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). > > > 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. 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). 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. 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. > > > 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..." -- Richard Alimi Department of Computer Science Yale University _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
