Internet Engineering Task Force Alexandre Cassen
Internet-Draft Freebox S.A.
Expires: September 27, 2006 March 27, 2006
Access Right Distribution Protocol (ARDP)
<draft-cassen-access-right-distribution-protocol-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a protocol to securely distribute channel
access rights to TVoDSL customers using multicast over a national
backbone. The protocol typically runs on DSLAM or any other piece of
equipments to locally store owned customers TV channel access right.
This design provides access control at edge level.
Cassen Expires September 27, 2006 [Page 1]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
Table of Contents
1. Introduction .............................................. 2
1.1. Scope ................................................. 3
1.2. Definitions ........................................... 3
2. ARDP Overview ............................................. 5
2.1. Interface with routing stack .......................... 6
2.2. Confidentiality and security considerations ........... 6
2.3. Global Operation workflow ............................. 7
3. Multicast Protocol Part ................................... 8
3.1. IP/UDP packet field descriptions ...................... 8
3.2. ARDP Packet Format .................................... 9
3.3. Operator Right message format ........................ 11
3.4. Sevice ID message format ............................. 12
3.5. Client ID message format ............................. 13
3.6. Unencrypted Timeslot message format .................. 14
4. Unicast Protocol Part .................................... 14
5. ARDP Server .............................................. 15
6. DSLAM ARDP Client Operations ............................. 16
6.1. Initialize State ..................................... 16
6.2. Learning State ....................................... 17
7. Sending and receiving ARDP datagram ...................... 17
7.1. Sending .............................................. 18
7.2. Receiving ............................................ 18
8. Acknowledgments .......................................... 18
9. References ............................................... 18
10. Editor s Address ......................................... 18
11. Full Copyright Statement ................................. 19
Cassen Expires September 27, 2006 [Page 2]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
1. Introduction
Standard digital TV security models are based on smartcard
intelligence at the end user Set-Top-Box side. We will not present
global goal and design of Conditional Access System since this is not
the scope of this document. We can simply remind that digital pay TV
is based on such a system where EMM (Entitlement Management Message),
an encrypted message, provides private conditional access information
concerning the broadcast services one viewer is allowed to receive.
The challenge of such an architecture is to provide strong
cryptographic systems to protect EMM messages against piracy since
EMM are stored directly into the Set-Top-Box/smartcard. If this
system can be considered as good for broadcasting where upstream (on
Set-Top-Box side) has high latency, this design can be enhanced for
upstream low latency network such as xDSL.
The very first security consideration rely more on trust edge network
or any routing equipements and reduce end user Set-Top-Box
intelligence/complexity. xDSL network and architecture provide a way
to dissociate Conditionnal Acces and video content protection. While
stream can still use standard DVB-CSA scrambling design, EMM
equivalent can be stored into edge routing equipment. Set-Top-Box is
considered as hostile equipement and the idea is to reduce to the max
the action it may have. For services like TVoDSL, this design offers
a secure conditional access design by physically dissociating both
security components. Stream access is controled during stream
subscribtion stage. The Set-Top-Box simply requests for a video
stream and the edge equipment grants or not access according to its
local access database (local right cache).
The challenge for now is to find a secure and scalable way to
populate edge equipments access database. We can be inspired from the
broadcasting model by using multicast transmission to distribute
access rights over xDSL backbone. The following document will present
a protocol used on top of IP to securely distribute those access
rights.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
The IESG/IETF take no position regarding the validity or scope of any
intellectual property right or other rights that might be claimed to
pertain to the implementation or use of the technology, or the extent
to which any license under such rights might or might not be
available. See the IETF IPR web page at http://www.ietf.org/ipr.html
for additional information.
Cassen Expires September 27, 2006 [Page 3]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
1.1 Scope
The remainder of this document describes the features, design goals,
and theory of operation of Access Right Distribution Protocol - The
message format, protocol processing rules and state machine that
guarantee safe and secure operations.
1.2 Definitions
FSM Finite State Machine. Coming from Discrete
Mathematics scheme. It defines the structure
which handles each state and state
transitions.
ARDP Backbone A Wide Area Network made of thousands of
ARDP clients. For xDSL network architecture,
the word ARDP client refers to a DSLAM ARDP
Client. ARDP backbone is typically a private
network.
DSLAM ARDP Client A Software component running ARDP protocol on
network edge routing equipments. It is
responsible for DSLAM local right cache
management and is interacting with Master ARDP
Server. It stores all Operator Assigned MCAST
group, associated security elements (RSA
public key) and customer Access Right.
Assigned MCAST group ISP broadcasting on TVoDSL is using multicast
over ethernet as streaming vector. It is
responsible for multicast routing and network
architecture. For each TV Operator with a
point of presence in ISP network, a multicast
network IP range is assigned. Each TV Operator
is in charge of distributing ARDP right for
this multicast ip range to ARDP backbone.
TV Operator An operator is in charge of multicast content
streaming. Each TV Operator is also in charge
of distributing ARDP right for its assigned
multicast ip range over ARDP backbone.
Operator ARDP Server Each TV Operator stores an RSA keypair and
uses RSA private key to sign all ARDP protocol
datagrams sent to ARDP Backbone. The RSA
public key is exported to all DSLAM ARDP
Clients.
Cassen Expires September 27, 2006 [Page 4]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
Master ARDP Server A server running ARDP protocol and acting as
root authority. This server distributes
ClientID over ARDP backbone and forwards ARDP
requests to TV Operators ARDP servers. It
manages ClientID flooding, unencrypted
Timeslot flooding, channel flooding and any
ARDP right for MCAST group it may manage.
ClientID An abstraction modelizing association between
customer Identification number and physical
IP address (or MAC address or phone number).
Each IP address (or MAC or phone number) can
have multiple ClientID, each one is unique to
each TV Operator namespace.
Access Right An abstraction modelizing a customer
conditional access on a specific channel.
It determines whether or not a ClientID
can access a specific channel.
Unencrypted TimeSlot An abstraction modelizing a global Access
Right for all ClientID to a specific
channel and during a specific validity time.
2. ARDP Overview
We can localize each ARDP architecture component on the following
diagram :
+-----------+ +-----------+
| | | |
__________| OP_ARDP_1 |________| OP_ARDP_2 |________________
/ | | | | \
/ +-----------+ +-----------+ \
| |
| ARDP Backbone |
| |
\ +----------+ +---------+ +---------+ +---------+ /
\__| Master |_____| DSLAM 1 |___| DSLAM 2 |..| DSLAM n |___/
| ARDP | +---------+ +---------+ +---------+
+----------+
Master ARDP : Master ARDP Server
OP_ARDP_1 : TV Operator 1 running Operator 1 ARDP Server.
OP_ARDP_2 : TV Operator 2 running Operator 2 ARDP Server.
DSLAM 1 : DSLAM 1 running DSLAM 1 ARDP Client
DSLAM 2 : DSLAM 2 running DSLAM 2 ARDP Client
DSLAM n : DSLAM n running DSLAM n ARDP Client
Cassen Expires September 27, 2006 [Page 5]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
ARDP is a protocol running over multicast and targetting
centralization of access right flooding. The global operating mode is
a multicast Client/Server, respectively localized on DSLAM and Master
ARDP Server/Operator ARDP Server. The Master ARDP Server handles
massive access right, ClientID and Unencrypted Timeslot flooding.
All customer ClientID are flooded from Master ARDP Server. All
customer access right are flooded from Operator ARDP Server. Each
Operator ARDP Server is flooding access right for Assigned MCAST
group. DSLAM ARDP Client is then filtering received multicast
datagrams to only store access right, for customers it hosts.
ARDP finality is then to maintain access right cache integrity on
DSLAM ARDP Client side and to offer any TV Operator the ability to
flood directly access right over ARDP Backbone. An RSA signature is
used to guaranty protocol datagram authenticity and integrity using a
1024bits RSA keypair. Each ARDP Server stores its RSA private key and
DSLAM ARDP Client stores all RSA public key. A Public Key
Infrastructure can be used to distribute RSA pubkey, we will not
detail this part since it is out of the scope of this document.
2.1. Interface with routing stack
In TVoDSL architecture, stream subscription is most of the time done
through IGMP (as described in [RFC3376]) since streaming is done via
multicast. ARDP operates close to edge routing equipment stack at
IGMP level. The diagram below shows general ARDP operations :
+--------------------------------------------------------+
| DSLAM Routing Software |
| +--------------+ |
| | Access Right | |
| | Cache | |
| +------------------------+ +------^-------+ |
| | CORE Routing Stack | | |
| | +------+ +------v-----+ |
| | | IGMP |<------>| ARDP Stack | |
| +-----------------+--^---+ +------------+ |
+------------------------|-------------------------------+
|
|
+------v------+
| Set-Top-Box |
+-------------+
When the Set-Top-Box requests for a channel, it generates an IGMP
Join request caught by DSLAM IGMP stack. Before processing the stream
subscription operation, IGMP stack requests authorisation to ARDP
Stack. If access is granted by ARDP then IGMP stack proceeds to
Cassen Expires September 27, 2006 [Page 6]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
perform stream subscription or any multicast routing related task.
2.2. Confidentiality and security considerations
First of all, ARDP operates in a separate/dedicated network plane
without any physical link with the Set-Top-Box network. It is
mandatory to separate the ARDP network plane from the Set-Top-Box
network plane. Only edge routing equipments can access the ARDP plane
and Set-Top-Box one but without any routings nor forwardings rules
between both planes.
ARDP protocol is disgned to operate in a multi-operator fashion. From
the networking point of view it is running multiple multicast sending
sources at a time. One of its goales is to give full access to a TV
Operator on streams it is responsible for. Master Operator provides
"Assigned MCAST group" to each TV Operator. Using ARDP, a TV Operator
can manage Access Right through head-end in realtime using
flexibility of multicast.
ARDP architecture defines a hierarchy between Master Operator and TV
Operator. On the one hand Master Operator, formerly a TVoDSL
operator owning network infrastructure, has a role of arbitration and
root authority :
- Distributes all TV Operator ClientID over ARDP Backbone. Each TV
Operator has its own namespace for ClientID but the association
between a TV Operator ClientID and a physical client (customer)
identification (IP address, MAC address, phone number, ...) is
only known by Master Operator.
- Assigns multicast IP range to TV Operator and distributes this
association to ARDP Backbone. Each TV Operator will be able to
assign Access Right to the multicast groups provided by the
Master Operator.
- Requests TV Operator ARDP Server to distribute Access Right to
a particular ClientID.
On the other hand, TV Operator is a supervisor authority for
distributing ARDP Access Right to Assigned MCAST group :
- Handles Master Operator ClientID request by flooding in response
the associated ARDP Access Right.
- Distributes Unencrypted Timeslot and Access Right.
Cassen Expires September 27, 2006 [Page 7]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
2.3. Global Operation workflow
The following diagram gives the general workflow of ARDP protocol.
+-----------+ +-----------+
| | | |
__________| OP_ARDP_1 |________| OP_ARDP_2 |________________
/ +---->| | | | \
/ | +-----------+ +-----------+ \
| | \ |
| | \(e) |
| | \ |
| |(d) ^ ^ v ARDP Backbone |
| | / / |
| | /(c) /(b) |
| | / / |
\ +----------+ +---------+ +---------+ +---------+ /
\__| Master |_____| DSLAM 1 |___| DSLAM 2 |..| DSLAM n |___/
| ARDP | +---------+ +---------+ +---------+
+----^-----+ |
+----------------+
(a)
This sample configuration illustrates ARDP operation workflow from ARDP
protocol boot-up state (a) through ClientID and right flooding stage
(b), (c), (d) and (e). Protocol operates at both Multicast and
Unicast levels such as follows :
(a) Unicast message : DSLAM 1 informs Master ARDP Server of its
initialization state. It requests for ClientID and right
flooding.
(b)+(c) Multicast message : Master ARDP Server floods ClientID
and Access Right for each customer hosted by DSLAM 1.
(d) Unicast message : Master ARDP Server requests right flooding
to each remote Operator ARDP Server for given ClientID in
each TV Operator ClientID namespace.
(e) Multicast message : In response to (d) each Operator ARDP
Server floods Access Right requested by Master ARDP Server.
3. Multicast Protocol Part
ARDP protocol operates at multicast level and runs over UDP.
ARDP packet are encapsulated in IP/UDP packets and sent to a
routed multicast IPv4 address over ARDP Backbone. Multicast offers
a many-to-many entities discussion. Using UDP encapsulation offers
Cassen Expires September 27, 2006 [Page 8]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
the ability to run multiple ARDP plane using the same multicast
routing ressource.
3.1. IP/UDP packet field descriptions
For the current ARDP version 1 there is no layer3/4 restrictions.
Multicast TTL must be set with a proper value permitting
backbone traversal.
3.2. ARDP header packet format
Each ARDP protocoal datagram starts with ARDP header as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Hl | Msg Type | Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count Msg | Auth Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Operator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Message Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| Operator Signature |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.1. Version field
Specifies the ARDP protocol version a packet belongs to. Our current
document describes Version 1.
3.2.2. Header Length field
Specifies the length of the ARDP header.
3.2.3. Message Type field
Specifies the type of ARDP packet data part following the ARDP
header. ARDP message types are :
- 0x01 : Operator Right message
- 0x02 : ServiceID message
- 0x03 : ClientID message
- 0x04 : Unencrypted Timeslot message
Cassen Expires September 27, 2006 [Page 9]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
3.2.4. Size field
Specifies the total size of the ARDP packet including ARDP header and
message data.
3.2.5. Count Messages field
Specifies the number ARDP message data included in the global ARDP
packet.
3.2.6. Authentication Type field
Specifies kind of authentication used to sign the ARDP packet.
Mandatory Authentication Type are :
- 0x01 : No authentication signature
- 0x02 : Use HMAC-MD5-96bit signature as described in [RFC2104]
- 0x03 : Use RSA 1024bit signature as described in [RFC2437]
3.2.7. Source Operator ID field
Specifies the TV Operator origin of the ARDP packet. This gives ARDP
Client side the possibility to select authentication to be used as
sanity check, validity of message data regarding TV Operator Assigned
MCAST group. Formerly an Operator ID is a 32bit value identifying in
a unique way any TV Operator. This can be an IPv4 IP address used as
point of presence in ARDP Backbone.
3.2.8. Global Message Data field
For this first version of ARDP protocol, this field is only used
during ClientID flooding to indicate which TV Operator the ClientID
flooding message belongs to in order to identify TV Operator ClientID
namespace.
3.2.9. Operator Signature field
Includes the digital signature (if used) to authenticate ARDP packet.
On ARDP Client side, Source Operator ID field indicates which TV
Operator secret or key to be used. Depending on authentication type
use, this field is 96bit length long for HMAC-MD5-96bit signature and
1024bit length long for 1024bit RSA signature.
Cassen Expires September 27, 2006 [Page 10]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
3.3. Operator Right message format
This message type refers to a unary Access Right and responds to the
following message format :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Validity | End Of Validity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.1. Command field
Specifies whether to add or delete a right. Valid commands are :
- 0x01 : Add a new right
- 0x02 : Delete a right
3.3.2. Service ID field
Specifies a TV Operator service, formerly these are routings pieces of informations
identifying a TV Operator channel.
3.3.3. Client ID field
Specifies the ClientID this right refers to.
3.3.4. Begin Validity field
Specifies the beginning of validity date.
3.3.5. End Of Validity field
Specifies the end of validity date. This expiration date prevents
from storing expired access rights.
Cassen Expires September 27, 2006 [Page 11]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
3.4. Service ID message format
This message type refers to a unary TV Operator service description and
responds to the following message format :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unicast Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fallback Multicast Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fallback Unicast Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast TTL | Fallback Multicast TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Service String |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4.1. Service ID field
Specifies a unique ID into the TV Operator namespace.
3.4.2. Version Code field
Specifies a version number to identify the service plan this Service
ID belongs to.
3.4.3. Multicast Group field
Specifies an IPv4 Multicast group into the Assigned MCAST group
range.
3.4.4. Unicast Source field
Specifies an IPv4 IP address source of streaming refering to
Multicast Group field. This is useful information when using SSM for
wide-area multicast as described in [RFC3569].
Cassen Expires September 27, 2006 [Page 12]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
3.4.5. Fallback Multicast Group field
Specifies an IPv4 multicast group into the assigned MCAST group
range.
3.4.6. Fallback Unicast Source field
Specifies an IPv4 IP address source of streaming refering to Fallback
Multicast Group field. This is useful information when using SSM for
wide-area multicast.
3.4.7. Multicast TTL field
Specifies the refresh rate in millisecond for next ARDP right polling
from edge routing network equipment. DSLAM periodically poll ARDP
right cache to ensure Access Right validity during stream
subscription life. This field refer to Multicast group field.
3.4.8. Fallback Multicast TTL field
Specifies the refresh rate in millisecond for next ARDP right polling
done by the edge routing network equipment. DSLAM periodically polls
ARDP right cache to ensure Access Right validity during stream
subscription life. This field refers to Fallback Multicast group
field.
3.4.9. Service String field
Specifies a String as comment for the Service ID.
3.5. Client ID message format
This message type refers to a unary ClientID association and responds
to the following message format :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSLAM Client IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each customer owns a unique ClientID into each TV Operator namespace.
DSLAM Client IP Address is unique to each TV Operator namespace.
Cassen Expires September 27, 2006 [Page 13]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
3.5.1. Client ID field
Specifies the ClientID this association refer to.
3.5.2. DSLAM Client IP Address field
Specifies the physical IP Address.
3.6. Unencrypted Timeslot message format
This message type refers to a unary unencrypted timeslot and responds
to the following message format :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Time Slot | End Time Slot |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.6.1. Command field
Specifies whether to add or delete an Unencrypted Timeslot. Valid
commands are :
- 0x01 : Add a new Timeslot
- 0x02 : Delete a Timeslot
3.6.2. Service ID field
Specifies a unique ID into the TV Operator namespace.
3.6.3. Begin Time Slot field
Specifies the begin TimeSlot validity date.
3.6.4. End Time Slot field
Specifies the end of TimeSlot validity date. This expiration date
prevents from storing expired Time Slot.
4. Unicast Protocol Part
ARDP Unicast datagrams are used by DSLAM ARDP Client to request ARDP
Master Server for right cache feeding. Those messages are using
Cassen Expires September 27, 2006 [Page 14]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
general ARDP protocol header presented in section 3.2. Authentication
is not mandatory since flows are local to private ARDP Backbone from
DSLAM to Master ARDP Server. Unicast messages are vehiculed over
IP/TCP and are :
- 0x01 : DSLAM Access Right populate request
- 0x02 : DSLAM ClientID populate request
- 0x03 : DSLAM ServiceID populate request
DSLAM ARDP Client fills the Global Message Data field with its ID.
Formerly it used the IPv4 IP Address provided for ARDP Backbone point
of presence.
5. ARDP Server
The global goal of ARDP architecture is to focus protocol complexity
onto the ARDP server instead of ARDP client. As previously explained,
ARDP protocol reduce Set-Top-Box complexity by deporting conditional
access to edge routing equipment. The same statement is used for ARDP
Server. It is responsible for ARDP protocol messages flooding and
scheduled flooding jobs. In this many-to-many networking scheme it is
convenient to centralize complexity onto the server side for
maintenance and scalability reasons.
ARDP Server MUST perform the following operations :
- MUST permanently flood TV Operator Service ID plane. If new
Service ID plane is flooded then send all Access Right
(of this TV Operator).
- If ARDP server is MASTER ARDP Server then:
o Only accept Unicast requests from DSLAM ARDP Client
o Only send Unicast request to remote TV Operator
ARDP Server
Else
o Only accept unicast requests from Master ARDP Server
Endif
- MUST periodically flood whole Access Right
- MUST sequencely flood ClientID before any Access Right
related.
Cassen Expires September 27, 2006 [Page 15]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
6. DSLAM ARDP Client State Transition Diagram
ARDP Client side manages local access right cache. Its FSM
is divided into 2 states as follows :
+------------------+ +------------------+
| |------------------------>| |
| Initialize | | Learning |
| |<------------------------| |
+------------------+ +------------------+
6.1. Initialize State
The purpose of this state is to boot up ARDP protocol. While in this
state, ARDP client MUST perform the following operations :
- If Authentication is used then MUST load TV Operators secrets
for HMAC-MD5-96bit authentication or load RSA public key if
RSA authentication is used.
- MUST wait until TV Operator Service IDs are received
- MUST connect to ARDP Master Server only to request for
ClientID flooding.
- If ClientID table is empty then:
o Re-schedule a new ClientID flooding request to
Master ARDP Server.
o If ClientID table still empty until max_retry then:
. Disable scheduling ClientID flooding retry.
. Re-schedule a new ClientID request with a longer
delay
Endif
Else
o Schedule Access Right flooding request to Master
ARDP Server.
Endif
- If Access Right Table is empty then:
o Re-schedule a new Access Right flooding request to
Master ARDP Server.
Cassen Expires September 27, 2006 [Page 16]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
o If Access Right table still empty until max_retry then:
. Disable scheduling Access Right flooding retry.
. Re-schedule a new Access Right request with a longer
delay
Endif
Else
o Transit to Learning state.
Endif
In this pseudo code we can note that "Re-schedule" can mean inhibit
flooding request since Master ARDP Server can schedule any request
since it has the knowledge of the whole ARDP Backbone point of
presence.
6.2. Learning State
The purpose of this state is to enter a long time listening stage.
While in this state, ARDP client MUST perform the following
operations :
- When receiving ClientID message, if ClientID is refering to a
local DSLAM IP Address then store this new correspondance.
- When receiving ClientID message then MUST remove any Access
Right associated if already exists.
- When receiving Access Right message then MUST replace any Access
Right related to the same ClientID/ServiceID.
- When receiving new ServiceID, means when "Version Code" field is
different from current ARDP Client Service version code then
remove any Access Right related to the TV Operator source of the
message.
- If Access Right Table is empty then:
o Transit to Initialize state.
Endif
Cassen Expires September 27, 2006 [Page 17]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
7. Sending and receiving ARDP datagram
7.1. Sending
Any ARDP sending source MUST perform the following operations:
- MUST fill ARDP protocol header in accordance with protocol
specification in section 3.
- If Authentication is used sign ARDP datagram.
7.2. Receiving
Any ARDP received datagram MUST perform the following operations:
- MUST perform sanity check over datagram to conform ARDP header
elements with real data content.
- If Authentication is used then:
o MUST verify HMAC-MD5-96bit or RSA signature. If signature
is not valid then:
. Drop incoming datagram.
Endif
Endif
8. Acknowledgments
Funding for the RFC Editor function is currently provided by the
Internet Society.
9. References
[HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", Work in Progress.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[RFC2437] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner,
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
Cassen Expires September 27, 2006 [Page 18]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
[RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
10. Editor s Address
Alexandre Cassen
Freebox S.A.
8, Rue de la Ville l Eveque
75008
FR
Phone:+33 1 73 50 25 00
EMail: acassen<at>freebox<dot>fr
11. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
Cassen Expires September 27, 2006 [Page 19]
Internet-Draft Access Right Distribution Protocol (ARDP) March 2006
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Cassen Expires September 27, 2006 [Page 20]