Hi Richard, > -----Original Message----- > From: Richard Alimi [mailto:[email protected]] > Sent: Saturday, December 19, 2009 2:15 AM > To: Song Haibin > Cc: 'Enrico Marocco'; [email protected] > Subject: Re: [alto] New > draftnotification:draft-wang-alto-privacy-load-analysis-00 > > Hi Haibin, > > > > > 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. > > That may be true from the P2P-side, but from the ISP-side, > transmitting CPIDs may still require > authentication/encryption. This relates to the comment about > whether we are solving (3a) and (3b). >
I don't want to mix authentication with encryption. I do understand the motivation to do authentication. But for CPID, I don't understand what the motivation for an ISP to do the encryption. Since a peer still needs to get CPIDs of other peers in order to calculate the cost. I would agree we need encryption if there is certain information that P2P clients consider as private. Note that encryption will also introduce additional load to the ALTO server. > > > > 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. > > You're correct that it would take longer for tracker-less > scenarios, where the ISP only offers a CPIDs based on IP > address, and would require more resources to carry out. Yes. >But, > there are many variables to consider here that can all play a > role in how easy or hard discovery is. For example: > - How often the ISP information changes, and what changes > (e.g., aggregations > or costs amongst aggregations) > - The number of peers that are coordinating to discover the > information > - The amount of aggregation done by the ISP when preparing > the information > - How much error the peers reconstructing the topology are > willing to tolerate > > Of course, there is a trade-off here. You may make it harder > for P2P to reconstruct the topology by providing > finer-grained information. There are a couple of options: > 1) The ISP provides accurate information under the assumption > that it cannot > be reconstructed. Of course, if it *is* reconstructed, > there's a danger to > the ISP because they are leaking more information than > originally intended. > 2) The ISP extends their original coarse-grained information > to add some more > "false" PIDs and costs, or they take the true fine-grained > topology and > perturb it. Exactly how they extend or perturb the > information can have > side-effects in terms of application behavior or > performance. Also, both of > these solutions in which false information is purposefully > provided by > the ALTO Server seems quite "awkward" to me. > 3) The ISP really does wish to provide extremely fine-grained > information. In > this case, there is obviously no privacy issue for the > ISP. This then gets > into the scalability discussion (as mentioned below). > With providing finer-grained information, there will need more resources to reconstruct the prefix information and cost information (and most probably, incomplete). With CPID option, you do not disclose the prefix information to P2P applications (I don't know if this kind of information is private to ISPs). I think the challenge for map-based solution in this case is the map size and the processing resource. Looking up in a big table to match the IP address and their prefix each time consumes more CPU circles than a simple calculation. Of course, you can use cache technology to optimize it. In tracker-base scenario, this will be a problem for a originally simple p2p tracker. > Also note that in a tracker-based scenario, it may > substantially increase implementation complexity if the > tracker must query for a CPID for each joining peer. When we > had spoken with P2P companies providing tracker-based > solutions (with regards to P4P), one of the first things they > wanted to clarify is that we did NOT need to make a query > over the network for each joining peer. > Query CPID for each "joining" peer will not introduce much load. We don't have to query CPID for each "request". It depends on the dynamics of joining behaviors. It's a tradeoff with map base solution. With map based solution, we don't have to query the anything for each peer initially, but we have to lookup the prefix map to get the aggregation point information for the peers after we got the whole map. > Given this, if CPID were to be used in tracker-based > scenarios, it might necessitate having the ALTO Server > provides a map from CPID -> SetOfPrefixes so the tracker > could do the IP->CPID lookup locally. In such a case, > constructing the original network map and cost map is trivial. > I don't think it is necessary to have this map. IMO, both CPID and map based solution work fine with this scenario. > > > > 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. > > That would be a good question to study :) > > > > 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? > > I believe it should be mentioned, especially since Lisa's > presentation in Hiroshima suggests explicitly to "Require > specific authentication and encryption." In our context, > this seems to translate to "If an ALTO Server and/or ALTO > Client wishes to use authentication or encryption, these are > the ones that should be used..." > I agree we need authentication. And I would agree with encryption if there is some information considered "private" : ) Haibin > -- > Richard Alimi > Department of Computer Science > Yale University > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
