> -----Original Message-----
> From: Richard Alimi [mailto:[email protected]] 
> Sent: Friday, December 18, 2009 3:36 PM
> To: Song Haibin
> Cc: 'Enrico Marocco'; [email protected]
> Subject: Re: [alto] New 
> draftnotification:draft-wang-alto-privacy-load-analysis-00
> 
> Hi Haibin,
> 
> Thanks for the reply - it is good that we can discuss CPID in 
> this context :)
> 

Me too :)

> On Thursday 17 December 2009 9:46:11 pm Song Haibin wrote:
> > Hi Rich and Enrico,
> > 
> > I also like the categorization. Generally I agree with most of what 
> > you  said here. Actually in section 3.1 "ISP privacy" and 
> secion 3.2 
> > "P2P  privacy" in draft-wang-alto-privacy-load-analysis, we have 
> > covered (1) and  (2). Tha's also why we suggested CPID 
> option. Since 
> > each peer has a CPID  and the cost can be calculated with 
> CPIDs directly.
> 
> >  ISPs don't have to
> >  give the full map to P2P applications
> 
> (See below for my comments on this..)
> 
> >  while P2P applications will not have
> >  their behaviors monitored by ISPs.
> 
> Yes - this is true in both CPID and the maps-based approaches.
> 

Agree.

> >  You don't have to worry about your CPID  information being 
> theft by 
> > other peers, it is useless to them.
> 
> Can you clarify what you mean by CPID "theft"?
> 

Sorry for the ambiguity. I mean even the ATLO server does not encrypt the
CPID information from the ALTO server to the client, and then this CPID is
acquired by other parties through someway.  Then it is not harmfull for the
peer who owns the CPID. Because other peers can not use the CPID for another
peer to calculate their cost.

> >  The
> >  benefits of CPID option include not only the obscuration of ISP  
> > information,
> 
> Can you be more specific here? By "ISP information", do you 
> mean a list of PIDs and the costs amongst the PIDs?
> 

I mean the mapping from IP addresses/prefixes to ISP aggregation points, and
the mapping of cost between these aggregation points. I understand that in
map-based solution, PID and cost do not reflect the real topology info like
AS number or routing hops either.  

> If you do mean that it obscures the PIDs and the costs 
> amongst PIDs, I think it can be dangerous to make this claim. 
> Just because the information isn't given away all at once 
> doesn't make it any more "private."  For example, it is 
> entirely possible for a set of peers to each query for their 
> own CPIDs, send them to a central server, and have the 
> central server compute the pairwise costs.  My feeling is 
> that we should be cautious about solutions that give some 
> party (either ISP or P2P applications) a false sense of 
> privacy or security.
> 
Theoretically, I think we all agree that map based solution and CPID have
the same level of privacy : ) In CPID proposal, it is very hard to get (a)
all IP prefixes under each aggregation points, and (b) the full cost map.
Especially in trackerless P2P scenarios, I don't know if there is a
particular one who can gather as many CPIDs as he wanted to rebuild the cost
map, or to get all IP prefixes under the same aggregation point.  


> >  but also simple and light-weight (each peer has to maintain  much 
> > smaller information).
> 
> This could be a benefit if the maps are extremely large 
> (e.g., something on the order of what Enrico had mentioned in 
> his presentation in Hiroshima).
> 

I am glad you can agree on that. I am curious about what size is "extremely
large". Maybe we need more work about  load analysis.


> >  I'm concern about the logic between (3a), (3b) and (3c).   
> Like Enrico
> > said, ALTO servers SHOULD NOT provide anyone with information they 
> > don't want to get redistributed. Then I don't see any necessary to 
> > encrypt the ALTO information. That means, we don't need to have 
> > mechanisms to solve
> >  (3a) and (3b).
> 
> As I mentioned in my response to Enrico's post, I disagree 
> with the wording here.  A provider should have the right to 
> distribute certain information only to authorized parties 
> (and protect it in transit from unauthorized parties).  
> For example, an ISP could provide customized topology 
> information to certain partners.
> 

Yes, it makes sense if ISP is willing to do that.

> Of course, solving (3a) and (3b) doesn't entail us inventing 
> anything new. If we stick with HTTP, there are already 
> solutions ready for use.
> 

Right. I would like to leave it open to implementers. They can choose
whether to encrypt their information or use what existing mechanism. Do you
want to specify it in the ALTO protocol?

> >  But we still need to have signature or something to prevent  the 
> > information being modified and to make sure it is from the 
> right ALTO  
> > server.
> 
> Yes.  It sounded like there was some interest in pursuing 
> this from the meeting in Hiroshima.
> 

I think this is important.

BR,
Haibin



_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to