Internet Engineering Task Force Alexandre Cassen Internet-Draft Freebox S.A. Expires: July 16, 2009 January 12, 2009 Access Right Distribution Protocol (ARDP) Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 16, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cassen Expires July 16, 2009 [Page 1] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 Abstract This document describes a protocol using multicast to securely distribute IPTV management elements such as IPTV customer's access rights. The protocol typically runs on any piece of equipments to locally store owned customers IPTV service access right. This design provides access control at edge level. Table of Contents 1. Introduction .............................................. 4 1.1. Scope ................................................. 5 1.2. Definitions ........................................... 5 2. ARDP framework ............................................ 7 2.1. NSP/CP Hierarchy ...................................... 7 2.2. Using Multicast to convey ARDP datagrams .............. 7 2.3. An ID and attributes oriented protocol ................ 8 2.4. CP Service Plane ...................................... 8 2.5. ClientID ............................................. 10 2.6. Conditional Access Right ............................. 10 2.7. Attributes inheritance ............................... 11 3. ARDP Architecture ........................................ 11 3.1. Interface with NE routing stack ...................... 13 3.2. Adaptive zapping ..................................... 14 3.3. Confidentiality and security considerations .......... 15 3.4. NSP ARDP Server ...................................... 16 3.5. CP ARDP Server ....................................... 17 3.6. NE ARDP Client ....................................... 17 3.7. NSP ARDP Report ...................................... 18 3.8. NSP ARDP Accounting .................................. 18 3.9. Make it reliable ! ................................... 19 3.10. ARDP stream bitrate ? ............................... 20 3.11. Global Operation workflow ........................... 20 4. Multicast Protocol Part .................................. 21 4.1. IP/UDP packet field descriptions ..................... 21 4.2. ARDP header Packet Format ............................ 21 4.3. ARDP AVP Packet Format ............................... 24 5. ARDP Base Protocol AVPs .................................. 24 6. Unicast Protocol Part .................................... 30 7. ARDP Server Operations ................................... 30 8. NE ARDP Client Operations ................................ 31 8.1. Initialize State ..................................... 31 8.2. Learning State ....................................... 33 9. Sending and receiving ARDP datagram ...................... 34 9.1. Sending .............................................. 34 9.2. Receiving ............................................ 34 10. Acknowledgments ......................................... 34 Cassen Expires July 16, 2009 [Page 2] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 11. References ............................................... 35 12. Authors' Address ......................................... 35 Cassen Expires July 16, 2009 [Page 3] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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. Cassen Expires July 16, 2009 [Page 4] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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. ChannelID An abstraction modelizing a CP pieces of informations identifying a CP IPTV streaming service (multicast group and any other low-level related attributes). ServiceID An abstraction modelizing a CP pieces of informations identifying a CP IPTV set of ChannelID. ClassID An abstraction modelizing a CP pieces of informations identifying a CP IPTV set of ServiceID. Service Plane An abstraction modelizing the CP set of ClassID / ServiceID. 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 or ClassID. It determines whether or not a ClientID can access a specific ServiceID or ClassID. CP Content Provider is in charge of multicast content streaming. Each CP is also in charge of distributing Service Plane, ClientID, Access Right over ARDP backbone. ARDP Backbone A Wide Area Network made of lot of ARDP clients. Cassen Expires July 16, 2009 [Page 5] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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 network edge routing equipments. It is responsible for NE local right cache management and is interacting with NSP ARDP Server. It stores all CP Service Plane, ClientID, associated security elements (RSA public key) and customer Access Right. 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. It manages Service Plane and Access Right flooding. 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. ARDP Session A connection issued by NSP ARDP Server to CP ARDP Server to request Access Right flooding for a set of CP ClientID. NSP Accounting Srv A server listening and handling any accounting reports sent by NE. NSP Report Srv A server acting as a proxy between NE and Back-office management systems. Use to fetch/verify Access Right bound to a specific ClientID. CDS Content Delivery Services. CPE Customer Premise Equipment. Cassen Expires July 16, 2009 [Page 6] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 2. ARDP framework ARDP provides secure, scalable and reliable facilities to distribute IPTV management elements. Those elements are : . CP Service Plane (ClassID/ServiceID) . ClientID . Access Right 2.1. NSP/CP Hierarchy ARDP design tend to create a hierarchy between NSP and CP. NSP trust CP with point of presence in its ARDP Backbone, but for security/maintenability reasons NSP 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 namespace. CP operations are CDS centralized, it manages informations needed to run its business say : ServiceID/ClassID/Access Right. 2.2. Using Multicast to convey ARDP datagrams ARDP is running over multicast. ARDP Servers are a only multicast sending source while NE ARDP Client are a only multicast receiver. Every CP are network low-level topology agnostic, using multicast provides a simple and scalable answer to offer a full and realtime distribution of Access Right to each CP. IPTV makes extensive use of multicast, using multicast for ARDP and localizing it into same networking plane as other regular streamed contents will provide an accurate feedback on multicast reliability until NE. As presented in section 4.5, ARDP architecture defines an accounting server used to handle ARDP protocol reliability, any trouble occuring on ARDP multicast flow can be extrapolated to other multicast flows into the same networking plane. Finally, using multicast as distribution vector offers to ARDP protocol a very short convergence time since one change will be learnt and affect every NE at a time. For example, changing any Service Plane piece of informations (multicast group, ...) will be quite realtime. Cassen Expires July 16, 2009 [Page 7] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 2.3. An ID and attributes oriented protocol ARDP is network topology agnostic by making extensive use of ID for addressing every low-level elements. IDs are key-elements just like those found in DVB satellite architecture. Using IDs create an abstraction between managed and target elements leading to a very short (optimum) convergence time needed while updating those target elements. CP Service Plane is the ARDP fundation element. Every CP are permanently flooding over ARDP backbone all of their ServiceID and ClassID elements. On its own, NSP is flooding ClientID element. Service Plane and ClientID open the road to CP Access Right flooding, in other words: setting an Access Right for a ServiceID or ClassID to a target ClientID. An Access Right is thus a binding between ClientID and ServiceID/ClassID. The others ARDP key-elements are attributes. Every IDs are filled with a set of attributes like presented in section 4.3.1. A ServiceID/ClassID/ClientID is a set of attributes. Creating ID abstraction provides flexibility while managing attributes. Attributes values updates (over ClassID, ServiceID, ClientID, ....) will not impact any ARDP operations since Access Right binding is made on ID. 2.4. CP Service Plane Service Plane is managed by a CP, it defines low-level elements CP will use to run its business. A Service Plane is thus a set of ServiceID and ClassID learnt by ARDP Client. Service Plane brings an important flexibility for CP since it can change any elements in quite realtime. It provides functional flexibility like defining playlist based ServiceID, adaptive zapping, ... 2.4.1. ServiceID A ServiceID is compounded by a set of ChannelID and is unique in CP ARDP namespace. Its management representation is an ID and is filled using the following ABNF notation as in [RFC4234]: ServiceID ::= { Auth-Service-Id } * [ AVP ] { Service-Profile } [ Channel-Id [ AVP ] ] { Service-Profile-fallback } [ Channel-Id [ AVP ] ] Cassen Expires July 16, 2009 [Page 8] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 Detailed AVPs declaration and specifications can be found in section 5. A live example can be : SvcID | Service Attributes ---------+--------------------------------------- 201 | . Service Name : IETF IPTV Room1 | . PC Redirect : 1 | . Number of Decoder : 2 | . Accounting-Zap : 192.168.200.10 | . Profile : | . ChannelID : 419 | . Service Name : IETF IPTV HD | . Multicast Group : 239.1.2.3 | . Unicast Source : 192.168.200.1 | . Capabilities : 0x0002 | . Bitrate : 5500 | . ChannelID : 32 | . Service Name : IETF IPTV SD | . Multicast Group : 239.1.2.4 | . Unicast Source : 192.168.200.2 | . Capabilities : 0x0004 | . Bitrate : 3600 | . ChannelID : 347 | . Service Name : IETF IPTV H264 | . Multicast Group : 239.1.2.5 | . Unicast Source : 192.168.200.3 | . Capabilities : 0x0008 | . Bitrate : 2000 | . Profile Fallback : | . ChannelID : 519 | . Service Name : IETF FB HD | . Multicast Group : 239.1.2.6 | . Unicast Source : 192.168.200.4 | . Capabilities : 0x0002 | . Bitrate : 5500 | . ChannelID : 132 | . Service Name : IETF FB SD | . Multicast Group : 239.1.2.7 | . Unicast Source : 192.168.200.5 | . Capabilities : 0x0004 | . Bitrate : 3600 | . ChannelID : 447 | . Service Name : IETF FB H264 | . Multicast Group : 239.1.2.8 | . Unicast Source : 192.168.200.6 | . Capabilities : 0x0008 Cassen Expires July 16, 2009 [Page 9] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 | . Bitrate : 2000 In this example ServiceID 201 defines "IETF IPTV Room1" service. 2.4.2. ClassID A ClassID is managed by a CP, it defines a set of ServiceID and is filled using the following ABNF notation as in [RFC4234]: ClassID ::= { Auth-Class-Id } * [ AVP ] [ Auth-Service-Id ] A live example can be : ClassID | Class Attributes ---------+--------------------------------------- 74 | . Class Name : IETF IPTV Area | . Number of Decoder : 3 | . Service : | 201 202 203 204 205 206 207 208 2.5. ClientID A ClientID defines an NSP low-level binding between Client networking informations and its ARDP representation. A ClientID is filled using the following ABNF notation as in [RFC4234]: ClientID ::= { Auth-Client-Id } * [ AVP ] A live example can be : ClientID | Client Attributes ----------+--------------------------------------- 100 | . IP-Address : 10.1.1.1 | . Number of Decoder : 5 | . Accounting-Zap : 192.168.200.150 2.6. Conditional Access Right A conditional Access Right defines a binding between (ClientID,ServiceID) or (ClientID,ClassID). CP is setting those bindings for every ClientID it manages. If a Client is subscribing to a marketing offer modelized in ARDP by ClassID 74 then CP simply send an ARDP datagram to set/create this binding. Cassen Expires July 16, 2009 [Page 10] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 2.7. Attributes inheritance ARDP provides attributes inheritance design between every element it manages. Inheritance tree is : ServiceID ^ | ClassID ^ | ClientID ServiceID is surcharging ClassID attributes surcharging ClientID attributes. If we use the live example presented in previous sections, "Number of Decoder" attributes will finally have the value of 2. 3. ARDP Architecture 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 | +------+ +------+ +------+ +-------+ ^ ^ ^ ^ ................ . . . . . . . +--------- v + +---------- v + . . | NSP ARDP | | NSP ARDP |<...... . | Accounting | | Report |<............... +------------+ +-------------+ Cassen Expires July 16, 2009 [Page 11] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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 NSP ARDP Accounting : NSP Accounting Server NSP ARDP Report : NSP Back-Office Report Server All customer ClientID are flooded from NSP ARDP Server. All customer Access Right are flooded from CP ARDP Server. Every CP ARDP Server are flooding Service Plane and Access Right for ServiceID/ClassID they manage. NE ARDP Client is then filtering received multicast datagrams to only store Access Right, for customers it hosts (ClientID). 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 Service Plane and Access Right over ARDP Backbone. Cassen Expires July 16, 2009 [Page 12] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 3.1. Interface with NE routing stack In IPTV architectures, stream subscription is most of the time done through IGMP (as described in [RFC3376]) since streaming is done via multicast. In IGMP there is a lake of feedback while performing JOIN or LEAVE operation, in this document we will not use IGMP as subscription protocol, we will rather use SUBSP acronym to identify this subscription protocol. SUBSP MUST be a protocol offering feedback/error reporting and using regular Client/Server approach to benefit any ARDP features and flexibilities. SUBSP can be : - RTSP as described in [RFC2326] - SIP/RTSP as descibed in [SIPRTSP] - define a new protocol ? ARDP operates close to edge routing equipment stack at subscription protocol level. The diagram below shows general ARDP operations : +--------------------------------------------------------+ | NE Routing Software | | +--------------------+ | | | ARDP | | | | Information Base | | | +------------------------+ +----------^---------+ | | | CORE Routing Stack | | | | | +-------+ +------v-----+ | | | | SUBSP |<------>| ARDP Stack | | | +----------------+---^---+ +------------+ | +------------------------|-------------------------------+ | | +------v------+ | CPE | +-------------+ When CPE requests for a ServiceID, it generates an Access Request caught by NE routing stack. Before processing the subscription operation, SUBSP stack requests authorisation to ARDP Stack. If access is granted by ARDP then SUBSP stack proceeds to perform stream subscription and any routing related task. SUBSP is thus sending Access Request to ARDP Stack. Cassen Expires July 16, 2009 [Page 13] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 Authentication workflow between CPE and NE Routing Software is defined as : +------+ +-------+ +------+ | CPE | | SUBSP | | ARDP | +------+ +-------+ +------+ | | | | JOIN / LEAVE | | |-------------------->| Access-Request | | |-------------------->| | | | | | Access-Response | | |<--------------------| | ACK / NAK | (DENY / ACCEPT) | |<--------------------| | | | | Using ABNF notation as in [RFC4234] SUBSP Access-Request and Access- Response can be specified as : Access-Request ::= { Namespace } { Auth-Client-Id / IP-Address } { Auth-Service-Id } Access-Response ::= { DENY / ACCEPT } [ Channel-Id [ AVP ] ] While handling Access-Response ARDP stack will append ServiceID's Profile or Profile Fallback rather it is an ACCEPT or a DENY. 3.2. Adaptive zapping An important feature provided by ARDP Service Plane is to offer adaptive zapping. As described in section 3.1 customer zapping in translated into sending an Access Request to ARDP for a specific ServiceID. As described in section 2.4.1, ServiceID is a set of ChannelID filled with a set of attributes. While performing conditionnal Access Right operations, NE routing software can adaptively select a ChannelID based on attribute matching. A specific use case of this feature is to select a ChannelID based on bitrate attribute value so that zapping will be dynamic/adaptive according to available bandwitdh between CPE and NE. If a CPE is feeded with multiple streams at a time then this mecanism can optimize bandwidth usage. Cassen Expires July 16, 2009 [Page 14] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 3.3. 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 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 Service Plane and Access Right for running its business. NSP provides a Namespace and a point of presence in ARDP backbone to each CP. Using ARDP, a CP can manage Service Plane and 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. - Requests CP ARDP Server to distribute Access Right to a particular ClientID. On the other hand, CP is a supervisor authority for distributing ARDP Service Plane and Access Right it manages : - Handles NSP ClientID request by flooding in response the associated ARDP Access Right. - Permanently flood Service Plane. 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. On the other hand ARDP is using sequence numbers in every datagram and generated at server side which prevent against any kind of replay attack. ARDP protocol replay attack is not intrinsec possible since Cassen Expires July 16, 2009 [Page 15] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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. 3.4 NSP ARDP Server The main goal of this server is to distribute CP ClientID over ARDP backbone and issue ARDP Sessions with CP ARDP Server. Main functional elements blocks can be represented as following : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ARDP Backbone | | | | | | +-----------+ ^(MCAST) | \ | | . +------+ +------+ +------+ / \___| CP ARDP |______._______| NE 1 |___| NE 2 |..| NE n |__/ | | . +------+ +------+ +------+ +-----------+ . . . ^ . . (TCP) .(TCP) .(TCP) . ............. .... . . . . +----- . --------------- . -------------- v -- v -------+ | +--------------+ +----------------+ +-------------+ | | | ARDP Session | | ClientID Flood | | NE Listener | | | +--------------+ +----------------+ +-------------+ | | +------------------+ | | | Subscribers's DB | | | | Interface | | | NSP ARDP Server +------------------+ | +-------------------------------------------------------+ NSP ARDP Server fonctionnalities are : - ARDP Session : It peers ClientID to CP ARDP Server to request CP Access Right flooding accordingly. - ClientID Flooding : It floods ClientID of every CP. - NE Listener : It listens on ARDP Backbone for NE flooding requests. Cassen Expires July 16, 2009 [Page 16] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 - Subscriber's DB Interface : It is closely linked to subscriber's database to fetch accurate informations for ClientID flooding and Session with every CP ARDP Servers. 3.5 CP ARDP Server This server is managed by CP and operates two major functions: - Autonomous ARDP flooding : Any CP back-office MUST and NEED to send Access Right whenever it is needed. - Sollicited ARDP flooding : Any CP ARDP Server MUST send Access Right over ARDP Backbone upon NSP ARP Server request received by ARDP session. 3.6 NE ARDP Client Is running on NE and is managing NE ARDP information base. Main functional elements blocks can be represented as following : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | ARDP Backbone | | | \ +------+ +------+ / \___| CP |_| NSP |________________________________.______/ | ARDP | | ARDP |<.................. . +------+ +------+ . . . . +-------------+ +--------------- . ----------- . ------+ | NSP ARDP | | +----------+ +-.----+ +----v-----+ | | Report |<........>| Report | | NSP | | MCAST | | +-------------+ | | Listener | | Req. | | Listener | | | +----------+ +------+ +----------+ | +-------------+ | | | NSP ARDP | | +------------+ +------------------+ | | Accounting |<.........| Accounting | | Routing Software | | +-------------+ | | Notifier | | Interface | | | +------------+ +------------------+ | | | | NE ARDP Client | +--------------------------------------+ NE ARDP Client fonctionnalities are : Cassen Expires July 16, 2009 [Page 17] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 - MCAST Listener : Multicast listener handling incoming ARDP datagram received from ARDP Backbone. - NSP Requester : Send ARDP flooding request to NSP ARDP Server. ARDP ClientID and Access Right flooding requests. - Routing Software interface : A TCP listener handling Access-Request coming from SUBSP (as presented in section 3.1. - Report Listener : Listening from NSP ARDP Report server Access Right fetching request. - Accounting notifier : Periodically notify NSP Accounting Server to internal informations 3.7 NSP ARDP Report The main goal of this server is to provide an interface to customer's management back-office in order to fetch ClientID Access Right bindings and thus providing an accurate feedback internal ARDP NE storage. For exemple it can provides facilities to customer hotline in order to verify customer Access Right. 3.8 NSP ARDP Accounting The main goal of this server is to provide ARDP protocol accounting facilities. NE ARDP Client push periodically internal informations to this central node. This accounting server offers a centralized consolidation point. NE ARDP Client can push informations like : - ARDP Stream discontinuity. - Customer zapping request rate. - ServiceID zap auditing. - ... In this document we will not detail protocol framing used to push accounting informations to NSP ARDP Accounting server, but it is mainly using the ARDP protocol header with a bunch of ARDP AVPs append. Due to its push design fashion, NE ARDP Client need to add kind of skew factor to its timer push to workaroung any flooding side-effect. IPTV customer's uses are impulsive and periodical, pushing timer need to be short in order to consider and consolidate accurate informations. Cassen Expires July 16, 2009 [Page 18] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 3.9 Make it reliable ! ARDP is using multicast to distribute protocol datagrams. The main constraint using multicast is that we need to make it reliable since its using a non-connected design fashion, any datagram can be lost in transit especially if it is running on a very large network. There is multiple way found into litterature to handle reliability of multicast stream. The very first design is to retransmit lost sequences. As presented in section 4.2.7, ARDP datagrams are sequenced so that ARDP Client can learn how many ARDP datagrams have been lost and request for retransmission. Retransmission can also be operated by agnostic protocol like presented into [RMT] IETF Working Group. The main side effect of such an architecture is to lead to massive restransmission flooding. Actually, on large operator network it is most likely any operationnal action on routings or network equipments will lead to lost datagram into network regions where operations has been done. It can be extrapolated to a massive retransmission request if drops are localized close to multicast streaming source. This design is to be used for multicast stream where lost of datagram is critical and irreversible, if lost datagram can be recomputed and retransmitted later on then we can investigate others alternatives that will offer flexibility of delayed operations. An alternative to previous design would be to completely ignore lost datagrams and, instead, periodically flood global ARDP protocol informations (ClientID + Access Right). The main advantage with this approach is its simplicity but its cost is that flooding time will increase accordingly to number ARDP protocol informations. On one hand we have the flexibility of delayed operations, on the other hand we increase convergence time and impact scalability. Another alternative would be to mix both approaches. NE ARDP Client is periodically pushing back to NSP ARDP Accounting Server protocol stream discontinuity so that if NSP ARDP Server is notified accordingly it can flood back to NE any ARDP protocol related informations (ClientID + Access Right). NSP ARDP Server can selectively flood ARDP protocol informations by NE. This approch will scale and provide flexibility of mass flooding. This document will prefer this approach. Cassen Expires July 16, 2009 [Page 19] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 3.10. ARDP stream bitrate ? ARDP is a streamed protocol so that its bitrate will directly impact receiving processing, even more since it is using crypto. Controlling ARDP source will control any NE ARDP Client time computing ressources. Making ARDP stream Constant BitRate will transitively induce a maximum time computing threshold tweakable at sending source. 3.11. 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 Access 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 Access Right flooding to each remote CP ARDP Server for given ClientID in each CP ClientID namespace. Cassen Expires July 16, 2009 [Page 20] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 (d) Multicast message : In response to (c) each CP ARDP Server floods Access Right requested by NSP ARDP Server. 4. 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 the ability to run multiple ARDP plane using the same multicast routing ressource. 4.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. 4.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Namespace | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | CP Signature | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ARDP AVPs... +-+-+-+-+-+-+-+-+-+-+-+-+- Cassen Expires July 16, 2009 [Page 21] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 4.2.1. Version field Specifies the ARDP protocol version a packet belongs to. Our current document describes Version 1. 4.2.2. Header Length field Specifies the length of the ARDP header. 4.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 Attributes message - 0x03 : CP ClassID Attributes message - 0x04 : ClientID Attributes message 4.2.4. Size field Specifies the total size of the ARDP packet including ARDP header and message data. 4.2.5. Count Messages field Specifies the number ARDP message data included in the global ARDP packet. 4.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] 4.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. Cassen Expires July 16, 2009 [Page 22] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 4.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. 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. 4.2.9. Namespace field This field is used during ClientID flooding to indicate which CP the ClientID flooding message belongs to. 4.2.10. NE ID field This field is used during flooding to indicate which NE the ClientID/Access Right flooding messages belongs to. This field prevent against filtering every AVPs in every datagram while processing. NE will process datagram if NE ID field found in ARDP header is matching its localy configured ID. If field is zeroed then NE will process inconditionnally datagram. 4.2.11. 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 July 16, 2009 [Page 23] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 4.3. ARDP AVP Packet Format ARDP AVPs carry specific authentication, accounting, authorization, routing and security information as well as configuration details for a specific ServiceID, ClassID and ClientID. This message refers to format and paradigm as presented in [RFC3588]. Every ARDP AVPs are using the following 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 following sections we will define specifics AVPs for use in ARDP protocol using Basic AVP data formats and Derived/Grouped AVP data formats as in section 4.2 and 4.3 of [RFC3588]. 5. ARDP Base Protocol AVPs The following table describes the ARDP 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). +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Auth-Service- 65536 3.3.3 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Class- 65537 3.3.4 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Client- 65538 3.3.5 Unsigned32 | M | P | | V | N | Id | | | | | | Auth-Client- 65539 3.7.3 Address | M | P | | V | N | Cassen Expires July 16, 2009 [Page 24] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 Address | | | | | | Auth-Begin- 65540 3.3.6 Time | M | P | | V | N | Validity | | | | | | Auth-End- 65541 3.3.7 Time | M | P | | V | N | Validity | | | | | | Accounting- 65542 3.3.8 Address | M | P | | V | N | Server | | | | | | Multicast- 65543 3.5.3 Address | M | P | | V | N | Group | | | | | | Unicast- 65544 3.5.4 Address | M | P | | V | N | Source | | | | | | Bitrate 65545 3.5.7 Unsigned32 | M | P | | V | N | Capabilities 65546 3.5.8 Unsigned32 | M | P | | V | N | Service-Name 65547 3.5.9 UTF8String | M | P | | V | N | Version-Code 65558 3.5.10 Unsigned32 | M | P | | V | N | -----------------------------------------|----+-----+----+-----|----| ARDP Grouped AVPs are set of Base Protocol AVPs: +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST| | Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| Access-Right- 65580 3.4.1 Grouped | M | P | | V | N | Add | | | | | | Access-Right- 65581 3.4.2 Grouped | M | P | | V | N | Delete | | | | | | Accounting- 65582 3.4.3 Grouped | M | P | | V | N | Zap | | | | | | ServiceID-Add 65583 3.5.1 Grouped | M | P | | V | N | ServiceID- 65584 3.5.2 Grouped | M | P | | V | N | Delete | | | | | | ClassID-Add 65587 3.6.1 Grouped | M | P | | V | N | ClassID-Delete 65588 3.6.2 Grouped | M | P | | V | N | ClientID-Add 65589 3.7.1 Grouped | M | P | | V | N | ClientID- 65590 3.7.2 Grouped | M | P | | V | N | Delete | | | | | | -----------------------------------------|----+-----+----+-----|----| 5.1. AVP Auth-Service-Id The Auth-Service-Id AVP (AVP code 65536) is of type Unsigned32 and refers to an ARDP ServiceID. Cassen Expires July 16, 2009 [Page 25] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 5.2. AVP Auth-Class-Id The Auth-Class-Id AVP (AVP code 65537) is of type Unsigned32 and refers to an ARDP ClassID. 5.3. AVP Auth-Client-Id The Auth-Client-Id AVP (AVP code 65538) is of type Unsigned32 and refers to an ARDP ClientID. 5.5. AVP Auth-Begin-Validity The Auth-End-Validity AVP (AVP code 65540) is of type Time and identifies begin of a validity of Access right. 5.6. AVP Auth-End-Validity The Auth-End-Validity AVP (AVP code 65541) is of type Time and identifies end of a validity of Access right. 5.7. AVP Accounting-Server The Accounting-Server AVP (AVP code 65542) is of type Address and informs to ARDP client the remote accounting server it MUST send recorded zapping events (join, leave). 5.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 ] This AVP allow ARDP sending source to append optional AVPs. Cassen Expires July 16, 2009 [Page 26] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 5.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-Delete ::= < AVP Header: 65581 > { Auth-Service-Id } { Auth-Client-Id } 5.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 or ClassID or set of ServiceID/ClassID will be traced to the specified Server. The Grouped Data field has the following ABNF grammar as in [RFC4234]: Accounting-Zap ::= < AVP Header: 65582 > { Auth-Client-Id } { Accounting-Server } * [{ Auth-Service-Id } / { Auth-Class-Id }] 5.11. CP ServiceID Attributes message format This message type refers to a unary CP service definition and apply to ARDP header message Type as presented in section 3.2.3. 5.12. AVP ServiceID-Add The ServiceID-Add AVP (AVP code 65583) is of type Grouped. It adds into CP namespace a ServiceID with its optional attributes. The Grouped Data field has the following ABNF grammar as in [RFC4234]: ServiceID-Add ::= < AVP Header: 65583 > { Auth-Service-Id } { Version-Code } { Multicast-Group } * { Unicast-Source } Cassen Expires July 16, 2009 [Page 27] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 * { Multicast-Fallback-Group } * { Unicast-Fallback-Source } * { Bitrate } * { Capabilities } * { Service-Name } This AVP allow ARDP sending source to append ServiceID and optional AVPs. 5.13. AVP ServiceID-Delete The ServiceID-Delete AVP (AVP code 65584) is of type Grouped. It removes from CP namespace a ServiceID. The Grouped Data field has the following ABNF grammar as in [RFC4234]: ServiceID-Add ::= < AVP Header: 65584 > { Auth-Service-Id } { Version-Code } 5.14. AVP Multicast-Group The Multicast-Group AVP (AVP code 65543) is of type Address and is specific to ServiceID AVPs (Add and Delete). It specifies a unique ID into the TV Operator namespace. 5.15. AVP Unicast-Source The Multicast-Group AVP (AVP code 65544) is of type Address and is specific to ServiceID AVPs (Add and Delete). It 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]. 5.16. AVP Capabilities The Capabilities AVP (AVP code 65548) is of type Unsigned32 and is specific to ServiceID AVPs (Add and Delete). It specifies ServiceID capabilities. 5.17. AVP Service-Name The Service-Name AVP (AVP code 65549) is of type UTF8String and is specific to ServiceID AVPs (Add and Delete). It specifies Service description. Cassen Expires July 16, 2009 [Page 28] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 5.18. AVP Version-Code The Version-Code AVP (AVP code 65550) is of type Unsigned32 and is specific to ServiceID AVPs (Add and Delete). It specifies a version number to identify the service plan this Service ID belongs to. 5.19. CP ClassID Attributes message format This message type refers to a unary CP Class definition and apply to ARDP header message Type as presented in section 3.2.3. 5.20. AVP ClassID-Add The ServiceID-Add AVP (AVP code 65587) is of type Grouped. It adds into CP namespace a ClassID. The Grouped Data field has the following ABNF grammar as in [RFC4234]: ClassID-Add ::= < AVP Header: 65587 > { Auth-Class-Id } { Version-Code } { Auth-Service-Id } This AVP allow ARDP sending source to append ClassID AVPs. 5.21. AVP ClassID-Delete The ServiceID-Add AVP (AVP code 65588) is of type Grouped. It removes from CP namespace a ClassID. The Grouped Data field has the following ABNF grammar as in [RFC4234]: ClassID-Add ::= < AVP Header: 65588 > { Auth-Class-Id } 5.22. ClientID Attributes message format This message type refers to a unary ClientID association and apply to ARDP header message Type as presented in section 3.2.3. 5.23. AVP ClientID-Add The ClientID-Add AVP (AVP code 65589) is of type Grouped. It adds into CP namespace a ClientID. The Grouped Data field has the following ABNF grammar as in Cassen Expires July 16, 2009 [Page 29] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 [RFC4234]: ClientID-Add ::= < AVP Header: 65589 > { Auth-Client-Id } { Auth-Client-Address } * [ AVP ] This AVP allow ARDP sending source to append any optional AVPs. 5.24. AVP ClientID-Delete The ClientID-Delete AVP (AVP code 65590) is of type Grouped. It removes from CP namespace a ClientID. The Grouped Data field has the following ABNF grammar as in [RFC4234]: ClientID-Delete ::= < AVP Header: 65590 > { Auth-Client-Id } 5.25. AVP Auth-Client-Address The ClientID-Delete AVP (AVP code 65539) is of type Address. It specifies the NE Client IP Address. 6. 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 NE ARDP Client fills the NE ID field with its own ID. Formerly it used the IPv4 IP Address provided for ARDP Backbone point of presence. 7. ARDP Server Operations The global goal of ARDP architecture is to focus protocol complexity onto the ARDP server instead of ARDP client. 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 Cassen Expires July 16, 2009 [Page 30] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 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. 8. NE ARDP Client Operations ARDP Client side manages local access right cache. Its finite state machine is divided into 2 states as follows : +------------------+ +------------------+ | |------------------------>| | | Initialize | | Learning | | |<------------------------| | +------------------+ +------------------+ 8.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. Cassen Expires July 16, 2009 [Page 31] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 - 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: 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 July 16, 2009 [Page 32] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 8.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 July 16, 2009 [Page 33] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 9. Sending and receiving ARDP datagram 9.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. 9.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 10. Acknowledgments Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Cassen Expires July 16, 2009 [Page 34] Internet-Draft Access Right Distribution Protocol(ARDP) December 2008 11. 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. [RFC2326] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [SIPRTSP] X. Marjou, J. Lindquist, P. Rajagopal, M. Said, S. Ganesan "Session Description Protocol (SDP) Offer/Answer Model For Media Control Protocol", Internet Draft. [AAA] Hiroaki Satou, Hiroshi Ohta, Christian Jacquenet, Tsunemasa Hayashi, Haixiang He, "AAA Framework for Multicasting", Internet Draft. 12. Authors' Address Alexandre Cassen Freebox S.A. 8, Rue de la Ville l Eveque 75008 FR EMail: acassen<-at->freebox<-dot->fr Cassen Expires July 16, 2009 [Page 35]