The whole question of whether various uses of peer-to-peer networks should be denied access to the ALTO service is not one that impacts the design of the ALTO protocol in any meaningful way.
While I won't go so far as to say that these sorts of debates about the scope of our work are counterproductive, they certainly yield diminishing returns after a certain point, and I believe we're at that point if we haven't passed it already. I think it has been amply substantiated that the ALTO service is poorly positioned to enforce policy, largely due to the fact that the large installed base of applications will use ALTO only if it provides an ostensible benefit. Similarly, any ALTO service can elect not to handle requests from particular sources at its discretion, but I sincerely doubt we have any authority to influence that decision. Our job here is to remain focused on the technical design of this optimization, not on the various policy issues that arise in some use cases of the larger system. Commingling them will almost certainly render this work unsuitable for most applications. Jon Peterson NeuStar, Inc. On 5/4/09 11:26 AM, "Gyorgy Dan" <[email protected]> wrote: > Greg, > > Personally, I do not see why the approach > --- > If "BT, eMule,..." are distributing pirated content, I would argue they > should not qualify for ALTO service." > --- > would be beneficial with respect to C1. My reasoning is the following, > please correct me if I am missing something: > > On the one hand, BT, eMule and all other applications are doing quite > fine without the ALTO service today in the Internet: they can locate > content and they can locate peers, unfortunately, mostly in a network > unaware manner. Consequently, denying them access to the ALTO service > would not make the distribution of illegal content impossible, probably > not even more difficult. > > On the other hand, if we believe the statistics that were quoted on this > mailing list a few weeks ago (something like 99% or more of file sharing > traffic > is illegal content) then excluding illegal content from the ALTO service > will penalize the ISPs significantly (in case they are the ones > operating the ALTO service), as most of the content will be distributed > without any traffic optimization. Unless non-ALTO compliant traffic will > be blocked/throttled, but that is hopefully not part of the vision. > > György > > > > DePriest, Greg (NBC Universal) wrote: >> Using your three categories of content, my concern is "C1: Consumer >> content (e.g., Movie X)." Of course, it's much broader than movies and >> includes music, software, games, etc. -- essentially the copyrighted >> content that's freely traded via P2P today without the copyright owner's >> permission. >> >> I call it "content protection" while Richard Bennett calls it "rights >> management." Others have suggested content creators simply need stronger >> DRM. None of these characterizations quite fits. >> >> Let me explain: Content creators are concerned with content that's gone >> "into the wild" or "over the fence." It could be a camcorded movie, a >> DVD rip, or unprotected music. >> >> The issue isn't DRM for the content may or may not have been wrapped in >> DRM originally (a camcorded movie would not be, for example). And it's >> not quite "rights management" as it's difficult to manage rights when >> content is already freely available. >> >> What it is possible to do is to discriminate against pirated content and >> that's my goal (denying ALTO access, e.g.). >> >> I'm not sure of your view other than on Friday you noted "I believe that >> some 'content integrator' which fetch the same content from multiple >> sources (e.g., http/ftp, BT, eMule, their own network), search and index >> contents across networks this way." >> >> If "BT, eMule,..." are distributing pirated content, I would argue they >> should not qualify for ALTO service. >> >> * * * * >> >> Originally I thought hashes could be used to identify pirated content >> and discriminate against it. Nicholas points out that UUIDs are more >> likely to be used at the lowest level for the reasons contained in his >> response from last week. >> >> Satish noted that "All the ALTO service needs to be able to do is >> accommodate standards based authentication and authorization mechanisms. >> The provider of the ALTO service decides what a client with right >> credentials receives in responses and what other clients receive." >> >> Maybe that's right. I'm not sure. >> >> The question that does come to mind is who operates the ALTO service? >> >> In any event, did I answer your question? >> >> -----Original Message----- >> From: Y. Richard Yang [mailto:[email protected]] >> Sent: Saturday, May 02, 2009 4:59 PM >> To: Richard Bennett >> Cc: Satish Raghunath; Paul Jessop; [email protected]; Nicholas Weaver; >> alto; DePriest, Greg (NBC Universal) >> Subject: Re: [alto] The origins of the piracy debate... >> >> I feel that it becomes increasingly difficult to follow the discussion >> on "content protection": >> >> Q1: What "content" are we referring to? >> Q2: What protection (attacks) are we referring to? >> >> For Q1, I can see at least three types of contents: >> C1: Consumer content (e.g., Movie X); >> C2: Content availability information (e.g., servers A/B (peers D/E, or >> caches F/G) can provide (part of) Movie X); >> C3: Network information (e.g., the network path from A to C is >> good/bad). >> >> Do I miss any other potential interpretations? >> >> For protection, I assume we are referring to access control to >> aforementioned contents. >> >> Realistically, I do not see how ALTO is in a position to protect C1. See >> >> HDCP to see >> the complexity. Please correct me if I miss anything. It will be a quite >> >> challenging issue >> and ALTO will be just one component in a much bigger picture. >> >> It seems that we are referring to C2 and C3. Do I understand the >> situation correctly? >> >> For C2, personally, I do not think it should belong to the *basic* ALTO >> services. >> It is a content discovery mechanism. ALTO is not in a position to block >> existing >> discovery mechanisms (e.g., DHT, tracker sites). It is debatable that it >> >> should belong >> to ALTO, which is mainly focused on network/application interface, at >> least according >> to my understanding. >> >> For C3, it appears that we can do something so that ALTO does not help >> with >> accelerating downloading of "illegal" content. For example, an ALTO >> server >> provides C3 only to a subset of clients (or gives different >> information). The >> selection of the subset is based on some access control policy. One >> possibility >> is that a client presents some access token/credential (Satish's >> approach). >> One issue is that who has the authority to issue the access credentials >> that can >> be acceptable by an ALTO server. Remember that we are talking about a >> large number of ALTO servers (e.g., one ALTO server for each ISP). >> At the same time, I image that there can be many sources who can >> "voucher" >> that a content (C3) is "legal" and the network should help. An >> alternative >> is that access to C3 is based on a blacklist approach (default is allow, >> >> and >> allows deny). But this also has substantial technique/trust/security >> challenges. >> >> Clearly, "content protection" is not an issue that we (i.e., I) >> understand well. >> >> Richard >> >> >> Richard >> >> Richard Bennett wrote: >> >>> That's the way I see it as well. >>> >>> RB >>> >>> Satish Raghunath wrote: >>> >>>> It is not clear to me why the ALTO service needs a content ID to aid >>>> >> something like content protection. (I take content ID to mean a unique >> identifier of the object that the client is trying to download.) >> >>>> ALTO requirements already provide for authorized access to the ALTO >>>> >> service: >> >>>> REQ. ARv00-27: The ALTO client protocol MUST support mechanisms >>>> >> for >> >>>> mutual authentication and authorization of ALTO clients and >>>> >> servers. >> >>>> In the particular case of content protection, I can think of >>>> >> something like this: >> >>>> | >>>> |----> Future mechanisms >>>> | >>>> +---------------+| Send req +----------------+ >>>> | || ....> | Content-aware | >>>> | ALTO client |.............| services (like | >>>> | | <.... | protection) | >>>> +-------+-------+ Get auth +----------------+ >>>> | info + possibly >>>> ALTO proto| peer list >>>> | >>>> +-------+---------+ >>>> | ALTO server | >>>> | conditions | >>>> | service on auth | >>>> | information | >>>> +-----------------+ >>>> >>>> >>>> All the ALTO service needs to be able to do is accommodate standards >>>> >> based authentication and authorization mechanisms. The provider of the >> ALTO service decides what a client with right credentials receives in >> responses and what other clients receive. >> >>>> Thanks, >>>> Satish >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On Behalf >>>>> >> Of >> >>>>> Nicholas Weaver >>>>> Sent: Thursday, April 30, 2009 2:59 PM >>>>> To: DePriest, Greg (NBC Universal) >>>>> Cc: Paul Jessop; Nicholas Weaver; alto; [email protected] >>>>> Subject: Re: [alto] The origins of the piracy debate... >>>>> >>>>> >>>>> On Apr 30, 2009, at 2:19 PM, DePriest, Greg (NBC Universal) wrote: >>>>> >>>>> >>>>> >>>>>> Thanks to Enrico and Nicholas for providing additional background >>>>>> >> and >> >>>>>> explanations. >>>>>> >>>>>> The key point of disagreement seems to be that adding a content >>>>>> protection requirement to ALTO would "hugely complicate and >>>>>> >> compromise >> >>>>>> the design of >>>>>> ALTO." >>>>>> >>>>>> I'm not an expert in such matters, have very limited exposure to >>>>>> >> the >> >>>>>> area, and can't help but wonder if that is, in fact, correct. >>>>>> >>>>>> Was there a serious investigation or did someone simply do a >>>>>> back-of-the-envelope analysis. >>>>>> >>>>>> >>>>> For me, its "Intuition backed up by a threat analysis and usage >>>>> >> cases": >> >>>>> We have legitimate uses which requires ID churn: its the only way to >>>>> guarantee that a rebalancing is fresh. Especially since nodes churn >>>>> all the time, and ALTO may not have notification when nodes leave. >>>>> >>>>> We have legitimate uses which require IDs to be arbitrary (rather >>>>> >> than >> >>>>> representative hashes): ALTO is not just for file distribution, but >>>>> other P2P optimization (eg, optimizing for low latency for DHTs) >>>>> >> where >> >>>>> hashes don't have meaning. ALTO doesn't want to deal with >>>>> >> particular >> >>>>> P2P protocols, which all may have different representations of what >>>>> data or blocks are. And doesn't want to deal with colliding >>>>> namespaces from different P2P programs. Thus defining ID as a UUID >>>>> >> or >> >>>>> other opaque identifier means ALTO doesn't have to deal with these >>>>> problems. >>>>> >>>>> We have legitimate uses which require IDs to be creatable at-will by >>>>> any party: Otherwise, ALTO becomes an admission only system which >>>>> limits utility. >>>>> >>>>> >>>>> Yet all three decisions (allowing churn, opaque-data IDs, at-will ID >>>>> creation) and there becomes an easy countermeasure to ANY system >>>>> predicated on "block bad IDs", as long as that system has a slower >>>>> response time than the P2P network you are trying to prevent >>>>> optimizing its communication, and you can't do "only allow good IDs" >>>>> if IDs are creatable at-will by any party. >>>>> >>>>> And "if a defense has a trivial countermeasure, don't bother >>>>> >> deploying >> >>>>> it". >>>>> >>>>> Thus this means the only way to make ALTO "content protecting" is to >>>>> remove one of those three constraints. But all three features are >>>>> very valuable in a localization service. >>>>> >>>>> >>>>> >>>>> Additionally, there is a large bias in the network community in >>>>> general to be "content neutral". Any time you cease to be content >>>>> neutral on the technical level, it must necessarily impose >>>>> >> constraints >> >>>>> and costs on the system. >>>>> >>>>> _______________________________________________ >>>>> alto mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/alto >>>>> >>>>> >>>> _______________________________________________ >>>> alto mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/alto >>>> >>>> >> ------------------------------------------------------------------------ >> >>> _______________________________________________ >>> alto mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/alto >>> >>> >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
