Internet Engineering Task Force Alexandre Cassen Internet-Draft Freebox S.A. Expires: January 24, 2008 July 23, 2007 Access Right Distribution Protocol (ARDP) 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 January 24, 2008. 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 January 24, 2008 [Page 1] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 Conditional Access Attributes message format ...... 11 3.4. CP Sevice ID message format .......................... 16 3.5. CP Class ID message format ........................... 17 3.6. Client ID message format ............................. 18 3.7. CP Free Access Timeslot message format ............... 18 4. Unicast Protocol Part .................................... 19 5. ARDP Server .............................................. 19 6. NE ARDP Client State Transition Diagram .................. 20 6.1. Initialize State ..................................... 20 6.2. Learning State ....................................... 22 7. Sending and receiving ARDP datagram ...................... 23 7.1. Sending .............................................. 23 7.2. Receiving ............................................ 23 8. Acknowledgments .......................................... 23 9. References ............................................... 23 10. Editor s Address ......................................... 24 11. Full Copyright Statement ................................. 25 Cassen Expires January 24, 2008 [Page 2] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 1. Introduction Standard digital TV security models are based on smartcard intelligence at the end user CPE 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 CPE/smartcard. If this system can be considered as good for broadcasting where upstream (on CPE 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 CPE 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. CPE is considered as no trust equipement and the idea is to reduce to the max the action it may have. CPE 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 CPE 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 January 24, 2008 [Page 3] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 January 24, 2008 [Page 4] Internet-Draft Access Right Distribution Protocol(ARDP) July 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. Free Access 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). ClassID An abstraction modelizing a CP pieces of informations identifying a CP IPTV set of ServiceID. CPE Customer Premise Equipment. Cassen Expires January 24, 2008 [Page 5] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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 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 Free Access Timeslot flooding. All customer ClientID are flooded from NSP ARDP Cassen Expires January 24, 2008 [Page 6] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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 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 | | +--------------------+ | | | Conditional Access | | | | Cache | | | +------------------------+ +----------^---------+ | | | CORE Routing Stack | | | | | +------+ +------v-----+ | | | | IGMP |<------>| ARDP Stack | | | +-----------------+--^---+ +------------+ | +------------------------|-------------------------------+ | | +------v------+ | CPE | +-------------+ When the CPE 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 CPE network. It is mandatory to Cassen Expires January 24, 2008 [Page 7] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 separate the ARDP network plane from the CPE network plane. Only edge routing equipment can access the ARDP plane and CPE 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 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 Free Access Timeslot and Access Right. Cassen Expires January 24, 2008 [Page 8] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 January 24, 2008 [Page 9] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARDP Msg Data... +-+-+-+-+-+-+-+-+-+-+-+-+- 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 Conditional Access Attributes message - 0x02 : CP ServiceID message - 0x03 : CP ClassID message Cassen Expires January 24, 2008 [Page 10] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 - 0x04 : ClientID message - 0x05 : CP Free Access Timeslot message 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 January 24, 2008 [Page 11] Internet-Draft Access Right Distribution Protocol(ARDP) July 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. 3.3. Conditional Access Attributes message format Conditional Access attributes carry specific authentication, accounting, authorization, routing and security information as well as configuration details for a specific ClientID. This message refers to format and paradigm as presented in [RFC3588]. Every conditional access attributes are using the AVP Header specification as described in section 4.1 of [RFC3588]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ In this the following sections we will define specifics AVPs for use in ARDP protocol using Basic AVP data formats and Derived AVP data formats as in section 4.2 and 4.3 of [RFC3588]. Cassen Expires January 24, 2008 [Page 12] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 3.3.1. ARDP Conditional Access Base Protocol AVPs The following table describes the ARDP Conditional Access AVPs defined in the base protocol, their AVP Code Values, types, possible flag values and whether the AVP MAY be encrypted. For the the originator of a ARDP message, "Encr" (Encryption) means that if a message containing that AVP is to be sent via an ARDP server then the message MUST NOT be sent unless there is a end-to-end security between the originator and the recipient (eg: between ARDP Server and ARDP Client). ARDP base Protocol AVPs are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Auth-Service- 65536 3.3.2 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Class- 65537 3.3.3 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Client- 65538 3.3.4 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Begin- 65539 3.3.5 Time | M | P | | V | N | Validity | | | | | | Auth-End- 65540 3.3.6 Time | M | P | | V | N | Validity | | | | | | Accounting- 65541 3.3.7 Address | M | P | | V | N | Server | | | | | | -----------------------------------------|----+-----+----+-----|----| ARDP Grouped AVPs are: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Access-Right- 65580 3.3.8 Grouped | M | P | | V | N | Add | | | | | | Access-Right- 65581 3.3.9 Grouped | M | P | | V | N | Delete | | | | | | Accounting- 65582 3.3.10 Grouped | M | P | | V | N | Zap | | | | | | -----------------------------------------|----+-----+----+-----|----| Cassen Expires January 24, 2008 [Page 13] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 3.3.2. AVP Auth-Service-Id The Auth-Service-Id AVP (AVP code 65536) is of type Unsigned32 and refers to an ARDP ServiceID. 3.3.3. AVP Auth-Class-Id The Auth-Class-Id AVP (AVP code 65537) is of type Unsigned32 and refers to an ARDP ClassID. 3.3.4. AVP Auth-Client-Id The Auth-Client-Id AVP (AVP code 65538) is of type Unsigned32 and refers to an ARDP ClientID. 3.3.5. AVP Auth-Begin-Validity The Auth-End-Validity AVP (AVP code 65539) is of type Time and identifies begin of a validity of Access right. 3.3.6. AVP Auth-End-Validity The Auth-End-Validity AVP (AVP code 65540) is of type Time and identifies end of a validity of Access right. 3.3.7. AVP Accounting-Server The Accounting-Server AVP (AVP code 65541) is of type Address and informs to ARDP client the remote accounting server it MUST send recorded zapping events (join, leave). 3.3.8. AVP Access-Right-Add The Access-Right-Add AVP (AVP code 65580) is of type Grouped. It adds a positive access right for a ClientID to a specific ServiceID into ARDP Conditional Access cache. If received by NE then ClientID will have ability to zap and receive specified ServiceID (CP IPTV streaming service: multicast group) stream until its CPE. The Grouped Data field has the following ABNF grammar as in [RFC4234]: Access-Right-Add ::= < AVP Header: 65580 > { Auth-Client-Id } { Auth-Service-Id } / { Auth-Class-Id } { Auth-Begin-Validity } { Auth-End-Validity } * [ AVP ] Cassen Expires January 24, 2008 [Page 14] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 This AVP allow ARDP sending source to append optional AVPs. 3.3.9. AVP Access-Right-Delete The Access-Right-Delete AVP (AVP code 65581) is of type Grouped. It removes access right for a ClientID to a specific ServiceID from ARDP Conditional Access cache. If received by NE then ClientID will no longer have ability to zap and receive specified ServiceID. The Grouped Data field has the following ABNF grammar as in [RFC4234]: Access-Right-Add ::= < AVP Header: 65581 > { Auth-Service-Id } { Auth-Client-Id } 3.3.10. AVP Accounting-Zap The Accounting-Zap AVP (AVP code 65582) is of type Grouped. It defines accounting server for zapping event accounting. Every Zap events for a specified ClientID to a specific ServiceID will be traced to the specified Server. The Grouped Data field has the following ABNF grammar as in [RFC4234]: Access-Right-Add ::= < AVP Header: 65582 > { Auth-Client-Id } { Accounting-Server } * [{ Auth-Service-Id } / { Auth-Class-Id }] Cassen Expires January 24, 2008 [Page 15] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 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 January 24, 2008 [Page 16] Internet-Draft Access Right Distribution Protocol(ARDP) July 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.9. Service String field Specifies a String as comment for the Service ID. 3.5. CP Class 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5.1. Class ID field Specifies a unique ID into the TV Operator namespace. 3.5.2. Version Code field Specifies a version number to identify the Class plan this Class ID belongs to. 3.5.1. Service ID field Specifies a CP Service ID. Cassen Expires January 24, 2008 [Page 17] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 3.6. 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. 3.6.1. Client ID field Specifies the ClientID this association refer to. 3.6.2. NE Client IP Address field Specifies the physical IP Address. 3.7. CP Free Access 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.7.1. Command field Specifies whether to add or delete an Free Access Timeslot. Valid commands are : - 0x01 : Add a new Timeslot - 0x02 : Delete a Timeslot Cassen Expires January 24, 2008 [Page 18] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 3.7.2. Service ID field Specifies a unique ID into the CP namespace. 3.7.3. Begin Time Slot field Specifies the begin TimeSlot validity date. 3.7.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 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 - 0x04 : NE ClassID 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 CPE 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: Cassen Expires January 24, 2008 [Page 19] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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. 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 wait until CP Class IDs are received. While receiving Class IDs update local ClassID sequence counter. - MUST connect to NSP ARDP Server only to request for ClientID flooding. - If ClientID table is empty then: Cassen Expires January 24, 2008 [Page 20] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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. 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. Cassen Expires January 24, 2008 [Page 21] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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 - 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 Free Access TimeSlot according to Validity learnt during ARDP message flooding as presented in section 3.3.5/3.3.6 for CP Access Right and 3.7.3/3.7.4 for CP Free Access TimeSlot. If Access Right or Free Access TimeSlot has expired, then it is removed from local Access Right cache. Cassen Expires January 24, 2008 [Page 22] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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 provided by the IETF Administrative Support Activity (IASA). Cassen Expires January 24, 2008 [Page 23] Internet-Draft Access Right Distribution Protocol(ARDP) July 2007 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. [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko "Diameter Base Protocol", RFC 3588, September 2003. [RFC4234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [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, Christian Jacquenet, 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 EMail: acassen<-at->freebox<-dot->fr Cassen Expires January 24, 2008 [Page 24] Internet-Draft Access Right Distribution Protocol(ARDP) July 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 January 24, 2008 [Page 25]