Richard, I like your categorization, I think it would be useful having it written somewhere (in the requirements doc?) as a reference for future discussions.
On the substance of the matter, I agree that we should introduce mechanisms in the protocol to address (1), (2), (3a) and (3b), but regarding (3c) don't go any further than stating very clearly that ALTO servers SHOULD NOT provide anyone with information they don't want to get redistributed. Enrico Richard Alimi wrote: >> After reading about draft, I'm concerned about the privacy issues. Since >> mutual authentication of clients and servers (assure the peers are >> trusted)and information-encryption mechanism(assure the information are >> protected)will assure the important information(privacy) not being theft >> and disclosed, if we can say that P2P and ISP can fully trust each other. >> In this case all things will turn to be simple like solution 5 in the >> draft. In another way to say, we need to design a good authentication and >> encryption mechanism to help to solve privacy issues. > > I think we need to start getting specific about what we mean by "privacy > issues" in these discussions, since it could be interpreted to mean multiple > things, some of which (I feel) we can address and some that we cannot. > > Here are at least some interpretations of what "privacy" can mean in ALTO: > > (1) Preventing an ISP's internal topology from being discovered > (2) Preventing an ISP from learning about P2P application behavior (e.g., > peers with which it is connecting) > (3) Preventing an ISP's ALTO information from being "leaked" to unauthorized > parties. There are a couple of cases here: > (a) An ALTO Server sends the information directly to an unauthorized ALTO > Client > (b) An unauthorized party snoops on the data transmission from the ALTO > Server to an authorized ALTO Client. > (c) An authorized ALTO Client knowingly sends the information to an > unauthorized party > > Authenticating ALTO Clients to servers and encrypting traffic on the wire are > not going to solve (1) or (2). In the current solution, (1) is addressed > primarily by an ISP choosing how much aggregation is done before even making > the information available to ALTO Clients. (2) is addressed by allowing ALTO > Clients to query for "maps" from the ALTO Server which may be used entirely > locally by an ALTO Client, instead of requiring ALTO Clients to query ALTO > Servers based on endpoint addresses. Of course, ALTO Clients that wish to > query based on endpoint addresses may still do so with the Ranking Service, > and they may even adopt strategies such as zeroing-out or randomizing the > last > few bits of the IP addresses they are sending (with a potential side effect > being inaccurate results). > > Note that (1) and (2) cannot be addressed with authentication/encryption, > since (1) and (2) talk about the *content* of the information transmitted, > and > not *who* is doing the transmission and whether or not it is protected from > snooping. > > Now, when it comes to (3), this is where authentication/encryption can help > in > some cases. Authentication and encryption can address (3a) and (3b). > However, it doesn't help with (3c). > > Authentication/Encryption doesn't help in (3c), since the authorized ALTO > Client needs the ability to extract the information needed to do its job. If > we keep the solution simple and just require ALTO Clients to decrypt > information before using it, the ALTO Client couple simply decrypt it, and > send it along to an unauthorized ALTO Client. > > In (3c), even if we were to have some technique to prevent the raw ALTO > information to be transferred from an authorized ALTO Client to an > unauthorized ALTO Client, this still doesn't quite satisfy the requirement. > An > unauthorized ALTO Client could simply ask the authorized ALTO Client for the > desired information (e.g., "What is the list of PIDs?", "What is the cost > from > PID A to PID B?", "Please rank IP addresses A, B, C, D, and E."). The > authorized ALTO Client clearly has the right to compute the answers > (otherwise > the ALTO information would be useless), so it could pretend that it was > asking > for the information itself, and compute the answer. The authorized ALTO > Client > then simply sends the answer back to the unuathorized ALTO Client. > > In summary, we already have solutions for (1), (2), (3a), and (3b), but my > feeling is that it would not be fruitful for us to try and address (3c) > within > this working group.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
