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
