[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06
Internet Engineering Task Force Alexandre Cassen
Internet-Draft Freebox S.A.
Expires: November 22, 2007 May 21, 2007
Access Right Distribution Protocol (ARDP)
<draft-cassen-access-right-distribution-protocol-02.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 November 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a protocol to securely distribute service
access rights to IPTV customers using multicast over a national
backbone. The protocol typically runs on any piece of equipments to
locally store owned customers TV service access right. This design
provides access control at edge level.
Cassen Expires November 22, 2007 [Page 1]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
Table of Contents
1. Introduction .............................................. 3
1.1. Scope ................................................. 4
1.2. Definitions ........................................... 4
1.3. ARDP Multicast operations ............................. 5
2. ARDP Overview ............................................. 6
2.1. Interface with routing stack .......................... 7
2.2. Confidentiality and security considerations ........... 7
2.3. Global Operation workflow ............................. 9
3. Multicast Protocol Part ................................... 9
3.1. IP/UDP packet field descriptions ..................... 10
3.2. ARDP Packet Format ................................... 10
3.3. CP Access Right message format ....................... 13
3.4. CP Sevice ID message format .......................... 13
3.5. Client ID message format ............................. 15
3.6. CP Unencrypted Timeslot message format ............... 16
4. Unicast Protocol Part .................................... 16
5. ARDP Server .............................................. 17
6. NE ARDP Client State Transition Diagram .................. 18
6.1. Initialize State ..................................... 18
6.2. Learning State ....................................... 19
7. Sending and receiving ARDP datagram ...................... 20
7.1. Sending .............................................. 20
7.2. Receiving ............................................ 20
8. Acknowledgments .......................................... 21
9. References ............................................... 21
10. Editor s Address ......................................... 21
11. Full Copyright Statement ................................. 22
Cassen Expires November 22, 2007 [Page 2]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
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. Networking architecture provides 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 no trust equipement and the idea is to reduce to the
max the action it may have. Set-Top-Box intelligence and operations
on security side can be emulated which open the door to reverse
engineering. For services like IPTV, 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 a network 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
Cassen Expires November 22, 2007 [Page 3]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
for additional information.
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
In this document we will use same Definitions/Abbreviations as
present in [AAA] document.
FSM Finite State Machine. Coming from Discrete
Mathematics scheme. It defines the structure
which handles each state and state
transitions.
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 CP namespace.
Access Right An abstraction modelizing a customer
conditional access on a specific ServiceID.
It determines whether or not a ClientID
can access a specific ServiceID.
CP Content Provider is in charge of multicast
content streaming. Each CP is also in charge
of distributing Access Right for its assigned
multicast ip range over ARDP backbone.
ARDP Backbone A Wide Area Network made of lot of ARDP
clients.
NSP Network Service Provider owns ARDP Backbone
and is in charge of any administration related
operations over it.
NE Network Equipment is runing an ARDP Client and
is storing Access Right. It controls and
maintains multicast subscription.
ARDP Client A Software component running ARDP protocol on
Cassen Expires November 22, 2007 [Page 4]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
network edge routing equipments. It is
responsible for NE local right cache
management and is interacting with NSP ARDP
Server. It stores all CP Assigned MCAST
group, associated security elements (RSA
public key) and customer Access Right.
Assigned MCAST group CP is using multicast over ethernet as
streaming vector. It is responsible for
multicast routing and network architecture.
For each CP with a point of presence in NSP
network, a multicast network IP range is
assigned. Each CP is in charge of distributing
ARDP right for this multicast ip range to ARDP
backbone.
CP ARDP Server Each CP 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 NE ARDP Clients.
NSP ARDP Server A server running ARDP protocol and acting as
root authority. This server distributes
ClientID over ARDP backbone and forwards ARDP
requests to CP ARDP servers. It manages
ClientID flooding, unencrypted Timeslot
flooding, ServiceID flooding and any ARDP
right for MCAST group it may manage.
Unencrypted TimeSlot An abstraction modelizing a global Access
Right for all ClientID to a specific
ServiceID and during a specific validity time.
CDS Content Delivery Services.
ServiceID An abstraction modelizing a CP pieces of
informations identifying a CP IPTV streaming
service (a multicast group).
1.3 ARDP Multicast operations
ARDP is a protocol running over multicast. ARDP design tend to create
a hierarchy between NSP and CP. NSP trust CP with PoP in its ARDP
Backbone, but for security/maintenability reasons it MUST
protect/hide its low-level topology. NSP is in charge with
administration and operations all over its backbone, each NE can
change/migrate to a different routing plane, each customer can roam
from NE to NE and consequently change their routing related elements
Cassen Expires November 22, 2007 [Page 5]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
and path (change of IP address for example). NSP is responsible to
keep accurate association between ClientID and IP Address in all CP
ClientID namespace. CP operations are CDS centralized, it manages
customer informations needed to run its business say : ClientID and
ServiceID. Multicast provides a simple and scalable answer to offer
a full and realtime distribution of Access Right to each CP. CP ARDP
Servers are a only multicast sending source while NE ARDP Client are
a only multicast receiver.
2. ARDP Overview
We can localize each ARDP architecture component on the following
diagram :
+-----------+ +-----------+
| | | |
__________| CP ARDP 1 |________| CP ARDP 2 |________________
/ | | | | \
/ +-----------+ +-----------+ \
| |
| ARDP Backbone |
| |
\ +-------+ +------+ +------+ +------+ /
\__| NSP |___________| NE 1 |___| NE 2 |..| NE n |_________/
| ARDP | +------+ +------+ +------+
+-------+
NSP ARDP : NSP ARDP Server
CP ARDP 1 : CP 1 running CP 1 ARDP Server.
CP ARDP 2 : CP 2 running CP 2 ARDP Server.
NE 1 : NE 1 running NE 1 ARDP Client
NE 2 : NE 2 running NE 2 ARDP Client
NE n : NE n running NE n ARDP Client
ARDP is targetting centralization of access right flooding. The
global operating mode is a multicast Client/Server, respectively
localized on NE and NSP ARDP Server/CP ARDP Server. The NSP ARDP
Server handles massive access right, ClientID and Unencrypted
Timeslot flooding. All customer ClientID are flooded from NSP ARDP
Server. All customer access right are flooded from CP ARDP Server.
Each CP ARDP Server is flooding access right for Assigned MCAST
group. NE 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 NE
ARDP Client side and to offer any CP 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
Cassen Expires November 22, 2007 [Page 6]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
keypair. Each ARDP Server stores its RSA private key and CP ARDP
Client stores all RSA exported 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 IPTV 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 :
+--------------------------------------------------------+
| NE Routing Software |
| +--------------+ |
| | Access Right | |
| | Cache | |
| +------------------------+ +------^-------+ |
| | CORE Routing Stack | | |
| | +------+ +------v-----+ |
| | | IGMP |<------>| ARDP Stack | |
| +-----------------+--^---+ +------------+ |
+------------------------|-------------------------------+
|
|
+------v------+
| Set-Top-Box |
+-------------+
When the Set-Top-Box requests for a ServiceID, it generates an IGMP
Join request caught by NE 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
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 equipment can access the ARDP plane
and Set-Top-Box plane; howerver no routings or forwardings rules may
exist between the two planes.
ARDP protocol is disigned 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 the goals of the protocol is to
give CP full control of Access Right for the streams it is
Cassen Expires November 22, 2007 [Page 7]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
responsible for. NSP provides "Assigned MCAST group" to each CP.
Using ARDP, a CP can manage Access Right through head-end in realtime
using flexibility of multicast.
ARDP architecture defines a hierarchy between NSP and CP. On the one
hand NSP, formerly an IPTV operator owning network infrastructure,
has a role of arbitration and root authority :
- Distributes all CP ClientID over ARDP Backbone. Each CP
has its own namespace for ClientID but the association
between a CP ClientID and a physical client (customer)
identification (IP address, MAC address, phone number, ...) is
only known by NSP.
- Assigns multicast IP range to CP and distributes this
association to ARDP Backbone. Each CP will be able to
assign Access Right to the multicast groups provided by NSP.
- Requests CP ARDP Server to distribute Access Right to
a particular ClientID.
On the other hand, CP is a supervisor authority for distributing ARDP
Access Right to Assigned MCAST group :
- Handles NSP ClientID request by flooding in response
the associated ARDP Access Right.
- Distributes Unencrypted Timeslot and Access Right.
Cassen Expires November 22, 2007 [Page 8]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
2.3. Global Operation workflow
The following diagram gives the general workflow of ARDP protocol.
+-----------+ +-----------+
| | | |
__________| CP ARDP 1 |________| CP ARDP 2 |________________
/ +---->| | | | \
/ | +-----------+ +-----------+ \
| | \ |
| | \(d) |
| | \ |
| |(c) ^ v ARDP Backbone |
| | / |
| | /(b) |
| | / |
\ +-------+ +------+ +------+ +------+ /
\__| NSP |______________| NE 1 |___| NE 2 |..| NE 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) and (d). Protocol operates at both Multicast and
Unicast levels such as follows :
(a) Unicast message : NE 1 informs NSP ARDP Server of its
initialization state. It requests for ClientID and right
flooding.
(b) Multicast message : NSP ARDP Server floods ClientID for each
customer hosted by NE 1.
(c) Unicast message : NSP ARDP Server requests right flooding
to each remote CP ARDP Server for given ClientID in each
CP ClientID namespace.
(d) Multicast message : In response to (c) each CP ARDP Server
floods Access Right requested by NSP 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 November 22, 2007 [Page 9]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source CP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Message Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| CP 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 : CP Access Right message
- 0x02 : CP ServiceID message
- 0x03 : ClientID message
- 0x04 : CP Unencrypted Timeslot message
Cassen Expires November 22, 2007 [Page 10]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
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. Sequence Number field
This 16-bit field contains a monotonically increasing counter value
managed at ARDP Server side. Each ARDP Server maintains a sequence
counter for every ARDP Message Types it may send. This sequence
number is legitimated by 2 points.
First of all, using sequence number at server side prevent against
any kind of replay attack. Even if ARDP datagram are using a
private/dedicated plane, NE will trust ARDP Server source by this
protocol provision. ARDP protocol replay attack is not intrinsec
possible since ARDP message contains validity range. If a malicious
source try to replay any previously recorded datagrams, the final
effect will just be a forced update at NE side, that will end on a no
effect injection. The benefit brought by sequence number, when used
with authenticated datagrams (HMAC-MD5-96bit or RSA), resides in the
key decision it provides to drop any incoming malicious datagram and
thus prevent against any time consuming task induced by datagram
handling.
Secondly, using sequence number in each ARDP datagram provides a way
to detect any protocol discontinuity at NE side. If ARDP datagrams
are sent into the same private/dedicated plane as video datagrams
this can provide a valuable feedback on global end-to-end plane QoS.
Discontinuity can even trigger actions at NE ARDP Client side in
order to request lost datagrams.
Cassen Expires November 22, 2007 [Page 11]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
3.2.8. Source CP ID field
Specifies the CP 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 CP Assigned MCAST group.
An Operator ID is a 32bit value identifying in a unique way any CP.
This can be an IPv4 IP address used as point of presence in ARDP
Backbone.
3.2.9. Global Message Data field
For this first version of ARDP protocol, this field is only used
during ClientID flooding to indicate which CP the ClientID flooding
message belongs to in order to identify CP ClientID namespace.
3.2.10. CP Signature field
Includes the digital signature (if used) to authenticate ARDP packet.
On ARDP Client side, Source CP ID field indicates which CP 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 November 22, 2007 [Page 12]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
3.3. CP Access 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 CP service, these are routings pieces of informations
identifying a CP IPTV streaming service (multicast group).
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 November 22, 2007 [Page 13]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
3.4. CP Service ID message format
This message type refers to a unary CP 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
OPTIONAL 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 November 22, 2007 [Page 14]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
3.4.5. Fallback Multicast Group field
OPTIONAL field. Specifies an IPv4 multicast group into the assigned
MCAST group range. While a customer is requesting for a ServiceID, if
NE detects there is no Access Right for this customer, then NE can
choose to subscribe to any advertising or teasing multicast ressource
refer to as "Fallback".
3.4.6. Fallback Unicast Source field
OPTIONAL 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. NE ARDP Client 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. NE ARDP Client
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NE Client IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each customer owns a unique ClientID into each CP namespace. NE
Client IP Address is unique to each CP namespace.
Cassen Expires November 22, 2007 [Page 15]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
3.5.1. Client ID field
Specifies the ClientID this association refer to.
3.5.2. NE Client IP Address field
Specifies the physical IP Address.
3.6. CP 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 CP 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 TimeSlot.
4. Unicast Protocol Part
ARDP Unicast datagrams are used by NE ARDP Client to request ARDP NSP
Server for right cache feeding. Those messages are using general ARDP
Cassen Expires November 22, 2007 [Page 16]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
protocol header presented in section 3.2. Authentication is not
mandatory since flows are local to private ARDP Backbone from NE to
NSP ARDP Server. Unicast messages are vehiculed over IP/TCP and are :
- 0x01 : NE Access Right populate request
- 0x02 : NE ClientID populate request
- 0x03 : NE ServiceID populate request
NE 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 CP Service ID plane. If new
Service ID plane is flooded then send all Access Right
(of this CP).
- If ARDP server is NSP ARDP Server then:
o Only accept Unicast requests from NE ARDP Client
o Only send Unicast request to remote CP ARDP Server
Else
o Only accept unicast requests from NSP ARDP Server
Endif
- MUST periodically flood whole Access Right
- MUST flood ClientID before any Access Right related to this
ClientID.
- MUST monotonically increment sequences counters for every
message type while sending ARDP datagrams.
Cassen Expires November 22, 2007 [Page 17]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
6. NE 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 CP secrets
for HMAC-MD5-96bit authentication or load RSA public key if
RSA authentication is used.
- MUST wait until CP Service IDs are received. While receiving
Service IDs update local ServiceID sequence counter.
- MUST connect to NSP ARDP Server only to request for
ClientID flooding.
- If ClientID table is empty then:
o Re-schedule a new ClientID flooding request to
NSP 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 NSP ARDP Server.
Endif
- If Access Right Table is empty then:
o Re-schedule a new Access Right flooding request to
NSP ARDP Server.
Cassen Expires November 22, 2007 [Page 18]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
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 NSP 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 :
- If Authentication is used then MUST drop any datagram
received with a lower sequence number than currently
stored sequence counter related to incoming ARDP
message type.
- When receiving ARDP datagram then MUST update local ARDP message
type sequence counter with ARDP header sequence number field.
- When receiving ClientID message, if ClientID is refering to a
local NE 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 CP source of the message.
- If Access Right Table is empty then:
o Transit to Initialize state.
Endif
Cassen Expires November 22, 2007 [Page 19]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
- When NE ARDP stack is looking for Access Right or TimeSlot
in Access Right cache as describe in section 2.1, it MUST
expire CP Access Right and CP Unencrypted TimeSlot according
to Validity learnt during ARDP message flooding as presented in
section 3.3.4/3.3.5 for CP Access Right and 3.6.3/3.6.4 for
CP Unencrypted TimeSlot. If Access Right or Unencrypted TimeSlot
has expired, then it is removed from local Access Right cache.
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
Cassen Expires November 22, 2007 [Page 20]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
8. Acknowledgments
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
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.
[RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[AAA] Hiroaki Satou, Hiroshi Ohta, Tsunemasa Hayashi,
Haixiang He, "AAA Framework for Multicasting", Internet
Draft.
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
Cassen Expires November 22, 2007 [Page 21]
Internet-Draft Access Right Distribution Protocol(ARDP) May 2007
11. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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
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 November 22, 2007 [Page 22]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/