Subject: [alto] Is there really a 'war' between ISPs and app providers?

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 26 Mar 2009 22:02:12 -0400

The WG chairs' diagram in the second ALTO session today portrayed a war between ISPs unwilling to provide topology information to the ALTO client, and P2P applications unwilling to provide any information to the ALTO server.
 
The image is strong, but it does not seem to reflect the reality that we are seeing. From our perspective, while the ISPs have constraints about what they can disclose, the ISPs are still able to provide useful policy information to the P2P applications. P2P applications have concerns about the privacy of their users, but do want to cooperate with the ISP to optimize network traffic in a manner beneficial to ISPs.
 
We are working together to solve an important problem that ISPs and the Internet have in general: the inefficiency of overlay routing, and lack of policy information available in machine-readable form. We have a proposal that we believe helps solve the problem to the satisfaction of both communities.
 
Can we agree as a WG that there is no 'hemispherical conflict'?
 
-- Rich Woundy, Comcast
-- Stanislav Shalunov, BitTorrent

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 26 Mar 2009 22:39:07 -0400

For those not attending the second session in person, here are the relevant slides:
 
http://www.ietf.org/proceedings/09mar/slides/alto-10.pdf

________________________________

From: Woundy, Richard
Sent: Thu 3/26/2009 10:02 PM
To: [email-masked]
Cc: Woundy, Richard; [email-masked]
Subject: Is there really a 'war' between ISPs and app providers?

 

-- Rich Woundy, Comcast

---

From: John Leslie <[email-masked]>
Date: Thu, 26 Mar 2009 22:52:54 -0400

Woundy, Richard <[email-masked]> wrote:
>  
> From our perspective, while the ISPs have constraints about what
> they can disclose, the ISPs are still able to provide useful policy
> information to the P2P applications.

   From my perspective, I see the same thing. Any failure in that
respect, IMHO, is due to inertia, not enmity.

> P2P applications have concerns about the privacy of their users,
> but do want to cooperate with the ISP to optimize network traffic
> in a manner beneficial to ISPs.

   To the extent it would improve their users' experience, however
slightly, I believe this to be true.

> We are working together to solve an important problem that ISPs and
> the Internet have in general: the inefficiency of overlay routing,
> and lack of policy information available in machine-readable form.

   These are by no means the only problems, but they are areas which
will almost certainly bear fruit.

> We have a proposal that we believe helps solve the problem to the
> satisfaction of both communities.

   Of the several proposals presented today, I believe any could 
have real benefits.

   However, all of them seemed to worry overmuch about an imagined
conflict of interests. I wish we could just let go of that belief,
design a protocol that hives good information in both directions
_and_ is easily expandable, and get some experience with it.

> Can we agree as a WG that there is no 'hemispherical conflict'?

   Pretty please!!

--
John Leslie <[email-masked]>

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 26 Mar 2009 20:10:30 -0700

Woundy, Richard wrote:
> The WG chairs' diagram in the second ALTO session today portrayed a
> war between ISPs unwilling to provide topology information to the
> ALTO client, and P2P applications unwilling to provide any
> information to the ALTO server.

No, no, wait, the diagram represents the two opposite approaches, not
certainly the positions of ISPs and P2P companies. On the contrary, the
fact that both are spending effort, time and money to find a good
compromise shows pretty clearly that this is not a war.

> -- Stanislav Shalunov, BitTorrent

And also this signature proves the point ;-)

-- 
Ciao,
Enrico

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 26 Mar 2009 20:38:58 -0700

On Mar 26, 2009, at 7:02 PM, Woundy, Richard wrote:

> P2P applications have concerns about the privacy of their users, but  
> do want to cooperate with the ISP to optimize network traffic in a  
> manner beneficial to ISPs.

This is also an area where I think the concerns are overblown.  DIRECT  
bulk-data P2P can't be privacy preserving, because peers know the  
peers they get data from.  You can try to be privacy preserving on  
ENTRY to a swarm (closed world), but once a peer is in a swarm,  
privacy-preserving is pretty much irrelevant.

Indirect P2P (eg, the UW? proposal recently) is whats necessary for  
privacy preserving, but that grossly magnifies bandwidth cost,  
requiring 2 intermediate hops (tor style).

---

From: "Y. R. Yang" <[email-masked]>
Date: Fri, 27 Mar 2009 01:54:19 -0400 (EDT)

Hi All,
  
First I should say that I still do not understand the diagram. I can infer 
the intention of 1 and 3, but not the other two: 
http://www.ietf.org/proceedings/09mar/slides/alto-10.pdf

Which one represents P4P/Info Export? Any elaboration?

To be honest, I should say that the image did create an image of 
conflicting possibilities in my mind and may not represent real protocols, 
which can support multiple possibilities.

Regarding a comparison, I think slide 20 of my presentation presents a 
much more converging picture than the slide in the preceding link. My 
presentation slides are at 
http://www.ietf.org/proceedings/09mar/slides/alto-5.pdf

Some self promotion here:

Re supporting multiple modes: I believe that the merged version of 
P4P/Info Export can already support what we discussed. Please read my 
slides if you get a chance. For example, Example 1 (slides 14-16) and 
Example 2 (slides 17-19) represent one extreme (Case 2 of the image?). 
Example 3 (slides 22-23) represents the Sorting approach (Case 1 of the 
image?).  So we do believe that we have a good solution already. Of 
course, any additional comments and contributions are highly welcome.

Re a negotiation protocol. I personally think that negotiation on prefix 
lengths and options will be too complicated. The current P4P/Info Export 
already supports "negotiation" in a simple sense. In particular, when an 
ALTO Client queries an ALTO Server, the first query is to obtain the 
Interface Descriptors (please see all three examples in my slides). The 
ALTO Server returns the interfaces supported. The Client then picks the 
one that it deems usable. We did not call it a negotiation because it is 
not. But if we stretch a bit, it is a kind of negotiation. We will be 
happy to revise this part to make it clearer and more flexible, if people 
think it can be a good starting base.

Cheers,

Richard

On Thu, 26 Mar 2009, 10:39pm -0400, Woundy, Richard wrote:

> The WG chairs' diagram in the second ALTO session today portrayed a war 
> between ISPs unwilling to provide topology information to the ALTO 
> client, and P2P applications unwilling to provide any information to the 
> ALTO server.
>
>  The image is strong, but it does not seem to reflect the reality that 
> we are seeing. From our perspective, while the ISPs have constraints 
> about what they can disclose, the ISPs are still able to provide useful 
> policy information to the P2P applications. P2P applications have 
> concerns about the privacy of their users, but do want to cooperate with 
> the ISP to optimize network traffic in a manner beneficial to ISPs.
>
>  We are working together to solve an important problem that ISPs and the 
> Internet have in general: the inefficiency of overlay routing, and lack 
> of policy information available in machine-readable form. We have a 
> proposal that we believe helps solve the problem to the satisfaction of 
> both communities.
>  
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Vijay Gurbani <[email-masked]>
Date: Fri, 27 Mar 2009 11:49:24 -0500

> Which one represents P4P/Info Export? Any elaboration?

Ellipse 2 was the P4P/Infoexport (at least that was the intent, if
not the delivery.)

> which can support multiple possibilities.

But regardless, the diagram of the chairs was not normative ;-)  It
was mainly a vehicle to get involved actors in direct talks towards
consensus on a path to a protocol.  In that, I think it may have
succeeded.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 27 Mar 2009 10:57:31 -0700

> Ellipse 2 was the P4P/Infoexport (at least that was the intent, if

Can you elaborate which part of the draft did give you this idea? Reading
the draft I'm not sure from where this idea (Ellipse 2 only) can be derived
since it seems clear that is not the case given the different queries
explained.

Anyway, that does not reflect the merged protocol in its current form since
it can provide all the functionality described (all ellipses) including
negotiation through service descriptors.

> But regardless, the diagram of the chairs was not normative ;-)

Right, but the diagram could have been circulated days before the meeting so
that feedback could be sent and any doubts tackled. A lot of the confusion
on the meeting sparked from that diagram.

 It

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 27 Mar 2009 11:58:03 -0700

> negotiation through service descriptors.

Ellipse 2 did _not_ represent the P4P/Infoexport merged proposal. If we
really had to link it to some solution, the closest one would probably
be the first version of infoexport; however, it was just meant to
represent a radical approach, in opposition to 1, the other extreme also
not necessarily impersonated by any proposal. In fact, the goal of the
discussion was to compare approaches rather than solutions, to try and
find some common ground (and to me it was quite successful in
identifying it in 3).

-- 
Ciao,
Enrico

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 27 Mar 2009 13:34:43 -0700

Please see inline.

zhangyunfei
2009-03-27

发件人： Nicholas Weaver
发送时间： 2009-03-26 20:38:18
收件人： [email-masked]
抄送： Richard Woundy; Nicholas Weaver
主题： Re: [alto] Is there really a 'war' between ISPs and app providers?

I support this point!

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 13:45:49 -0700

> privacy-preserving is pretty much irrelevant.
Please consider the following case:

A self-organizing peer-to-peer overlay which exchanges peer address 
information via encrypted network links. Peers in the swarm can see that 
data, but passive third-party observers cannot except by observing the 
traffic exchanged from peers they can see, which will only represent a 
small fraction of the IP addresses in use by a large swarm.

Sending that data in the clear to the ISP in order for it to be ranked 
now reveals many addresses which the peer might never connect to to that 
passive observer. That's unacceptable for certain applications.

In some cases, the user might trust their ISP with that data but still 
not want it to be exposed as plaintext traffic on the wire.

Matthew Kaufman

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 27 Mar 2009 16:55:18 -0400

"That's unacceptable for certain applications."

I'm confused:  Can you provide a few examples of such applications?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Matthew Kaufman
Sent: Friday, March 27, 2009 4:46 PM
To: Nicholas Weaver
Cc: Richard Woundy; [email-masked]
Subject: Re: [alto] Is there really a 'war' between ISPs and app
providers?

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 13:57:24 -0700

> I'm confused:  Can you provide a few examples of such applications?
Any application where the user base wishes to do its best to conceal 
from any one passive observer the majority of the participants in the 
application.

I build peer-to-peer things that let people build applications, I don't 
build the applications myself. This is one of the requirements that 
comes up from some people who (want to) build applications using the 
technology.

I am following the ALTO efforts because I can make the applications 
these developers build behave better on the network if I can have the 
part I build use locality information when constructing overlay networks.

Matthew Kaufman

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 14:00:29 -0700

How about an example of such an application that needs to conceal the IP 
addresses of the participants from a passive observer.

Matthew Kaufman wrote:
> I build peer-to-peer things that let people build applications, I 
> don't build the applications myself. This is one of the requirements 
> that comes up from some people who (want to) build applications using 
> the technology.
>

-- 
Richard Bennett

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 27 Mar 2009 14:02:33 -0700

> I'm confused:  Can you provide a few examples of such applications?

Skype, in countries where VoIP (or some encryption algorithms, or
anything else skype does) is illegal. Of course nobody is suggesting to
go break laws in foreign countries, but there is a strong understanding
that in this field in particular and in life in general privacy is
essential.

-- 
Ciao,
Enrico

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 14:04:16 -0700

Not to be too flip about it, but It's not clear to me that helping 
people break the law falls in the scope of the requirements for this 
working group or of the IETF in general.

RB

Enrico Marocco wrote:
> ------------------------------------------------------------------------
>

-- 
Richard Bennett

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 27 Mar 2009 17:09:20 -0400

I'm still mulling the Skype response...

Are there other examples beyond Skype?

Maybe Linux downloads?  Sharing the King James Version of the Bible?

Exactly what are those essential, right-to-privacy P2P applications that
demand privacy?

From: Richard Bennett [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 5:04 PM
To: Enrico Marocco
Cc: DePriest, Greg (NBC Universal); Richard Woundy; Nicholas Weaver;
[email-masked]
Subject: Re: [alto] Is there really a 'war' between ISPs and app
providers?

RB

Enrico Marocco wrote: 

	 
	I'm confused:  Can you provide a few examples of such
applications?

 

 

-- 
Richard Bennett

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 14:15:43 -0700

> working group or of the IETF in general.
What is "breaking the law" in one place is "supporting the human rights 
of the oppressed" in another.

But there's also corporate applications where there may be IT policy in 
place that restricts employees from sending lists of IP addresses of 
other users of that application in plaintext.

I admit that in both cases traffic analysis can be used to find *some* 
of the participating nodes, but a system where larger numbers of 
candidate nodes are transmitted to the ISP for ranking in plaintext is 
clearly not as safe as one where candidate nodes are transmitted to a 
trusted ISP for ranking in a secure form and that is not as safe as one 
where a trusted third party can anonymize the requests prior to having 
them ranked.

Given my position, I'm not really able to go on speculating more about 
what specific types of applications users might develop on top of the 
overlay network I implement for them, as it is important that my design 
be as generic as possible and not tailored to any specific use, 
particularly a use which might not be legal somewhere. What I can do it 
point out that a requirement that has come to me is that if I have my 
overlay use something like ALTO in order to build a more optimal 
overlay, some developers don't want node information being transmitted 
in plaintext, and others don't want it being transmitted at all.

Matthew Kaufman

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 27 Mar 2009 14:26:09 -0700

Richard, as already said (did you miss part of my email?), nobody is
suggesting to go break the law in foreign countries. The IETF charters
working groups to address very technical problems, conscious that
sometimes, somewhere, such technologies could have legal implications. I
suppose nobody disagrees that what the IETF has done in the security and
VoIP fields has been beneficial to a broad community, even if in some
parts of the world some of those technologies may be even considered
illegal.

Enrico

---

From: stefano previdi <[email-masked]>
Date: Fri, 27 Mar 2009 22:31:50 +0100

Richard, Stas,

On Mar 27, 2009, at 3:02 AM, Woundy, Richard wrote:
> The image is strong, but it does not seem to reflect the reality  
> that we are seeing. From our perspective, while the ISPs have  
> constraints about what they can disclose, the ISPs are still able  
> to provide useful policy information to the P2P applications. P2P  
> applications have concerns about the privacy of their users, but do  
> want to cooperate with the ISP to optimize network traffic in a  

that is good and it is also the impression we all had after the p2pi
workshop last year.

What confused me during the second meeting is that different  
"approaches"
where presented as if there were to be XOR'ed. The impression was given
by the "need to find a good balance between the extremes" while in fact
the "extremes" of the first picture could easily coexist.

We acknowledge the fact that some information will/should/must not be
delivered by currently most popular p2p applications but this doesn't
mean the protocol must not even think about having them in its
specification (the same is valid for the opposite direction SP->p2p).

The main reason is that ALTO will also serve a few other cases, e.g.,
where disclosure of IP addresses is not an issue. There are many cases
where CDN applications _do_ share details about upper layer so that
an ALTO-like server gives optimal hint on selection mechanisms.

We can argue about the "% of coverage" of these CDNs compared to
"current most popular p2p apps" but I hope we have in mind a larger
scope of applications leveraging ALTO and not strictly focus on what is
mostly used today.

Anyway, after the second meeting and after looking at the different
presented drafts, it looks to me we mostly all agree that the protocol
is not intended to enforce any form of information disclosure but it's
just a container of information that will improve selection mechanisms
in different kind of application overlays.

Most of the proposals I've read include different forms and variants
of what conveyed by the protocol so I tend to believe we all mostly
agree and we have a significant common ground that allows us to move
on into the next step of the merge process.

thanks.

s.

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 27 Mar 2009 17:35:55 -0400

"What is 'breaking the law' in one place is 'supporting the human rights

of the oppressed' in another."

Are you suggesting that protecting privacy is essential and protecting
the law can't be because some countries lack sufficient respect for the
law (and therefore might misuse ALTO information)?

-----Original Message-----
From: Matthew Kaufman [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 5:16 PM
To: Richard Bennett
Cc: Enrico Marocco; Nicholas Weaver; Richard Woundy; [email-masked];
DePriest, Greg (NBC Universal)
Subject: Re: [alto] Is there really a 'war' between ISPs and app
providers?

Matthew Kaufman

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 14:39:20 -0700

On Mar 27, 2009, at 1:45 PM, Matthew Kaufman wrote:

>> This is also an area where I think the concerns are overblown.   
>> DIRECT bulk-data P2P can't be privacy preserving, because peers  
>> know the peers they get data from.  You can try to be privacy  
>> preserving on ENTRY to a swarm (closed world), but once a peer is  
>> in a swarm, privacy-preserving is pretty much irrelevant.
> information via encrypted network links. Peers in the swarm can see  
> that data, but passive third-party observers cannot except by  
> observing the traffic exchanged from peers they can see, which will  
> only represent a small fraction of the IP addresses in use by a  
> large swarm.

Except that if someone really wants to map the P2P overlay, they can  
use a load of sybils participating in the network.

This is the point:

Peers can find out about other peers

Once you let an opponent into the network in any way, they can create  
sufficient sibyls to map the network completely.

Not to mention the ISP can determine who's talking to who just from  
traffic analysis alone, should that be desired.

It is all these items which mean that direct bulk-data P2P can't be  
privacy preserving, thus relaxing privacy constraints when developing  
localization should be a priority, especially when it comes to  
interacting with caching.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 14:38:59 -0700

> law (and therefore might misuse ALTO information)?
I am suggesting that protecting privacy is essential *for some 
developers that I have spoken to who are interested in using the overlay 
network I am developing*.

How ALTO handles privacy will then control how and when I can use ALTO 
to optimize that overlay. The more I can use ALTO, the better it is for 
ISPs (at least in theory).

That is all.

Matthew Kaufman

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 14:42:54 -0700

On Mar 27, 2009, at 1:57 PM, Matthew Kaufman wrote:

> from any one passive observer the majority of the participants in  
> the application.

This seems a weak adversary to consider, so weak as to be irrelevant.   
The idea that an adversary would be so passive as to be ineffective,  
when there are great active attacks, seems a silly constraint.

And if privacy is a real concern, you don't want direct P2P, but an  
indirect overlay.

There is a reason why Tor uses a "3-hop" rule on its communication,  
but such overlays are vastly less efficient for transmitting bulk data.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 14:44:13 -0700

On Mar 27, 2009, at 2:09 PM, DePriest, Greg (NBC Universal) wrote:

> I’m still mulling the Skype response…
>
> Exactly what are those essential, right-to-privacy P2P applications  
> that demand privacy?
>

As for skype, it is easy to detect that someone is doing P2P voip  
based on traffic analysis: its easy for the network to discover  
participants, and for sybils to map participants.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 14:43:40 -0700

> use a load of sybils participating in the network.
Not if they're unable to participate in the network but are only able to 
passively observe.
> Peers can find out about other peers
True.
> sufficient sibyls to map the network completely.
There may be sufficient cryptographic protection that an opponent cannot 
be a network participant.
> traffic analysis alone, should that be desired.
The ISP (or any passive observer of a node) is limited to seeing only 
those nodes a specific node chooses to talk to, not the larger list of 
nodes that are under consideration for communication. ALTO may 
potentially expose that larger list... to a passive observer if ALTO 
communication is not protected by encryption, just to the ISP if it is. 
In some cases the ISP may be more trusted than passive observation is. 
(For instance, a user might be on an unencrypted wireless network and 
unwilling to trust other people sitting nearby but be willing to trust 
the operator of that network)
> interacting with caching.

The privacy constraints are already relaxed because of the possibility 
of passive observation. If ALTO is significantly less private then some 
applications which might benefit from ALTO will be unable to use it. 
That would be unfortunate for the ISPs.

Matthew Kaufman

---

From: "DePriest, Greg (NBC Universal)" <[email-masked]>
Date: Fri, 27 Mar 2009 17:53:10 -0400

So, is "privacy" a chimera?  

If so, it is misleading to call it a "requirement."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nicholas Weaver
Sent: Friday, March 27, 2009 5:44 PM
To: DePriest, Greg (NBC Universal)
Cc: Richard Woundy; Nicholas Weaver; [email-masked]
Subject: Re: [alto] Is there really a 'war' between ISPs and app
providers?

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 15:00:55 -0700

On Mar 27, 2009, at 2:43 PM, Matthew Kaufman wrote:

> Nicholas Weaver wrote:
>>
>> Except that if someone really wants to map the P2P overlay, they  
>> can use a load of sybils participating in the network.

> Not if they're unable to participate in the network but are only  
> able to passively observe.

Closed world networks work when small, they fail when large.  Its  
exactly the botnet analysis problem, and there is a lot that can be  
done once you get a single node, let alone the ability to participate.

>> Once you let an opponent into the network in any way, they can  
>> create sufficient sibyls to map the network completely.
> There may be sufficient cryptographic protection that an opponent  
> cannot be a network participant.

If you carefully control admission and use some group key games, you  
MIGHT be able to do it, but I wouldn't count on it.

Additionally, nodes churn, and churn alone can get you a lot of  
information.

> The ISP (or any passive observer of a node) is limited to seeing  
> only those nodes a specific node chooses to talk to, not the larger  
> list of nodes that are under consideration for communication. ALTO  
> may potentially expose that larger list... to a passive observer if  
> ALTO communication is not protected by encryption, just to the ISP  
> if it is. In some cases the ISP may be more trusted than passive  
> observation is. (For instance, a user might be on an unencrypted  
> wireless network and unwilling to trust other people sitting nearby  
> but be willing to trust the operator of that network)

A)  Then don't use localization for such a sensitive application!   
This application you describe views the network as an opponent, so you  
aren't going to want to use external localization services at all!   
Period.  Because just the ACT of querying tells the localization  
service information, as well as node information, and a bunch of others.

B)  An ISP vantage point doesn't just see one node, but a boatload of  
nodes.

>> privacy preserving, thus relaxing privacy constraints when  
>> developing localization should be a priority, especially when it  
>> comes to interacting with caching.
>>
>
> The privacy constraints are already relaxed because of the  
> possibility of passive observation. If ALTO is significantly less  
> private then some applications which might benefit from ALTO will be  
> unable to use it. That would be unfortunate for the ISPs.

My argument however is you are at a middle ground on privacy that is  
ALMOST useless: active attackers and ISP level monitoring can rip  
through so much of the privacy at the level you describe.

That such an application can't use a localization service is, to my  
mind, a small loss:  such applications shouldn't really exist anyway  
because most of the privacy preserving is an illusion.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 16:01:04 -0700

> done once you get a single node, let alone the ability to participate.
Agreed, but these networks may in fact be relatively small.
> MIGHT be able to do it, but I wouldn't count on it.
You can invite individual nodes with cryptographic certificates as 
credentials. It requires having the client code and posessing a valid 
invitation certificate to join. In the real world, that can be made hard 
to come by.
> service information, as well as node information, and a bunch of others.
This is what developers should do, yes. But in some cases they want to 
make a tradeoff between more security and getting the locality data. 
This is 2009... why there are *any* protocols being deployed that don't 
have encryption, authentication, anti-tamper, etc. I don't understand.
True.
> because most of the privacy preserving is an illusion.
You may be right. However, developers have requested the ability to use 
locality awareness without transmitting large lists of addresses as 
plaintext. I can see their point, given my above comment about 
development of highly insecure protocols for today's Internet.

Matthew Kaufman

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 16:09:54 -0700

On Mar 27, 2009, at 4:01 PM, Matthew Kaufman wrote:
>> This application you describe views the network as an opponent, so  
>> you aren't going to want to use external localization services at  
>> all!  Period.  Because just the ACT of querying tells the  
>> localization service information, as well as node information, and  
>> a bunch of others.
> This is what developers should do, yes. But in some cases they want  
> to make a tradeoff between more security and getting the locality  
> data. This is 2009... why there are *any* protocols being deployed  
> that don't have encryption, authentication, anti-tamper, etc. I  
> don't understand.

Privacy vs data INTEGRITY are different things.  I dont' understand  
why there isn't universal data integrity on all the data.  It should  
be in the transport layer, IMO.

>
>>
>> B)  An ISP vantage point doesn't just see one node, but a boatload  
>> of nodes.
>>
> True.
>>
>> My argument however is you are at a middle ground on privacy that  
>> is ALMOST useless: active attackers and ISP level monitoring can  
>> rip through so much of the privacy at the level you describe.
>>
>> mind, a small loss:  such applications shouldn't really exist  
>> anyway because most of the privacy preserving is an illusion.
>>
> You may be right. However, developers have requested the ability to  
> use locality awareness without transmitting large lists of addresses  
> as plaintext. I can see their point, given my above comment about  

Just because they are your customers doesn't mean they are right:  I  
would not want to compromise localization (especially once caching  
gets introduced) in the name of a privacy protection that doesn't  
really exist.

Additionally, you CAN'T do localization comparison without knowing  
which points to compare.  Again, privacy can't work in that case.

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 16:25:37 -0700

I got that previous e-mail that said: "there is a strong understanding 
that in this field in particular and in life in general privacy is 
essential." I think the daily experience of the choices users make on 
the Internet contradicts this strong understanding. Privacy is one form 
of currency that people freely trade for products, services, 
information, and attention.

But as to your other point that unlawful activities may result from the 
specification of network protocols, indeed they will and that's never 
stopped me from creating new network protocols. In fact, criminal uptake 
is often proof that the original design was sound as criminals tend to 
be discriminating customers. (The criminal botnets currently in 
operation are wonderful technical systems, BTW, which may lead to some 
powerful systems for more beneficial purposes in the future.)

The problem I'm having with the emphasis on privacy in this context is 
that it creates a false dichotomy. The goal of ALTO is simply to create 
a system to improve the efficiency of P2P overlays and CDNs with respect 
to ISP networks; it seeks to do so in a manner that's consistent with 
preserving some reasonable degree of privacy, but in the tension between 
function and privacy it's clear to me that function wins. As Nick and 
others have pointed out, privacy in direct P2P swarms is an illusion in 
any case as there are so many easy ways to map P2P swarms on the basis 
of information no more obscure than the IP header.

So I don't see the value in reducing ALTO functionality in order to 
preserve the illusion of privacy, and I'm even open to reducing real 
privacy in order to increase capability should the question arise. But 
that question hasn't really arisen, so it doesn't matter.

RB

-- 
Richard Bennett

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 16:47:34 -0700

> which points to compare.  Again, privacy can't work in that case.
But an ISP or third-party I trust *could* do comparison without me 
showing the list to everyone passively monitoring the path between me 
and that service. And in the trusted 3rd-party case, they can anonymize 
who I am and why I'm asking even better.

Matthew Kaufman

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 27 Mar 2009 16:56:39 -0700

On Mar 27, 2009, at 4:47 PM, Matthew Kaufman wrote:

> showing the list to everyone passively monitoring the path between  
> me and that service. And in the trusted 3rd-party case, they can  
> anonymize who I am and why I'm asking even better.

On the wire interception is far less of a privacy concern than just  
the fact that you have to give the third party/ISP a list of the IPs  
to compare with.

Yes, it would be nice to specify "use either TLS or DTLS", but if you  
think this increases privacy significantly, it doesn't.

---

From: Richard Bennett <[email-masked]>
Date: Fri, 27 Mar 2009 18:00:50 -0700

Given the fact that the ALTO transaction is local to an ISP, nobody else 
is going to be able to see it anyway, so it doesn't matter whether it's 
plain text or not. So I'm agreeing with Nick.

RB

Nicholas Weaver wrote:
>> and that service. And in the trusted 3rd-party case, they can 

-- 
Richard Bennett

---

From: Stanislav Shalunov <[email-masked]>
Date: Fri, 27 Mar 2009 19:54:54 -0700

On Fri, Mar 27, 2009 at 9:49 AM, Vijay Gurbani <[email-masked]> wrote:
> the diagram of the chairs [...]
> consensus on a path to a protocol.

Vijay,

You put up a war slide where there was no war, claiming disagreement
where there was none.

This has the effect diametrically opposed to building consensus.

> In that, I think it may have succeeded.

Interested parties were talking directly before and after the botched
second ALTO session.  It didn't succeed in creating a direct
conversation, it failed in stopping it.

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 27 Mar 2009 20:31:01 -0700

Richard Bennett wrote:
> Given the fact that the ALTO transaction is local to an ISP, nobody 
> else is going to be able to see it anyway, so it doesn't matter 
> whether it's plain text or not. So I'm agreeing with Nick.
I totally disagree on this point. There are a whole lot of steps 
between, say, an open wi-fi access point at a coffee shop and the ISP 
that provides service to the coffee shop chain.

Now, Nick might be right enough anyway, but for other reasons.

Matthew Kaufman

---

From: "Y. R. Yang" <[email-masked]>
Date: Fri, 27 Mar 2009 23:42:59 -0400 (EDT)

Hi Vijay,

> Ellipse 2 was the P4P/Infoexport (at least that was the intent, if

I have to say that this is not the case.
 
> > To be honest, I should say that the image did create an image of conflicting
> > possibilities in my mind and may not represent real protocols, which can
> > support multiple possibilities.
> 
> But regardless, the diagram of the chairs was not normative ;-)  It was 
> mainly a vehicle to get involved actors in direct talks towards 

I was thinking about the second meeting on my long trip back to east 
coast. Below is a friendly, but critical comment on the second meeting 
that I wrote on the way. I have to say that the meeting might have slowed 
down the convergence process. Like I said during my presentation and shown 
in my comparison slide, I think much convergence has already happened. 
Thinking more about it, I think it is fair to say that the second meeting 
started with a presentation with such a set up:

 Facts:
 -----
  Fact 1. Both Eclipse 1 and Eclipse 2 are technically sound and 
          workable.

  Fact 2. ISPs can accept only Eclipse 1 because it can protect ISP 
          privacy;  and P2P can accept only Eclipse 2 because it can 
          protect P2P privacy.

  Implication:
  -----------
  Now the only issue is to select whose privacy.

 Assignment:
 ----------

  You guys figure out a way to pick one or design a negotiation protocol 
  to do the run-time selection.

During the meeting, I said multiple times that I was confused about the 
setup.

I disagree with both stated "facts". For Fact 1, I think Sorting (Eclipse 
1) of course can be useful---this is why we included it in P4P/Info 
Export. But I have doubt about it working in large-scale settings, not 
only for privacy issues. Think about PPLive which can run to 2 million 
clients in a single channel. Do you send 2 million IP addresses to an ALTO 
Server to sort? Trim down to 200,000, or 20,000, or 2,000, or 200. How? It 
is a pity that technical issues did not play a major role in the 
discussions. In my slides, scalability is before privacy, with the 
understanding that privacy of course is important.

I also have to disagree with the second stated "fact". Like I said 
multiple times, sorting protects ISP privacy is an assumption, not a fact. 
It is a complicated issue. Suppose an ALTO Server does not directly reveal 
the classification in Eclipse 2, but only uses the Eclipse 1 as an 
interface. Then a probing experiment is the following. Take any two 
destinations a and b, and ask the sorting interface. If a and b have same 
preference value to the ALTO Server, we are likely see either order [a b] 
or [b a]. If one has a higher preference value, say a is more preferred 
than b, the sorting will return a before b. Build a graph with nodes being 
IP addresses. If we see a ahead of b, add a directed link from a to b. 
Then the problem of identifying the preference ladders is a standard 
strongly connected components problem. Of course, we can modify the 
sorting machine to be more complicated (trying to obfuscate the 
information while at the same time making the ALTO info less effective), 
then we can design more learning/mining algorithms to filter the added 
noise.

To summarize, I greatly appreciate your effort for chairing the working 
group. It is a lot of work! It may be much helpful if the agenda has been
sent out earlier for feedback and comments.

Again, let me emphasize that this is a *friendly*, but criticial comment.

Cheers,

Richard

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 28 Mar 2009 10:22:04 -0700

> I have to say that this is not the case.

No, Richard, it is not the case. The diagram did not intend to map
solutions onto ellipses, but if it had meant to (stupidly, IMO, as
solution specifications at this time are still moving targets), probably
P4P/Infoexport would have gone into 3.

>   Fact 1. Both Eclipse 1 and Eclipse 2 are technically sound and 

The WG, not the chairs, are expected to determine whether an approach is
technically sound and workable. The goal of the meeting was to start an
open discussion about them, and even if such a discussion had already
started among proponents of some solutions, the intent was to extend it
to the larger group. And I think that, at the end of the day, that is
what's actually happened.

>           privacy;  and P2P can accept only Eclipse 2 because it can 

Nope. That is certainly not a "can only", it is probably more like a
preference, whose reasons -- scaability, privacy, perceived privacy and
so on -- have just started to be openly debated.

> sent out earlier for feedback and comments.

Well, it was supposed to be an open discussion of the solutions
presented during the first session, and days before it had been
announced on the list as such. If it turned out not to be the best
choice, at least it has had the merit to bring the participants with
different although converging views together in the bashing of the
chairs. Still an important achievement, even if quite accidental ;-)

> Again, let me emphasize that this is a *friendly*, but criticial comment.

And thanks for sharing it, such kind of feedback is extremely helpful.

-- 
Ciao,
Enrico

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 30 Mar 2009 11:12:39 -0500

Y. R. Yang wrote:
> coast. Below is a friendly, but critical comment on the second
> meeting that I wrote on the way. 

Richard: No worries; critical comments imply someone actually
cares a great deal.

Now, it seems that there has been an undue amount of consternation
on my inclusion of P4P/Infoexport in ellipse 2.  Clearly,
I don't consider the merged P4P/Infoexport to be on one extreme
of the spectrum.  As you (and others) have pointed out, it is
expansive enough to include multiple possibilities (preferences,
ranking, etc.)  The reason I put it in ellipse 2 when the
question was raised on the list was that P4P/Infoexport was
fleshed out well enough that it did not fit in ellipse 4 (where
we don't know what the request and response will be), nor did it
neatly fit in ellipse 3 (where the request and response were
wild-carded, implying uncertainty at worst and multiplicity
of options at best.  And while P4P/Infoexport implied the
latter, it certainly did not imply the former.)  To the extent
that my inclusion of P4P/Infoexport in ellipse 2 has caused
any discomfort to its authors, I readily apologize.

I will now refrain from mapping P4P/Infoexport into any ellipse
since it was expressly not our intent to map solutions to an
ellipse.  The ellipses simply represented coarse grained views
of where we were and where we are headed.

As I understand it, the authors of the various solution drafts
had a meeting after the additional session and much consensus
has been reached.  Absent any other summary from the discussion,
I think Rich's conclusion from his original email sums this up:

   We are working together to solve an important problem
   that ISPs and the Internet have in general: the inefficiency
   of overlay routing, and lack of policy information available
   in machine-readable form. We have a proposal that we believe
   helps solve the problem to the satisfaction of both
   communities.

> To summarize, I greatly appreciate your effort for chairing the
> working group. It is a lot of work! It may be much helpful if the
> agenda has been sent out earlier for feedback and comments.

I presume you mean the agenda for the additional session.  If so,
you may recall that we were in touch with the authors of the
various solutions draft to intimate them of a possible session
as the request worked its way through the IETF secretariat.  It
was not until Saturday that we knew the request was approved and
on Sunday a room was announced.  On Monday we sent an email to
the WG list officially announcing the session (please see
http://www.ietf.org/mail-archive/web/alto/current/msg00187.html).

There wasn't much in the form of an agenda except that we
thought bringing various solution proposal authors in the
same room will spur discussions.  The now infamous ellipse
slide was created Wed evening with the intent to summarize
approaches and move discussion forward.

Please continue the discussions and let the WG know what the
status is as things progress.

Thank you for all your work,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/