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

Versions: 00 01 02 03 04 05 06

Internet Engineering Task Force                         Alexandre Cassen
Internet-Draft                                              Freebox S.A.
Expires: September 27, 2006                               March 27, 2006


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


Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on September 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a protocol to securely distribute channel
   access rights to TVoDSL customers using multicast over a national
   backbone. The protocol typically runs on DSLAM or any other piece of
   equipments to locally store owned customers TV channel access right.
   This design provides access control at edge level.






Cassen                   Expires September 27, 2006             [Page 1]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


Table of Contents

     1.  Introduction .............................................. 2
        1.1. Scope ................................................. 3
        1.2. Definitions ........................................... 3
     2.  ARDP Overview ............................................. 5
        2.1. Interface with routing stack .......................... 6
        2.2. Confidentiality and security considerations ........... 6
        2.3. Global Operation workflow ............................. 7
     3.  Multicast Protocol Part ................................... 8
        3.1. IP/UDP packet field descriptions ...................... 8
        3.2. ARDP Packet Format .................................... 9
        3.3. Operator Right message format ........................ 11
        3.4. Sevice ID message format ............................. 12
        3.5. Client ID message format ............................. 13
        3.6. Unencrypted Timeslot message format .................. 14
     4.  Unicast Protocol Part .................................... 14
     5.  ARDP Server .............................................. 15
     6.  DSLAM ARDP Client Operations ............................. 16
        6.1. Initialize State ..................................... 16
        6.2. Learning State ....................................... 17
     7.  Sending and receiving ARDP datagram ...................... 17
        7.1. Sending .............................................. 18
        7.2. Receiving ............................................ 18
     8.  Acknowledgments .......................................... 18
     9.  References ............................................... 18
     10. Editor s Address ......................................... 18
     11. Full Copyright Statement ................................. 19























Cassen                   Expires September 27, 2006             [Page 2]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


1. Introduction

   Standard digital TV security models are based on smartcard
   intelligence at the end user Set-Top-Box side. We will not present
   global goal and design of Conditional Access System since this is not
   the scope of this document. We can simply remind that digital pay TV
   is based on such a system where EMM (Entitlement Management Message),
   an encrypted message, provides private conditional access information
   concerning the broadcast services one viewer is allowed to receive.
   The challenge of such an architecture is to provide strong
   cryptographic systems to protect EMM messages against piracy since
   EMM are stored directly into the Set-Top-Box/smartcard. If this
   system can be considered as good for broadcasting where upstream (on
   Set-Top-Box side) has high latency, this design can be enhanced for
   upstream low latency network such as xDSL.

   The very first security consideration rely more on trust edge network
   or any routing equipements and reduce end user Set-Top-Box
   intelligence/complexity. xDSL network and architecture provide a way
   to dissociate Conditionnal Acces and video content protection. While
   stream can still use standard DVB-CSA scrambling design, EMM
   equivalent can be stored into edge routing equipment.  Set-Top-Box is
   considered as hostile equipement and the idea is to reduce to the max
   the action it may have. For services like TVoDSL, this design offers
   a secure conditional access design by physically dissociating both
   security components. Stream access is controled during stream
   subscribtion stage. The Set-Top-Box simply requests for a video
   stream and the edge equipment grants or not access according to its
   local access database (local right cache).

   The challenge for now is to find a secure and scalable way to
   populate edge equipments access database. We can be inspired from the
   broadcasting model by using multicast transmission to distribute
   access rights over xDSL backbone. The following document will present
   a protocol used on top of IP to securely distribute those access
   rights.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

   The IESG/IETF take no position regarding the validity or scope of any
   intellectual property right or other rights that might be claimed to
   pertain to the implementation or use of the technology, or the extent
   to which any license under such rights might or might not be
   available.  See the IETF IPR web page at http://www.ietf.org/ipr.html
   for additional information.




Cassen                   Expires September 27, 2006             [Page 3]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


1.1 Scope

   The remainder of this document describes the features, design goals,
   and theory of operation of Access Right Distribution Protocol - The
   message format, protocol processing rules and state machine that
   guarantee safe and secure operations.

1.2 Definitions

   FSM                    Finite State Machine. Coming from Discrete
                          Mathematics scheme. It defines the structure
                          which handles each state and state
                          transitions.

   ARDP Backbone          A Wide Area Network made of thousands of
                          ARDP clients. For xDSL network architecture,
                          the word ARDP client refers to a DSLAM ARDP
                          Client. ARDP backbone is typically a private
                          network.

   DSLAM ARDP Client      A Software component running ARDP protocol on
                          network edge routing equipments. It is
                          responsible for DSLAM local right cache
                          management and is interacting with Master ARDP
                          Server. It stores all Operator Assigned MCAST
                          group, associated security elements (RSA
                          public key) and customer Access Right.

   Assigned MCAST group   ISP broadcasting on TVoDSL is using multicast
                          over ethernet as streaming vector. It is
                          responsible for multicast routing and network
                          architecture. For each TV Operator with a
                          point of presence in ISP network, a multicast
                          network IP range is assigned. Each TV Operator
                          is in charge of distributing ARDP right for
                          this multicast ip range to ARDP backbone.

   TV Operator            An operator is in charge of multicast content
                          streaming. Each TV Operator is also in charge
                          of distributing ARDP right for its assigned
                          multicast ip range over ARDP backbone.

   Operator ARDP Server   Each TV Operator stores an RSA keypair and
                          uses RSA private key to sign all ARDP protocol
                          datagrams sent to ARDP Backbone. The RSA
                          public key is exported to all DSLAM ARDP
                          Clients.




Cassen                   Expires September 27, 2006             [Page 4]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   Master ARDP Server     A server running ARDP protocol and acting as
                          root authority. This server distributes
                          ClientID over ARDP backbone and forwards ARDP
                          requests to TV Operators ARDP servers. It
                          manages ClientID flooding, unencrypted
                          Timeslot flooding, channel flooding and any
                          ARDP right for MCAST group it may manage.

   ClientID               An abstraction modelizing association between
                          customer Identification number and physical
                          IP address (or MAC address or phone number).
                          Each IP address (or MAC or phone number) can
                          have multiple ClientID, each one is unique to
                          each TV Operator namespace.

   Access Right           An abstraction modelizing a customer
                          conditional access on a specific channel.
                          It determines whether or not a ClientID
                          can access a specific channel.

   Unencrypted TimeSlot   An abstraction modelizing a global Access
                          Right for all ClientID to a specific
                          channel and during a specific validity time.

2. ARDP Overview

   We can localize each ARDP architecture component on the following
   diagram :

               +-----------+        +-----------+
               |           |        |           |
     __________| OP_ARDP_1 |________| OP_ARDP_2 |________________
    /          |           |        |           |                \
   /           +-----------+        +-----------+                 \
   |                                                              |
   |                        ARDP Backbone                         |
   |                                                              |
   \   +----------+     +---------+   +---------+  +---------+    /
    \__|  Master  |_____| DSLAM 1 |___| DSLAM 2 |..| DSLAM n |___/
       |   ARDP   |     +---------+   +---------+  +---------+
       +----------+

   Master ARDP : Master ARDP Server
   OP_ARDP_1   : TV Operator 1 running Operator 1 ARDP Server.
   OP_ARDP_2   : TV Operator 2 running Operator 2 ARDP Server.
   DSLAM 1     : DSLAM 1 running DSLAM 1 ARDP Client
   DSLAM 2     : DSLAM 2 running DSLAM 2 ARDP Client
   DSLAM n     : DSLAM n running DSLAM n ARDP Client



Cassen                   Expires September 27, 2006             [Page 5]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   ARDP is a protocol running over multicast and targetting
   centralization of access right flooding. The global operating mode is
   a multicast Client/Server, respectively localized on DSLAM and Master
   ARDP Server/Operator ARDP Server. The Master ARDP Server handles
   massive access right, ClientID  and Unencrypted Timeslot flooding.
   All customer ClientID are flooded from Master ARDP Server. All
   customer access right are flooded from Operator ARDP Server. Each
   Operator ARDP Server is flooding access right for Assigned MCAST
   group. DSLAM ARDP Client is then filtering received multicast
   datagrams to only store access right, for customers it hosts.

   ARDP finality is then to maintain access right cache integrity on
   DSLAM ARDP Client side and to offer any TV Operator the ability to
   flood directly access right over ARDP Backbone. An RSA signature is
   used to guaranty protocol datagram authenticity and integrity using a
   1024bits RSA keypair. Each ARDP Server stores its RSA private key and
   DSLAM ARDP Client stores all RSA public key. A Public Key
   Infrastructure can be used to distribute RSA pubkey, we will not
   detail this part since it is out of the scope of this document.

2.1. Interface with routing stack

   In TVoDSL architecture, stream subscription is most of the time done
   through IGMP (as described in [RFC3376]) since streaming is done via
   multicast. ARDP operates close to edge routing equipment stack at
   IGMP level. The diagram below shows general ARDP operations :

   +--------------------------------------------------------+
   | DSLAM Routing Software                                 |
   |                                     +--------------+   |
   |                                     | Access Right |   |
   |                                     |    Cache     |   |
   |   +------------------------+        +------^-------+   |
   |   |   CORE Routing Stack   |               |           |
   |   |                 +------+        +------v-----+     |
   |   |                 | IGMP |<------>| ARDP Stack |     |
   |   +-----------------+--^---+        +------------+     |
   +------------------------|-------------------------------+
                            |
                            |
                     +------v------+
                     | Set-Top-Box |
                     +-------------+

   When the Set-Top-Box requests for a channel, it generates an IGMP
   Join request caught by DSLAM IGMP stack. Before processing the stream
   subscription operation, IGMP stack requests authorisation to ARDP
   Stack. If access is granted by ARDP then IGMP stack proceeds to



Cassen                   Expires September 27, 2006             [Page 6]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   perform stream subscription or any multicast routing related task.

2.2. Confidentiality and security considerations

   First of all, ARDP operates in a separate/dedicated network plane
   without any physical link with the Set-Top-Box network. It is
   mandatory to separate the ARDP network plane from the Set-Top-Box
   network plane. Only edge routing equipments can access the ARDP plane
   and Set-Top-Box one but without any routings nor forwardings rules
   between both planes.

   ARDP protocol is disgned to operate in a multi-operator fashion. From
   the networking point of view it is running multiple multicast sending
   sources at a time. One of its goales is to give full access to a TV
   Operator on streams it is responsible for.  Master Operator provides
   "Assigned MCAST group" to each TV Operator. Using ARDP, a TV Operator
   can manage Access Right through head-end in realtime using
   flexibility of multicast.

   ARDP architecture defines a hierarchy between Master Operator and TV
   Operator.  On the one hand Master Operator, formerly a TVoDSL
   operator owning network infrastructure, has a role of arbitration and
   root authority :

     - Distributes all TV Operator ClientID over ARDP Backbone. Each TV
       Operator has its own namespace for ClientID but the association
       between a TV Operator ClientID and a physical client (customer)
       identification (IP address, MAC address, phone number, ...) is
       only known by Master Operator.

     - Assigns multicast IP range to TV Operator and distributes this
       association to ARDP Backbone. Each TV Operator will be able to
       assign Access Right to the multicast groups provided by the
       Master Operator.

     - Requests TV Operator ARDP Server to distribute Access Right to
       a particular ClientID.

   On the other hand, TV Operator is a supervisor authority for
   distributing ARDP Access Right to Assigned MCAST group :

     - Handles Master Operator ClientID request by flooding in response
       the associated ARDP Access Right.

     - Distributes Unencrypted Timeslot and Access Right.






Cassen                   Expires September 27, 2006             [Page 7]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


2.3. Global Operation workflow

   The following diagram gives the general workflow of ARDP protocol.

               +-----------+        +-----------+
               |           |        |           |
     __________| OP_ARDP_1 |________| OP_ARDP_2 |________________
    /    +---->|           |        |           |                \
   /     |     +-----------+        +-----------+                 \
   |     |               \                                        |
   |     |                \(e)                                    |
   |     |                 \                                      |
   |     |(d)    ^    ^     v      ARDP Backbone                  |
   |     |      /    /                                            |
   |     |     /(c) /(b)                                          |
   |     |    /    /                                              |
   \   +----------+     +---------+   +---------+  +---------+    /
    \__|  Master  |_____| DSLAM 1 |___| DSLAM 2 |..| DSLAM n |___/
       |   ARDP   |     +---------+   +---------+  +---------+
       +----^-----+          |
            +----------------+
                   (a)

   This sample configuration illustrates ARDP operation workflow from ARDP
   protocol boot-up state (a) through ClientID and right flooding stage
   (b), (c), (d) and (e). Protocol operates at both Multicast and
   Unicast levels such as follows :

      (a) Unicast message : DSLAM 1 informs Master ARDP Server of its
          initialization state. It requests for ClientID and right
          flooding.

      (b)+(c) Multicast message : Master ARDP Server floods ClientID
              and Access Right for each customer hosted by DSLAM 1.

      (d) Unicast message : Master ARDP Server requests right flooding
          to each remote Operator ARDP Server for given ClientID in
          each TV Operator ClientID namespace.

      (e) Multicast message : In response to (d) each Operator ARDP
          Server floods Access Right requested by Master ARDP Server.

3. Multicast Protocol Part

   ARDP protocol operates at multicast level and runs over UDP.
   ARDP packet are encapsulated in IP/UDP packets and sent to a
   routed multicast IPv4 address over ARDP Backbone. Multicast offers
   a many-to-many entities discussion. Using UDP encapsulation offers



Cassen                   Expires September 27, 2006             [Page 8]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   the ability to run multiple ARDP plane using the same multicast
   routing ressource.

3.1. IP/UDP packet field descriptions

   For the current ARDP version 1 there is no layer3/4 restrictions.
   Multicast TTL must be set with a proper value permitting
   backbone traversal.

3.2. ARDP header packet format

   Each ARDP protocoal datagram starts with ARDP header as follows.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Ver  |   Hl  |   Msg Type    |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Count Msg    |   Auth Type   |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Source Operator ID                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Global Message Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                       Operator Signature                      |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.1. Version field

   Specifies the ARDP protocol version a packet belongs to. Our current
   document describes Version 1.

3.2.2. Header Length field

   Specifies the length of the ARDP header.

3.2.3. Message Type field

   Specifies the type of ARDP packet data part following the ARDP
   header.  ARDP message types are :

      - 0x01 : Operator Right message
      - 0x02 : ServiceID message
      - 0x03 : ClientID message
      - 0x04 : Unencrypted Timeslot message




Cassen                   Expires September 27, 2006             [Page 9]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


3.2.4. Size field

   Specifies the total size of the ARDP packet including ARDP header and
   message data.

3.2.5. Count Messages field

   Specifies the number ARDP message data included in the global ARDP
   packet.

3.2.6. Authentication Type field

   Specifies kind of authentication used to sign the ARDP packet.
   Mandatory Authentication Type are :

      - 0x01 : No authentication signature
      - 0x02 : Use HMAC-MD5-96bit signature as described in [RFC2104]
      - 0x03 : Use RSA 1024bit signature as described in [RFC2437]

3.2.7. Source Operator ID field

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

3.2.8. Global Message Data field

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

3.2.9. Operator Signature field

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









Cassen                   Expires September 27, 2006            [Page 10]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


3.3. Operator Right message format

   This message type refers to a unary Access Right and responds to the
   following message format :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Command    |               Reserved                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Service ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Client ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Begin Validity         |        End Of Validity        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.1. Command field

   Specifies whether to add or delete a right. Valid commands are :

      - 0x01 : Add a new right
      - 0x02 : Delete a right

3.3.2. Service ID field

   Specifies a TV Operator service, formerly these are routings pieces of informations
   identifying a TV Operator channel.

3.3.3. Client ID field

   Specifies the ClientID this right refers to.

3.3.4. Begin Validity field

   Specifies the beginning of validity date.

3.3.5. End Of Validity field

   Specifies the end of validity date. This expiration date prevents
   from storing expired access rights.










Cassen                   Expires September 27, 2006            [Page 11]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


3.4. Service ID message format

   This message type refers to a unary TV Operator service description and
   responds to the following message format :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Service ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Version Code                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Multicast Group                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Unicast Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Fallback Multicast Group                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Fallback Unicast Source                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Multicast TTL         |     Fallback Multicast TTL    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                      Service String                           |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.4.1. Service ID field

   Specifies a unique ID into the TV Operator namespace.

3.4.2. Version Code field

   Specifies a version number to identify the service plan this Service
   ID belongs to.

3.4.3. Multicast Group field

   Specifies an IPv4 Multicast group into the Assigned MCAST group
   range.

3.4.4. Unicast Source field

   Specifies an IPv4 IP address source of streaming refering to
   Multicast Group field.  This is useful information when using SSM for
   wide-area multicast as described in [RFC3569].



Cassen                   Expires September 27, 2006            [Page 12]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


3.4.5. Fallback Multicast Group field

   Specifies an IPv4 multicast group into the assigned MCAST group
   range.

3.4.6. Fallback Unicast Source field

   Specifies an IPv4 IP address source of streaming refering to Fallback
   Multicast Group field.  This is useful information when using SSM for
   wide-area multicast.

3.4.7. Multicast TTL field

   Specifies the refresh rate in millisecond for next ARDP right polling
   from edge routing network equipment. DSLAM periodically poll ARDP
   right cache to ensure Access Right validity during stream
   subscription life. This field refer to Multicast group field.

3.4.8. Fallback Multicast TTL field

   Specifies the refresh rate in millisecond for next ARDP right polling
   done by the edge routing network equipment. DSLAM periodically polls
   ARDP right cache to ensure Access Right validity during stream
   subscription life. This field refers to Fallback Multicast group
   field.

3.4.9. Service String field

   Specifies a String as comment for the Service ID.

3.5. Client ID message format

   This message type refers to a unary ClientID association and responds
   to the following message format :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Client ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     DSLAM Client IP Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each customer owns a unique ClientID into each TV Operator namespace.
   DSLAM Client IP Address is unique to each TV Operator namespace.






Cassen                   Expires September 27, 2006            [Page 13]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


3.5.1. Client ID field

   Specifies the ClientID this association refer to.

3.5.2. DSLAM Client IP Address field

   Specifies the physical IP Address.

3.6. Unencrypted Timeslot message format

   This message type refers to a unary unencrypted timeslot and responds
   to the following message format :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Command    |               Reserved                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Service ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Begin Time Slot          |        End Time Slot          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.6.1. Command field

   Specifies whether to add or delete an Unencrypted Timeslot. Valid
   commands are :

      - 0x01 : Add a new Timeslot
      - 0x02 : Delete a Timeslot

3.6.2. Service ID field

   Specifies a unique ID into the TV Operator namespace.

3.6.3. Begin Time Slot field

   Specifies the begin TimeSlot validity date.

3.6.4. End Time Slot field

   Specifies the end of TimeSlot validity date. This expiration date
   prevents from storing expired Time Slot.

4. Unicast Protocol Part

   ARDP Unicast datagrams are used by DSLAM ARDP Client to request ARDP
   Master Server for right cache feeding. Those messages are using



Cassen                   Expires September 27, 2006            [Page 14]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   general ARDP protocol header presented in section 3.2. Authentication
   is not mandatory since flows are local to private ARDP Backbone from
   DSLAM to Master ARDP Server. Unicast messages are vehiculed over
   IP/TCP and are :

      - 0x01 : DSLAM Access Right populate request
      - 0x02 : DSLAM ClientID populate request
      - 0x03 : DSLAM ServiceID populate request

   DSLAM ARDP Client fills the Global Message Data field with its ID.
   Formerly it used the IPv4 IP Address provided for ARDP Backbone point
   of presence.

5. ARDP Server

   The global goal of ARDP architecture is to focus protocol complexity
   onto the ARDP server instead of ARDP client. As previously explained,
   ARDP protocol reduce Set-Top-Box complexity by deporting conditional
   access to edge routing equipment. The same statement is used for ARDP
   Server. It is responsible for ARDP protocol messages flooding and
   scheduled flooding jobs. In this many-to-many networking scheme it is
   convenient to centralize complexity onto the server side for
   maintenance and scalability reasons.

   ARDP Server MUST perform the following operations :

      - MUST permanently flood TV Operator Service ID plane. If new
        Service ID plane is flooded then send all Access Right
        (of this TV Operator).

      - If ARDP server is MASTER ARDP Server then:

        o Only accept Unicast requests from DSLAM ARDP Client

        o Only send Unicast request to remote TV Operator
          ARDP Server

        Else

        o Only accept unicast requests from Master ARDP Server

        Endif

      - MUST periodically flood whole Access Right

      - MUST sequencely flood ClientID before any Access Right
        related.




Cassen                   Expires September 27, 2006            [Page 15]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


6. DSLAM ARDP Client State Transition Diagram

   ARDP Client side manages local access right cache. Its FSM
   is divided into 2 states as follows :

   +------------------+                         +------------------+
   |                  |------------------------>|                  |
   |    Initialize    |                         |     Learning     |
   |                  |<------------------------|                  |
   +------------------+                         +------------------+

6.1. Initialize State

   The purpose of this state is to boot up ARDP protocol. While in this
   state, ARDP client MUST perform the following operations :

      - If Authentication is used then MUST load TV Operators secrets
        for HMAC-MD5-96bit authentication or load RSA public key if
        RSA authentication is used.

      - MUST wait until TV Operator Service IDs are received

      - MUST connect to ARDP Master Server only to request for
        ClientID flooding.

      - If ClientID table is empty then:

        o Re-schedule a new ClientID flooding request to
          Master ARDP Server.

        o If ClientID table still empty until max_retry then:
          . Disable scheduling ClientID flooding retry.
          . Re-schedule a new ClientID request with a longer
            delay
          Endif

        Else

        o Schedule Access Right flooding request to Master
          ARDP Server.

        Endif

      - If Access Right Table is empty then:

        o Re-schedule a new Access Right flooding request to
          Master ARDP Server.




Cassen                   Expires September 27, 2006            [Page 16]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


        o If Access Right table still empty until max_retry then:
          . Disable scheduling Access Right flooding retry.
          . Re-schedule a new Access Right request with a longer
            delay
          Endif

        Else

        o Transit to Learning state.

        Endif

   In this pseudo code we can note that "Re-schedule" can mean inhibit
   flooding request since Master ARDP Server can schedule any request
   since it has the knowledge of the whole ARDP Backbone point of
   presence.

6.2. Learning State

   The purpose of this state is to enter a long time listening stage.
   While in this state, ARDP client MUST perform the following
   operations :

      - When receiving ClientID message, if ClientID is refering to a
        local DSLAM IP Address then store this new correspondance.

      - When receiving ClientID message then MUST remove any Access
        Right associated if already exists.

      - When receiving Access Right message then MUST replace any Access
        Right related to the same ClientID/ServiceID.

      - When receiving new ServiceID, means when "Version Code" field is
        different from current ARDP Client Service version code then
        remove any Access Right related to the TV Operator source of the
        message.

      - If Access Right Table is empty then:

        o Transit to Initialize state.

        Endif









Cassen                   Expires September 27, 2006            [Page 17]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


7. Sending and receiving ARDP datagram

7.1. Sending

   Any ARDP sending source MUST perform the following operations:

      - MUST fill ARDP protocol header in accordance with protocol
        specification in section 3.

      - If Authentication is used sign ARDP datagram.

7.2. Receiving

   Any ARDP received datagram MUST perform the following operations:

      - MUST perform sanity check over datagram to conform ARDP header
        elements with real data content.

      - If Authentication is used then:

        o MUST verify HMAC-MD5-96bit or RSA signature. If signature
          is not valid then:

          . Drop incoming datagram.

          Endif

        Endif

8. Acknowledgments

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

9. References

   [HMAC]    Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", Work in Progress.

   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
             for Message Authentication", RFC 2104, February 1997.

   [RFC2437] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
             Specifications Version 2.0", RFC 2437, October 1998.

   [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner,
             A. Thyagarajan, "Internet Group Management Protocol,
             Version 3", RFC 3376, October 2002.



Cassen                   Expires September 27, 2006            [Page 18]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   [RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
             Multicast (SSM)", RFC 3569, July 2003.

10. Editor s Address

   Alexandre Cassen
   Freebox S.A.
   8, Rue de la Ville l Eveque
   75008
   FR

   Phone:+33 1 73 50 25 00
   EMail: acassen<at>freebox<dot>fr

11. Full Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary



Cassen                   Expires September 27, 2006            [Page 19]


Internet-Draft   Access Right Distribution Protocol (ARDP)    March 2006


   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
















































Cassen                   Expires September 27, 2006            [Page 20]


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