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
