Subject: Re: [alto] New draft notification:draft-wang-alto-privacy-load-analysis-00

From: "xiongbearie" <[email-masked]>
Date: Thu, 17 Dec 2009 14:43:27 +0800

Hi Song, 
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.

Best Regards

2009-12-17 

熊淼 Xiong Miao
Mobile Life and New Media Lab
Beijing University of Posts and Telecommunications
Addr:No.10 XiTuCheng Road Haidian District,Beijing 100876, P.R. China
Tel：+8610-62285126

Date: Tue, 20 Oct 2009 10:33:51 +0800From: Song Haibin <[email-masked]>Subject: [alto] New draft notification:draft-wang-alto-privacy-load-analysis-00To: 'alto' <[email-masked]>Message-ID: <[email-masked]>Content-Type: text/plain; charset=us-asciiHi all,We have submitted an analysis draft on ALTO load and privacy. Here is thelink:http://tools.ietf.org/id/draft-wang-alto-privacy-load-analysis-00.txtAny comments are appreciated!Best Regards,HaibinSkype: alexsonghw------------------------------

---

From: Richard Alimi <[email-masked]>
Date: Thu, 17 Dec 2009 09:40:09 -0500

> 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

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 17 Dec 2009 16:20:17 +0100

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

---

From: Richard Alimi <[email-masked]>
Date: Thu, 17 Dec 2009 10:31:37 -0500

Hi Enrico,

> servers SHOULD NOT provide anyone with information they don't want to

Agreed, but it might make senses to instead state something like "The protocol 
SHOULD NOT be responsible for preventing unauthorized redistribution of ALTO 
information by ALTO Clients."

I would think its possible for a provider to have some legal agreements 
covering redistribution of the ALTO information, but it would be outside of 
the scope of the protocol.

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 17 Dec 2009 16:44:25 +0100

> information by ALTO Clients."

Yeah, I don't actually care about the wording right now, as long as it
makes clear that we are not going to waste time on any kind of DRM-like
technology for protecting information distributed by ALTO servers.

-- 
Ciao,
Enrico

---

From: Song Haibin <[email-masked]>
Date: Fri, 18 Dec 2009 10:46:11 +0800

Hi Rich and Enrico,

I also like the categorization. Generally I agree with most of what you said
here. Actually in section 3.1 "ISP privacy" and secion 3.2 "P2P privacy" in
draft-wang-alto-privacy-load-analysis, we have covered (1) and (2). Tha's
also why we suggested CPID option. Since each peer has a CPID and the cost
can be calculated with CPIDs directly. ISPs don't have to give the full map
to P2P applications while P2P applications will not have their behaviors
monitored by ISPs. You don't have to worry about your CPID information being
theft by other peers, it is useless to them. The benefits of CPID option
include not only the obscuration of ISP information, but also simple and
light-weight (each peer has to maintain much smaller information).

 I'm concern about the logic between (3a), (3b) and (3c).   Like Enrico
said, ALTO servers SHOULD NOT provide anyone with information they don't
want to get redistributed. Then I don't see any necessary to encrypt the
ALTO information. That means, we don't need to have mechanisms to solve (3a)
and (3b). But we still need to have signature or something to prevent the
information being modified and to make sure it is from the right ALTO
server. 

Xie Xie,
Haibin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Enrico Marocco
> Sent: Thursday, December 17, 2009 11:44 PM
> To: Richard Alimi
> Cc: [email-masked]
> Subject: Re: [alto] New 
> draftnotification:draft-wang-alto-privacy-load-analysis-00
> 
> Richard Alimi wrote:
> >> 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.
> >>
> >> 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.
> > 
> > Agreed, but it might make senses to instead state something 
> like "The 
> > protocol SHOULD NOT be responsible for preventing unauthorized 
> > redistribution of ALTO information by ALTO Clients."
> 
> Yeah, I don't actually care about the wording right now, as 
> long as it makes clear that we are not going to waste time on 
> any kind of DRM-like technology for protecting information 
> distributed by ALTO servers.
> 
> --
> Ciao,
> Enrico
>

---

From: Song Haibin <[email-masked]>
Date: Fri, 18 Dec 2009 10:50:46 +0800

Hi Xiong Miao,

Please see my last email.

Xie Xie,
Haibin

> From: xiongbearie [mailto:[email-masked]] 
> Sent: Thursday, December 17, 2009 2:43 PM
> To: melodysong
> Cc: alto; standardMINE
> Subject: Re: [alto] New draft 
> notification:draft-wang-alto-privacy-load-analysis-00
> 
> Hi Song,
> 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.
>  
> Best Regards
>  
> 2009-12-17
> ________________________________
> 
> 熊淼 Xiong Miao
> Beijing University of Posts and Telecommunications Addr:No.10 
> XiTuCheng Road Haidian District,Beijing 100876, P.R. China
> Tel：+8610-62285126
> ________________________________
> 
> Date: Tue, 20 Oct 2009 10:33:51 +0800
> From: Song Haibin <[email-masked]>
> Subject: [alto] New draft notification:
> draft-wang-alto-privacy-load-analysis-00
> To: 'alto' <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii Hi all, We have 
> submitted an analysis draft on ALTO load and privacy. Here is the
> link:
> http://tools.ietf.org/id/draft-wang-alto-privacy-load-analysis-00.txt
> Any comments are appreciated!
> Best Regards,
> Haibin
> Skype: alexsonghw
> ------------------------------
> ________________________________
> 
>

---

From: Richard Alimi <[email-masked]>
Date: Fri, 18 Dec 2009 02:36:01 -0500

Hi Haibin,

Thanks for the reply - it is good that we can discuss CPID in this context :)

On Thursday 17 December 2009 9:46:11 pm Song Haibin wrote:
> Hi Rich and Enrico,
> 
> I also like the categorization. Generally I agree with most of what you
>  said here. Actually in section 3.1 "ISP privacy" and secion 3.2 "P2P
>  privacy" in draft-wang-alto-privacy-load-analysis, we have covered (1) and
>  (2). Tha's also why we suggested CPID option. Since each peer has a CPID
>  and the cost can be calculated with CPIDs directly.

>  ISPs don't have to
>  give the full map to P2P applications

(See below for my comments on this..)

>  while P2P applications will not have
>  their behaviors monitored by ISPs.

Yes - this is true in both CPID and the maps-based approaches.

>  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"?

>  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?

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.

>  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).

> ALTO information. That means, we don't need to have mechanisms to solve
>  (3a) and (3b).

As I mentioned in my response to Enrico's post, I disagree with the wording 
here.  A provider should have the right to distribute certain information only 
to authorized parties (and protect it in transit from unauthorized parties).  
For example, an ISP could provide customized topology information to certain 
partners.

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.

>  But we still need to have signature or something to prevent
>  the information being modified and to make sure it is from the right ALTO
>  server.

Yes.  It sounded like there was some interest in pursuing this from the 
meeting in Hiroshima.

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 18 Dec 2009 10:10:36 +0100

Song Haibin wrote:
> ALTO information.

No, wait, there's a bug in this reasoning. Encryption is still very
necessary to preserve user privacy, i.e. to let an ALTO server provide a
user with information the user themselves may consider confidential
(e.g. their own uplink/downlink capacity). But of course if the user is
willing to redistribute even such potentially-confidential information,
there is no means for the server to prevent that.

-- 
Ciao,
Enrico

---

From: Song Haibin <[email-masked]>
Date: Fri, 18 Dec 2009 17:58:01 +0800

> From: Richard Alimi [mailto:[email-masked]] 
> Sent: Friday, December 18, 2009 3:36 PM
> To: Song Haibin
> Cc: 'Enrico Marocco'; [email-masked]
> Subject: Re: [alto] New 

Me too :)

> > I also like the categorization. Generally I agree with most of what 
> > you  said here. Actually in section 3.1 "ISP privacy" and 
> secion 3.2 
> > "P2P  privacy" in draft-wang-alto-privacy-load-analysis, we have 
> > covered (1) and  (2). Tha's also why we suggested CPID 
> option. Since 
> > each peer has a CPID  and the cost can be calculated with 
> CPIDs directly.
> 
> >  ISPs don't have to

Agree.

> >  You don't have to worry about your CPID  information being 
> theft by 
> > other peers, it is useless to them.
> 

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.

> 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.  

> >  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.

> > said, ALTO servers SHOULD NOT provide anyone with information they 
> > don't want to get redistributed. Then I don't see any necessary to 
> > encrypt the ALTO information. That means, we don't need to have 
> > mechanisms to solve
> >  (3a) and (3b).
> 
> As I mentioned in my response to Enrico's post, I disagree 
> with the wording here.  A provider should have the right to 
> distribute certain information only to authorized parties 
> (and protect it in transit from unauthorized parties).  
> For example, an ISP could provide customized topology 
> information to certain partners.
> 

Yes, it makes sense if ISP is willing to do that.

> 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?

> >  But we still need to have signature or something to prevent  the 
> Yes.  It sounded like there was some interest in pursuing 
> this from the meeting in Hiroshima.
> 

I think this is important.

BR,
Haibin

---

From: Richard Alimi <[email-masked]>
Date: Fri, 18 Dec 2009 13:14:34 -0500

Hi Haibin,

> 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).

> 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.
> 
> 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.

> large". Maybe we need more work about  load analysis.

That would be a good question to study :)

> 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..."

---

From: Xiong Miao <[email-masked]>
Date: Tue, 22 Dec 2009 17:59:56 +0800

Thank you for your categorization, for it make me more clear about the
"privacy issues".
But i'm still puzzled about how to define information that  SHOULD NOT
provide for ALTO servers since the information may be useful for one
client but not useful for another. It's like an access-control issues.
ALTO protocol needs something to do with this.

2009/12/17 Richard Alimi <[email-masked]>:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
--------------------------------------------------------------------------------

熊淼 Xiong Miao

--------------------------------------------------------------------------------

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Dec 2009 09:58:47 -0500

> ALTO protocol needs something to do with this.

I agree that the ALTO Protocol should allow for access control *for requests 
to the ALTO Server*.  That is, it should handle (3a) and (3b) in the 
categorization (which also entails encryption to prevent snooping on the 
wire).  This is doable with existing techniques such as HTTP Basic/Digest 
authentication, and SSL/TLS presuming that we stick with a protocol built on 
top of HTTP.

Can you clarify what you mean by "useful"?  The term "useful" is a very 
general term that could encompass many uses, both legitimate and otherwise.

For example, an ALTO Client may have a business agreement to obtain detailed 
network information from a network provider via ALTO, and the agreement may 
state that the ALTO Client cannot share the information with a 3rd party. The 
ALTO Client may consider it "useful" to ignore the legal agreement and sell 
the information to a 3rd party anyways for a large sum of money.

This is the primary reason there is a distinction between (3a-b) and (3c). It 
is to allow the information to be protected in transit, and to protect it from 
being *directly* distributed to an unauthorized party. However, enforcing 
access control once an authorized ALTO Client has received it would entail 
other mechanisms (e.g., DRM) as Enrico has mentioned.

Another way to summarize the difference, is that the ALTO Protocol provides 
access control for requests to an ALTO Server, but it *does not* provide 
access control for the ALTO information itself.

---

From: Song Haibin <[email-masked]>
Date: Wed, 23 Dec 2009 17:35:51 +0800

Hi Richard, 

> Sent: Saturday, December 19, 2009 2:15 AM
> To: Song Haibin
> > > >  You don't have to worry about your CPID  information 
> being theft 
> > > > by other peers, it is useless to them.
> > >
> > 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).
> 

I don't want to mix authentication with encryption. I do understand the
motivation to do authentication. But for CPID, I don't understand what the
motivation for an ISP to do the encryption. Since a peer still needs to get
CPIDs of other peers in order to calculate the cost. I would agree we need
encryption if there is certain information that P2P clients consider as
private. Note that encryption will also introduce additional load to the
ALTO server. 

> > > 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.
> > 
> 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.
> > 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.  

Yes.

>But, 
> there are many variables to consider here that can all play a 
> role in how easy or hard discovery is. For example:
> 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:

With providing finer-grained information, there will need more resources to
reconstruct the prefix information and cost information (and most probably,
incomplete). With CPID option, you do not disclose the prefix information to
P2P applications (I don't know if this kind of information is private to
ISPs). I think the challenge for map-based solution in this case is the map
size and the processing resource. Looking up in a big table to match the IP
address and their prefix each time consumes more CPU circles than a simple
calculation. Of course, you can use cache technology to optimize it. In
tracker-base scenario, this will be a problem for a originally simple p2p
tracker.

> 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.
> 

Query CPID for each "joining" peer will not introduce much load. We don't
have to query CPID for each "request". It depends on the dynamics of joining
behaviors.  It's a tradeoff with map base solution. With map based solution,
we don't have to query the anything for each peer initially, but we have to
lookup the prefix map to get the aggregation point information for the peers
after we got the whole map.

> 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, 

I don't think it is necessary to have this map. IMO, both CPID and map based
solution work fine with this scenario.

> > > 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.
> 
> > > anything new. If we stick with HTTP, there are already solutions 
> > > ready for use.
> > 
> > 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..."
> 

I agree we need authentication. And I would agree with encryption if there
is some information considered "private" : )

Haibin

---

From: Song Haibin <[email-masked]>
Date: Wed, 23 Dec 2009 17:39:03 +0800

Hi Enrico,

I will agree with encryption if there is some information specified in the
ALTO protocol considered "private" as you enumerated : )

BR,
Haibin

> From: Enrico Marocco [mailto:[email-masked]] 
> Sent: Friday, December 18, 2009 5:11 PM
> To: Song Haibin
> Cc: 'Richard Alimi'; [email-masked]
> Subject: Re: [alto] 
> Newdraftnotification:draft-wang-alto-privacy-load-analysis-00
> 
> Song Haibin wrote:
> > encrypt the ALTO information.
> 
> No, wait, there's a bug in this reasoning. Encryption is 
> still very necessary to preserve user privacy, i.e. to let an 
> ALTO server provide a user with information the user 
> themselves may consider confidential (e.g. their own 
> uplink/downlink capacity). But of course if the user is 
> willing to redistribute even such potentially-confidential 
> information, there is no means for the server to prevent that.
> 
> --
> Ciao,
> Enrico
>

---

From: "Xiong Miao" <[email-masked]>
Date: Thu, 31 Dec 2009 14:33:54 +0800

The term "useful" here does not mean any economic price but technically. I think those cases that someone sells the information to another for high price is out of our discussions. This is just a cheating problem and it may be prevented by some mechanisms(maybe we can take into account). 
The term "useful" meaning for client is that it can help client for improving performance or traffic optimization.However clients may lie and ask more than what they really need and it can be hard to tell if they are lying(maybe client application-classification is good choice, one kind of application needs some fixed or less amount of "useful" information for it, some like access-control mechanism). This all can be considered in ALTO protocol.

2009-12-31 

熊淼 Xiong Miao

发件人： Richard Alimi 
发送时间： 2009-12-22  22:58:54 
收件人： Xiong Miao 
抄送： Enrico Marocco; [email-masked]; standardMINE 
主题： Re: [alto] New draft notification:draft-wang-alto-privacy-load-analysis-00