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