[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Internet Engineering Task Force                         Alexandre Cassen
Internet-Draft                                              Freebox S.A.
Expires: February 01, 2008                               August 01, 2007


               Access Right Distribution Protocol (ARDP)
        <draft-cassen-access-right-distribution-protocol-04.txt>


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on February 01, 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 February 01, 2008                [Page 1]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 ........... 8
        2.3. Global Operation workflow ............................. 9
     3.  Multicast Protocol Part .................................. 10
        3.1. IP/UDP packet field descriptions ..................... 10
        3.2. ARDP Packet Format ................................... 10
        3.3. ARDP AVP Packet Format ............................... 13
        3.4. CP Conditional Access Attributes message format ...... 16
        3.5. CP SeviceID Attributes message format ................ 17
        3.6. CP ClassID Attributes message format ................. 19
        3.7. ClientID Attributes message format ................... 20
     4.  Unicast Protocol Part .................................... 21
     5.  ARDP Server .............................................. 21
     6.  NE ARDP Client State Transition Diagram .................. 22
        6.1. Initialize State ..................................... 22
        6.2. Learning State ....................................... 24
     7.  Sending and receiving ARDP datagram ...................... 25
        7.1. Sending .............................................. 25
        7.2. Receiving ............................................ 25
     8.  Acknowledgments .......................................... 25
     9.  References ............................................... 26
     10. Editor s Address ......................................... 26
     11. Full Copyright Statement ................................. 27





















Cassen                 Expires February 01, 2008                [Page 2]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008                [Page 3]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008                [Page 4]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008                [Page 5]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008                [Page 6]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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.








Cassen                 Expires February 01, 2008                [Page 7]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


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
   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 February 01, 2008                [Page 8]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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.










Cassen                 Expires February 01, 2008                [Page 9]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


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
   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 AVPs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

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.






Cassen                 Expires February 01, 2008               [Page 10]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


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 Attributes message
      - 0x03 : CP ClassID Attributes message
      - 0x04 : ClientID Attributes 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.



Cassen                 Expires February 01, 2008               [Page 11]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


   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.

3.2.8. Source CP ID field

   Specifies the CP origin of the ARDP packet. This gives ARDP Client
   side the possibility to select authentication to be used as sanity
   check, validity of message data regarding CP Assigned MCAST group.
   An Operator ID is a 32bit value identifying in a unique way any CP.
   This can be an IPv4 IP address used as point of presence in ARDP
   Backbone.

3.2.9. Global Message Data field

   For this first version of ARDP protocol, this field is only used
   during ClientID flooding to indicate which CP the ClientID flooding
   message belongs to in order to identify CP ClientID namespace.

3.2.10. CP Signature field

   Includes the digital signature (if used) to authenticate ARDP packet.
   On ARDP Client side, Source CP ID field indicates which CP secret or
   key to be used. Depending on authentication type use, this field is
   96bit length long for HMAC-MD5-96bit signature and 1024bit length
   long for 1024bit RSA signature.






















Cassen                 Expires February 01, 2008               [Page 12]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


3.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].

3.3.1. 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).

















Cassen                 Expires February 01, 2008               [Page 13]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


                                            +---------------------+
                                            |    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  |
     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                                 |    |     |    |     |    |
   Multicast-     65545 3.5.5    Address    | M  |  P  |    |  V  | N  |
     Fallback-Group                         |    |     |    |     |    |
   Unicast-       65546 3.5.6    Address    | M  |  P  |    |  V  | N  |
     Fallback-Source                        |    |     |    |     |    |
   Bitrate        65547 3.5.7    Unsigned32 | M  |  P  |    |  V  | N  |
   Capabilities   65548 3.5.8    Unsigned32 | M  |  P  |    |  V  | N  |
   Service-Name   65549 3.5.9    UTF8String | M  |  P  |    |  V  | N  |
   Version-Code   65550 3.5.10   Unsigned32 | M  |  P  |    |  V  | N  |
   -----------------------------------------|----+-----+----+-----|----|

3.3.2. ARDP Grouped AVPs

   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                                 |    |     |    |     |    |



Cassen                 Expires February 01, 2008               [Page 14]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


   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                                 |    |     |    |     |    |
   Free-Access-   65585 3.5.11    Grouped   | M  |  P  |    |  V  | N  |
     TimeSlot-Add                           |    |     |    |     |    |
   Free-Access-   65586 3.5.12    Grouped   | M  |  P  |    |  V  | N  |
     TimeSlot-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                                 |    |     |    |     |    |
   -----------------------------------------|----+-----+----+-----|----|

3.3.3. AVP Auth-Service-Id

   The Auth-Service-Id AVP (AVP code 65536) is of type Unsigned32 and
   refers to an ARDP ServiceID.

3.3.4. AVP Auth-Class-Id

   The Auth-Class-Id AVP (AVP code 65537) is of type Unsigned32 and
   refers to an ARDP ClassID.

3.3.5. AVP Auth-Client-Id

   The Auth-Client-Id AVP (AVP code 65538) is of type Unsigned32 and
   refers to an ARDP ClientID.

3.3.6. 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.

3.3.7. 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.

3.3.8. 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).





Cassen                 Expires February 01, 2008               [Page 15]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


3.4. Conditional Access Attributes message format

   Conditional Access attributes carry specific authentication,
   accounting, authorization, routing and security information as well
   as configuration for a specific ClientID.

3.4.1. 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.

3.4.2. 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 }

3.4.3. 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



Cassen                 Expires February 01, 2008               [Page 16]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


   [RFC4234]:

         Accounting-Zap ::= < AVP Header: 65582 >
                            { Auth-Client-Id }
                            { Accounting-Server }
                          * [{ Auth-Service-Id } / { Auth-Class-Id }]


3.5. 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.

3.5.1. 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 }
                         * { Multicast-Fallback-Group }
                         * { Unicast-Fallback-Source }
                         * { Bitrate }
                         * { Capabilities }
                         * { Service-Name }

   This AVP allow ARDP sending source to append ServiceID and optional
   AVPs.

3.5.2. 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 }





Cassen                 Expires February 01, 2008               [Page 17]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


3.5.3. 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.

3.5.4. 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].

3.5.5. AVP Multicast-Fallback-Group

   The Multicast-Fallback-Group AVP (AVP code 65545) is of type Address
   and is specific to ServiceID AVPs (Add and Delete). It 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.5.6. AVP Unicast-Fallback-Source

   The Unicast-Fallback-Source AVP (AVP code 65546) 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-Fallback-
   Group AVP. This is useful information when using SSM for wide-area
   multicast.

3.5.7. AVP Bitrate

   The Bitrate AVP (AVP code 65547) is of type Unsigned32 and is
   specific to ServiceID AVPs (Add and Delete). It specifies ServiceID
   streaming Bitrate.

3.5.8. 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.

3.5.9. 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



Cassen                 Expires February 01, 2008               [Page 18]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


   description.

3.5.10. 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.

3.5.11. AVP Free-Access-TimeSlot-Add

   The Free-Access-TimeSlot-Add AVP (AVP code 65585) is of type Grouped
   and is specific to ServiceID AVPs (Add and Delete). It add a Free
   Access period during which every CPE will have full access to
   Service.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         Free-Access-TimeSlot-Add ::= < AVP Header: 65585 >
                                      { Auth-Service-Id }
                                      { Auth-Begin-Validity }
                                      { Auth-End-Validity }

3.5.11. AVP Free-Access-TimeSlot-Delete

   The Free-Access-TimeSlot-Delete AVP (AVP code 65586) is of type
   Grouped and is specific to ServiceID AVPs (Add and Delete). It
   removes a Free Access period for a specific ServiceID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         Free-Access-TimeSlot-Delete ::= < AVP Header: 65586 >
                                         { Auth-Service-Id }

3.6. 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.

3.6.1. 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]:




Cassen                 Expires February 01, 2008               [Page 19]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


         ClassID-Add ::= < AVP Header: 65587 >
                         { Auth-Class-Id }
                         { Version-Code }
                         { Auth-Service-Id }

   This AVP allow ARDP sending source to append ClassID AVPs.

3.6.2. 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 }

3.7. 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.

3.7.1. 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
   [RFC4234]:

         ClientID-Add ::= < AVP Header: 65589 >
                          { Auth-Client-Id }
                          { Auth-Client-Address }
                        * [ AVP ]

   This AVP allow ARDP sending source to append any optional AVPs.

3.7.2. 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 }



Cassen                 Expires February 01, 2008               [Page 20]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


3.7.3. AVP Auth-Client-Address

   The ClientID-Delete AVP (AVP code 65539) is of type Address. It
   specifies the NE Client IP Address.

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:

        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



Cassen                 Expires February 01, 2008               [Page 21]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


        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:

        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



Cassen                 Expires February 01, 2008               [Page 22]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 2007


          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 February 01, 2008               [Page 23]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008               [Page 24]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008               [Page 25]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008               [Page 26]


Internet-Draft    Access Right Distribution Protocol(ARDP)   August 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 February 01, 2008               [Page 27]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/