Re: [p2pi] Charter and problem statement

[stefano previdi <sprevidi at cisco.com>]

> From: Damien Saucez <damien.saucez at uclouvain.be>
> 
> Arvind,
> 
> What you propose can be done with a solution able to work with any kind of
> "identifier/locator". If the protocol is not limited to a specific kind of
> entity identification, you can tackle the problem by creating a ranking
> hierarchy: a first engine ranks P2P IDs based on P2P-related criteria. To
> refine the ranking, IDs can be translated into IP addresses sets and, a
> second engine, ranks these sets based on ISP-related criteria. This can be
> done with IDIPS but we'll discuss technical solutions later.
> 
> The way the engines perform the ranking is layer dependent but the
> information dissemination can remain the same (using something like
> address families?).
> 
> The key point of this discussion is that the ALTO protocol must be able to
> deal with any kind of "identifier/locator" (at least optionally) as stated
> by Stefano.

yes. As written in the requirements draft, IP addresses should be one option
for the ALTO ranking system.

Working with application identifiers is fine too but so far the only piece
of standardized information we can rely on are IP addresses (from a protocol
specification perspective I don't know how stable will be an application ID
encoding format).

Some concerns have been raised in terms of confidentiality that would need
to be disclosed (if client has to send into an ALTO request a list of IP
addresses) however, I believe SPs do already know how to figure out who's
doing what.

So, for me, IP addresses in ALTO req/res guarantee the transparency of the
protocol behavior when faced to a diversity of applications.

Thanks.

s. 

> Damien Saucez
> 
>> This is a rather interesting discussion.  Just wanted to draw attention
>> to the design proposed by p4p (another traffic localizing system in the
>> spirit of ALTO).
>> 
>> Note that a system might have to satisfy both: a) p2p user privacy and
>> b) ISP privacy.
>> 
>> So in this regard, p4p requires that the p2p swarm information and the
>> ISP traffic/topology information are maintained by two different
>> entities -- one owned by the p2p system and one owned by the ISP -- and
>> that information flow between the two entities operate at somewhat
>> coarse granularities.
>> 
>> For instance, when the p2p system needs some ISP-specific information,
>> such as traffic conditions between IPs x and y, it first maps them to
>> their corresponding PoPs (say New York and Los Angeles), and then
>> queries the ISP's server for the current conditions between the two PoPs.
>> 
>> Similarly, when the ISP needs to export information on topology and ISP
>> preferences, it publishes them as a full mesh, thereby somewhat limiting
>> the ability to reverse-engineer ISP's objectives.
>> 
>> This is of course just a first and simple attempt at limiting
>> information leakage, and coming up with more principled
>> privacy-preserving approaches would be an interesting research direction.
>> 
>> 
>>> 
>>> On Jul 22, 2008, at 10:54 AM, Reinaldo Penno wrote:
>>> 
>>>> This thread made the think that we need more security wording on the
>>>> charter.
>>>> 
>>>> I see ALTO maybe requiring a security document considerations of its
>>>> own
>>>> besides the security section on each document.
>>>> 
>>>> There is clearly an expectation of privacy from the P2P client. There
>>>> is
>>>> clearly an expectation from the ISP that he is not aiding
>>>> (conscientiously)
>>>> illegal file sharing, amongst others.
>>> 
>>> Actually, the expectation of privacy from a P2P client might be
>>> considered illusionary.
>>> 
>>> The whole point of P2P is you need to be able to discover peers, so
>>> any attacker who is authorized to participate in the P2P network (eg,
>>> able to get a Content-identifier from the tracker and therefore
>>> authorization to participate in the swarm) should be able to map at
>>> least part of the P2P network and, with sybils, generate a complete map.
>>> 
>>> Thus, for access to an ALTO server, the requirement should be "get NO
>>> more information than you could obtain otherwise as a participant in
>>> the P2P network", which is a huge amount, but generally safe.  ("If
>>> you know the content/network/swarm ID, you can get the peer list,
>>> because you need to be authorized already to know this identifier").
>>> 
>>> 
>>> The interesting question, however, is can an ALTO node, which ISN'T
>>> necessarily authorized to participate in a swarm, gain information on
>>> a swarm based on both queries to it, and also use any transactional
>>> information it gains to contact other ALTO servers to gain information
>>> about the swarm.
>>> 
>>> EG, it gets a content identifier based on a request, and then queries
>>> other ALTO servers to find out who else is participating in this
>>> content identifier.
>>> 
>>> 
>>> In the end, it may be necessary to write requirements on information
>>> leaking that specifically fall one-way or the other, eg, "There is NO
>>> expectation of privacy because of X, Y, Z", or "Because of the
>>> client's expectation of privacy, when such is enabled, ALTO can't do
>>> A, B, C".
>>> 
>>> 
>>> _______________________________________________
>>> p2pi mailing list
>>> p2pi at ietf.org
>>> https://www.ietf.org/mailman/listinfo/p2pi
>> 
>> _______________________________________________
>> p2pi mailing list
>> p2pi at ietf.org
>> https://www.ietf.org/mailman/listinfo/p2pi
>> 
> 
> 
> _______________________________________________
> p2pi mailing list
> p2pi at ietf.org
> https://www.ietf.org/mailman/listinfo/p2pi


_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi