[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
Internet Engineering Task Force                   Tsunemasa Hayashi, NTT
Internet Draft                                        Daisuke Andou, NTT
May, 2003                                   Haixiang He, Nortel Networks
Expires: November, 2003                    Wassim Tawbi, Nortel Networks
                             Teruki Niki, Matsushita Electric Industrial


          Internet Group membership Authentication Protocol (IGAP)
                     <draft-hayashi-igap-02.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted.

   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.


Abstract

   This memo documents the Internet Group membership Authentication
   Protocol (IGAP), a protocol developed by NTT, Nortel Networks and
   Panasonic. IGAP provides not only the group membership communication
   functionality between hosts and their first hop routers as IGMP does,
   but also user authentication and accounting functionalities. IGAP is
   designed to be used in a controlled or managed IPv4 multicast
   environment.  It provides with a viable alternative to IGMP in IP
   multicast networks when authentication and accounting are required.
   The user authentication information in IGAP can enable a provider to
   control the distribution of the multicast traffic as well as
   collecting real time user accounting information in an environment
   where the last hop access networks are not shared.


1. Introduction

   IP multicast provides an efficient mechanism for delivering packets
   to multiple destinations. Unfortunately, IP multicast services,
   especially commercial IP multicast services, are not widely
   deployed. One of the important reasons that discourage the deployment



Hayashi, Andou, He, Tawbi, Niki                                 [Page 1]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   is related to the current IP multicast model.

   The current IP multicast model provides by nature a non-secure
   non-controlled way for end systems attached to a network to access
   multicast traffic. Lack of access control in this model makes it
   difficult for a service provider to generate enough revenue to
   sustain multicast services such as IP multicast based Internet TV.

   A provider can enforce such access control through static
   configuration on the last hop network devices including Ethernet
   switches or routers. There are two major disadvantages in this
   approach. First, static configuration does not fit into the
   environment where the access control policy changes dynamically.
   Second, the access control policy can only be based on physical
   ports,
   hosts IP or MAC addresses and hence it can not be used in an
   environment where user based access control policy is required. This
   leads to the need for a comprehensive way to authenticate and
   authorize end systems before they are granted access to some
   multicast groups.

   The Internet Group membership Authentication Protocol (IGAP) is
   designed to allow last-hop network devices to enforce multicast
   receiver access control in a non-shared access networks environment.
   IGAP provides not only group membership communication but also user
   authentication and accounting functionalities. IGAP can be used when
   authentication and accounting are required for multicast data access
   while IGMP can be used when they are not required. IGAP is used only
   in an IPv4 environment. IGAP enables an IP multicast service provider
   to authenticate and authorize a host's requests to join a specific
   multicast group based on its user's authentication information and
   then to control the user's access to the multicast traffic
   accordingly.

   IGAP uses a user-based authentication model rather than IP or MAC
   address based authentication model. The benefits of a user-based
   model are well known. It offers operational simplicity and
   flexibility, in particular with respect to adds, moves, and changes.

   Another issue that discourages the wide deployment of IP multicast
   services is the lack of multicast network management functions

   especially an effective multicast accounting function. Effective
   user-based accounting information is critical in two aspects. On one
   hand network providers who provide commercial multicast services need
   to accurately identify the users and collect their usage information
   to generate correct billing information. On the other hand some
   content providers need to learn the content usage information. For
   example, in IP multicast based Internet TV services, network
   providers need to know which TV program is watched and how long a
   user watches so that they can charge the user differently based on



Hayashi, Andou, He, Tawbi, Niki                                 [Page 2]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   the values of the TV programs. In such services, content providers
   and TV program owners need to know how many viewers for a TV program
   and how long they watch the TV program so they can generate
   appropriate advertisement revenue.

   IGAP combines the user information including user ID with the
   multicast group addresses that reflect the different
   contents. Authenticated and authorized group join requests enable
   providers to effectively collect the user usage information for
   different content.

   IGAP not only encourages the wide deployment of new commercial IP
   multicast services, but also can be used in non-commercial
   environments such as enterprises. For example, IGAP can be used for
   closed video broadcasting. IGAP provides a mechanism to allow the
   access to the video broadcasting, only if the user is authenticated
   to join the video broadcasting.

   The transactions flow between an IGAP host client and an IGAP
   router. The IGAP router is assumed to be 1 hop from the IGAP host,
   such that the host does not have a route that bypasses the IGAP
   router. An IGAP host MUST authenticate itself to an IGAP router in
   order to join a multicast group.


2. IGAP Message Format

   IGAP messages are encapsulated in IP datagrams, with an IP protocol
   number of 2. All IGAP messages described in this document are sent
   with IP TTL 1, and contain the IP Router Alert option [RFC 2113] in
   their IP header.

   All IGAP message packets have the following format. The first 8
   octets consist of the same fields of IGMPv2 [IGMPv2].

   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 (bit)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      | Max Resp Time |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Group Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |    Subtype    |  Reserved-1   | Challenge ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Account Size  | Message Size  |          Reserved-2           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     User Account (16 bytes)                   .
   .                                                               .
   |                                                               |



Hayashi, Andou, He, Tawbi, Niki                                 [Page 3]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                     Message (64 bytes)                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.1 Type

   There are three types of IGAP messages.

   0x40 = IGAP Membership Report (IGAP Join)

   0x41 = IGAP Membership Query  (IGAP Query)

   0x42 = IGAP Leave Group       (IGAP Leave)

   Unrecognized message types should be silently ignored.


2.2 Max Response Time

   The meaning and the usage of Max Response Time are the same as those
   of the IGMP messages as described in RFC 2236 [IGMPv2].


2.3 Checksum

   Checksum covers the IGAP message (the entire IPv4 payload). The
   algorithm is the same as described in RFC2236 [IGMPv2].


2.4 Group Address

   In a Basic Query message described in section 2.6, the group address
   field is set to zero. In both Authentication Message and Accounting
   Message described in section 2.6, the group address field holds the
   IP multicast address of an IGAP Join. In a Membership Report or Leave
   Group message, the group address field holds the IP multicast group
   address of interest or the group being left.


2.5 Version

   This field indicates the version of IGAP. It is set to 0x10 to
   indicate the IGAP version 1.


2.6 Subtype



Hayashi, Andou, He, Tawbi, Niki                                 [Page 4]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   This field indicates the subtype of message transferred within the
   IGAP packet. Usage of this field is described later.

   The following 3 Subtypes are only used in IGAP join (Type 0x40).

       0x02 : Password Mechanism Join
              (Password-Join)
       0x03 : Challenge-Response Mechanism Join Challenge Request
              (Challenge-Request-Join)
       0x04 : Challenge-Response Mechanism Join Response
              (Challenge-Response-Join)

   The following 4 Subtypes are only used in IGAP Query (Type 0x41).

       0x21 : Basic Query
       0x23 : Challenge-Response Mechanism Challenge
              (Challenge)
       0x24 : Authentication Message
       0x25 : Accounting Message

   The following 4 Subtypes are used in IGAP Leave (Type 0x42).

       0x41 : Basic Leave
       0x42 : Password Mechanism Leave
              (Password-Leave)
       0x43 : Challenge-Response Mechanism Leave Challenge Request
              (Challenge-Request-Leave)
       0x44 : Challenge-Response Mechanism Leave Response
              (Challenge-Response-Leave)


2.7 Reserved-1

   This field should be set to 0x00. It is ignored when received.


2.8 Challenge ID

   This field is meaningful only when Challenge-Response authentication
   mechanism is used. The value is set according to the
   Challenge-Response protocol. If this field is not used, it is set to
   the default value of 0x00.


2.9 Account Size

   This field indicates the valid length in units of bytes of the User
   Account field described in section 2.12. The value must be less than
   or equal to 16. If this field is not used, it is set to the default
   value of 0x00.




Hayashi, Andou, He, Tawbi, Niki                                 [Page 5]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


2.10 Message Size

   This field indicates the valid length in units of bytes of the
   Message field described in section 2.13. The value must be less than
   or equal to 64. If this field is not used, it is set to the default
   value of 0x00.


2.11 Reserved-2

   This field should be set to 0x00. It is ignored when received.


2.12 User Account

   This field contains the user account information. The size of this
   field is 16 bytes. The length of the valid information is decided by
   the Account Size field described in section 2.9. If the user account
   occupies less than 16 bytes, the field is padded with 0x00.

2.13 Message

   This field contains certain information such as password. Different
   IGAP messages contain different Message information. The size of this
   field is 64 bytes. The length of the valid information is decided by
   the Message Size field described in section 2.10. If message
   information occupies less than 64 bytes, the field is padded with
   0x00.


3. Protocol Description

   IGAP is used for controlled or managed multicast services. IGMP is
   not needed when IGAP is used. An IGAP router should ignore all IGMP
   messages received on interfaces where IGAP is configured. The IGAP
   messages can be differentiated from the IGMP messages by the values
   of the "type" field as specified above.

   IGAP tracks individual host's group membership information. This
   feature allows an IGAP router to implement "fast leave" feature. In
   another word, IGAP does not implement Group-Specific Query feature
   that IGMPv2 has. When an IGAP router receives an IGAP Leave message,
   it will not send Group-Specific Query. Instead it will just delete
   corresponding state information. To facilitate tracking individual
   host's group membership, Host Suppression feature is not allowed in
   IGAP. The current version of IGAP does not support source filter
   features and such feature will be supported in the future version of
   IGAP.

   IGAP specifies different behaviors for IGAP hosts and for IGAP
   routers. If an IGAP router attempts to join some multicast groups, it



Hayashi, Andou, He, Tawbi, Niki                                 [Page 6]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   can perform both parts of the protocol.


3.1 User Authentication Mechanisms

   Currently IGAP supports two user authentication mechanisms for Join
   operation: simple and basic password authentication mechanism [PAP],
   and more advanced challenge-response authentication mechanism
   [CHAP]. These mechanisms are not used at the same time. Only one
   mechanism is configured to be used in a network. An IGAP
   implementation must support password authentication mechanism.
   Challenge-response authentication mechanism is optional.

   IGAP is intended for use with standard AAA servers such as RADIUS
   [RADIUS] servers that with necessary extensions can be used to
   achieve the authentication, authorization and accounting functions
   described in this document. However, IGAP is not limited for use with
   only standard AAA servers. It can be used with any back-end
   Authentication, Authorization, and Accounting functions or
   mechanisms. These functions or mechanisms can be located in different
   servers, within one server, or even within the IGAP routers. In this
   document, we use AAA servers as an example for these functions or
   mechanisms.


3.2 IGAP Host side Protocol Description

   This section describes the IGAP host behavior. Based on the
   configured authentication mechanism, an IGAP host behaves
   differently.


3.2.1 Password Authentication in Hosts

   When an IGAP host joins a multicast group, it should immediately
   transmit an unsolicited IGAP Membership Report that has a Subtype
   field of 0x02 (Password Mechanism Join) to the corresponding
   group. The User Account field is filled with the user account (user
   ID) while the Account Size field is set to the length of the user
   account. The Message field is filled with the user password while the
   Message Size field is set to the length of the password.

   When a host receives an IGAP Query, it sets delay timers as described
   in RFC2236 [IGMPv2]. If a timer for the group is already running, it
   is reset to the random value only if the requested Max Response Time
   is less than the remaining value of the running timer. When a group's
   timer expires, the host sends  a Membership Report that has a Subtype
   field of 0x02. In this message, the User Account field is filled with
   the user account (user ID) while the Account Size field is set to the
   length of the user account.




Hayashi, Andou, He, Tawbi, Niki                                 [Page 7]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   When an IGAP host leaves from a multicast group, it sends an IGAP
   Leave Group message to the all-routers multicast group
   (224.0.0.2). Normally an IGAP host sends a Leave message that has a
   Subtype field of 0x41 (Basic Leave). In Basic Leave, the User Account
   field is filled with the user account (user ID) while the Account
   Size field is set to the length of the user account. In scenarios
   where Leave message authentication is required, an IGAP host can send
   a Leave message that has a Subtype field of 0x42 (Password Mechanism
   Leave). In Password Mechanism Leave, the User Account and Account
   Size fields are set to the values as in Basic Leave. The Message
   field is filled with the user password while the Message Size field
   is set to the length of the password. An IGAP implementation must
   support Basic Leave. Password Mechanism Leave is optional.


3.2.2 Challenge-Response Authentication in Hosts

   When an IGAP host joins a multicast group, it sends a
   Challenge-Request-Join that has a Subtype field of 0x03
   (Challenge-Response Mechanism Join Challenge Request) to the
   corresponding group. The user Account field is filled with the user
   account (user ID) while the Account Size field is set to the length
   of the user account. The message field is not used.

   When the IGAP host receives a Challenge that has a Subtype of 0x23
   (Challenge-Response Mechanism Challenge) as a response to the
   Challenge-Request-Join, the IGAP host sends a Challenge-Response-Join
   that has a Subtype of 0x04 (Challenge-Response Mechanism Join
   Response). The Challenge ID field is set to the same value of
   Challenge ID on the Challenge packet. The user Account field is
   filled with the user account (user ID) while the Account Size field
   is set to the length of the user account. The Message field is set
   the results of MD5 calculation. The Message Size field is set to
   0x10.

   When a host receives an IGAP Query, it follows the behavior described
   above to set the delay timer. When a group's timer expires, the host
   sends a Membership Report that has a Subtype field of 0x03. In this
   message, the User Account field is filled with the user account (user
   ID) while the Account Size field is set to the length of the user
   account.

   When an IGAP host leaves from a multicast group, it sends an IGAP
   Leave Group message to the all-routers multicast group
   (224.0.0.2). Normally an IGAP host sends a Basic Leave message as
   described above. In scenarios where Leave message authentication is
   required, an IGAP host can send a Leave message that has a Subtype
   field of 0x43 (Challenge-Response Mechanism Leave Challenge
   Request). The User Account field is filled with the user account
   (user ID) while the Account Size field is set to the length of the
   user account. The other fields are not used. When the IGAP host



Hayashi, Andou, He, Tawbi, Niki                                 [Page 8]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   receives a Challenge that has a Subtype of 0x23 (Challenge-Response
   Mechanism Challenge) as a response to the Challenge-Response Leave,
   it sends a Leave message that has a Subtype field of 0x44
   (Challenge-Response Mechanism Leave Response). The User Account field
   and Account Size field are the same. The Message field is set to the
   results of MD5 calculation. The Message Size field is set to 0x10.
   An IGAP implementation must support Basic Leave. Challenge-Response
   Authentication Mechanism Leave is optional.


3.3 IGAP Router side Protocol Description

   IGAP routers use IGAP to learn which groups have members on each of
   their interfaces. They can be physical interfaces or virtual
   interfaces such as VLANs. An IGAP router keeps a list of multicast
   group memberships for each attached network, and a timer for each
   membership. Each group membership state has the conceptual following
   format:

        (group address, user-id, host IP, timer)

   IGAP routers periodically [Query Interval] send an IGAP Membership
   Query on each attached network to solicit membership information. On
   startup, a router SHOULD send [Startup Query Count] IGAP Membership
   Queries spaced closely together [Startup Query Interval] in order to
   quickly and reliably determine membership information. [Query
   Interval], [Startup Query Count] and [Startup Query Interval] are
   same as RFC 2236 [IGMPv2].

   An IGAP Membership Query is addressed to the all-systems multicast
   group (224.0.0.1), has a Group Address field of 0, has a Max Response
   Time of [Query Response Interval], and has a IGAP Type field of 0x21
   (Basic Query). Other fields are not used. [Query Response Interval]
   is same as RFC 2236 [IGMPv2].

   When an IGAP router receives an IGAP Membership Report or an IGAP
   Group Leave, it takes different actions based on the configured
   authentication mechanism.


3.3.1 Password Authentication in Routers

   When an IGAP router receives a Password Mechanism Join (an IGAP join
   that has a Subtype field of 0x02), if the router already has the
   corresponding group membership state, it refreshes the associate
   timer.

   If the router does not have the group membership state, it forwards
   the user's group join request information as well as its user
   authentication information including its user account and password to
   the back-end AAA server. Based on the AAA server's results of



Hayashi, Andou, He, Tawbi, Niki                                 [Page 9]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   authentication and authorization processes, the IGAP router grants or
   denies the user's access request. When the IGAP router grants the
   request, it adds the group being reported to the list of multicast
   group memberships on the interface on which it received the Report
   and sets the timer for the membership to the [User Membership
   Interval].

   When an IGAP router receives an IGAP Leave message for a group that
   has group members on the reception interface, it deletes the
   corresponding group membership state.

   If Leave message authentication is required, an IGAP Leave
   (Password-Leave) must have a Subtype field of 0x42, and includes a
   user authentication information which is same to a user
   authentication on Password-Join, and the router forwards the user's
   group leave information as well as the user authentication
   information to the back-end AAA server. If the group leave request is
   authenticated and authorized, the router deletes the corresponding
   group membership state. Otherwise, the leave request is ignored.


3.3.2 Challenge-Response Authentication in Routers

   When an IGAP router receives a Challenge-Response Mechanism Join
   Challenge Request Mechanism Join (a Challenge-Request-Join that has
   a Subtype field of 0x03), the router tries to establish
   Challenge-Response communication for a Join process, then the router
   sends a Challenge-Response Mechanism Challenge (a Challenge that
   has a Type field of 0x41, a Subtype field of 0x23, a Challenge ID
   field of an ID [CHAP], a User Account set to the same user ID in the
   Challenge-Response-Join, and a Message set to a Challenge value
   [CHAP]).

   When the IGAP router receives a Challenge-Response Mechanism Join
   Response (a Challenge-Response-Join that has a Subtype field of
   0x04), if the router already has the corresponding group membership
   state, it refreshes the associate timer.

   If the router does not have the group membership state, it forwards
   the user's group join request information as well as its user
   authentication information including its user account and password to
   the back-end AAA server. Based on the AAA server's results of
   authentication and authorization processes, the IGAP router grants or
   denies the user's access request. When the IGAP router grants the
   request, it adds the group being reported to the list of multicast
   group memberships on the interface on which it received the Report
   and sets the timer for the membership to the [User Membership
   Interval].

   When an IGAP router receives an IGAP Leave message for a group that
   has group members on the reception interface, it deletes the



Hayashi, Andou, He, Tawbi, Niki                                [Page 10]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   corresponding group membership state.

   If Leave message authentication is required, a host oriented
   Challenge-Response communication is establish between a host and the
   IGAP router. When an IGAP router receives an Challenge-Response
   Mechanism Leave (Challenge-Request-Leave that has a Subtype field of
   0x43), the router sends a Challenge-Response Mechanism Challenge (a
   Challenge that has a Type field of 0x41, a Subtype field of 0x23, a
   Challenge ID field of an ID [CHAP], a User Account set to the same
   user ID in the Challenge-Request-Leave, and a Message set to a
   Challenge value [CHAP]).

   When the IGAP router receives a Challenge-Response Mechanism Leave
   Response (a Challenge-Response-Leave that has a Subtype field of
   0x44, the User Account field and Account Size field are the same. The
   Message field is set to the results of MD5 calculation. The Message
   Size field is set to 0x10), and the router forwards the user's group
   leave information as well as the user authentication information to
   the back-end AAA server. If the group leave request is authenticated
   and authorized, the router deletes the corresponding group membership
   state. Otherwise, the leave request is ignored.

   An IGAP implementation must support Basic Leave. Challenge-Response
   Authentication Mechanism Leave is optional.


3.4 Status Notifications

   In controlled or managed multicast environments, it is very important
   to notify a user of its service statuses. IGAP supports the following
   status notifications.


3.4.1 Authentication Result Notification

   When an IGAP router receives the authentication result from the
   back-end AAA server, it notifies the user of the result by unicasting
   an Authentication message to the host.

   The Authentication message has a Type field of 0x41 (IGAP Query) and
   a Subtype field of 0x24. The Group Address field contains the
   corresponding group address for authentication. The Max Resp Time
   field is not used and is ignored by IGAP hosts. It can be set to any
   value or set to the default value 0x64. The User Account contains the
   user account (user ID) for authentication and the Account Size field
   is set the length of the user account.

   The Message Size field is set to 0x01. The Message field has the
   following values:

    0x11: Authentication success.



Hayashi, Andou, He, Tawbi, Niki                                [Page 11]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


    0x21: Authentication failure.

   An IGAP implementation must support the above mandatory values. It
   supports the any other vendor specific values. Appropriate value is
   chosen to reflect the result from the AAA server as well as other
   vendor specific processes. The process adopted by the IGAP hosts upon

   receiving this packet type is up to implementation. However, it must
   not affect other IGAP process.


3.4.2 Accounting Status Notification

   An IGAP router informs the accounting server to start accounting when
   it starts forwarding related multicast traffic into the host's
   network. When the IGAP host leaves the multicast group (either via
   silent departure or an explicit leave), the router informs the
   accounting server to stop accounting. Once it receives the response
   from the accounting server, it notifies the IGAP host by unicasting
   an Accounting message.

   The Accounting message has a Type field of 0x41 (IGAP Query) and a
   Subtype field of 0x25. The Group Address field, the Max Resp Time
   field, the User Account field, and the Account Size field are the
   same as those in the Authentication message described in section
   3.4.1.

   The Message Size field is set to 0x01. The Message field has the
   following values:

    0x11: Accounting start
    0x12: Accounting stop

   An IGAP implementation must support the above mandatory values. It
   supports the any other vendor specific values. The process adopted by
   the IGAP host upon receiving this packet type is up to
   implementation. However, it must not affect other IGAP process.


3.5 Validity Period

   For each group membership state, an IGAP router may maintain another
   timer: Validity Period timer. This timer indicates the valid period
   of an accounting to a group membership. When the timer is expired, an
   IGAP router needs to re-authenticate the group membership. The value
   of the "Validity Period" can be statically configured or dynamically
   set based on the results from the AAA server.

   When "Validity Period" is enforced, an IGAP router checks this timer
   when it receives an IGAP Join. If the timer does not expire, the IGAP
   router does not ask the AAA server a user authentication by a IGAP



Hayashi, Andou, He, Tawbi, Niki                                [Page 12]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   Join response. If the timer expires, it follows the procedures for
   initial authentication described above to re-authenticate the join
   request. During the re-authentication period, an IGAP router
   continues forwarding the multicast traffic and does not stop
   accounting. If the re-authentication succeeds, an IGAP router resets
   the group timer and the Validity Period timer. If the
   re-authentication fails, an IGAP router stops accounting and deletes
   the group membership state.


4. Security Considerations

   IGAP is based around an asymmetrical trust model in which the IGAP
   router does not trust the IGAP host, but the IGAP host trusts the
   IGAP router therefore may not be suitable for use in isolation where
   mutual authentication is required.

   IGAP supports password and challenge-response authentication
   mechanisms and inherits the security concerns of each. For multicast
   content encryption related technology, please refer to other IETF
   work. IGAP does not obstruct snooping of multicast traffic by
   unauthorized host that have access to media shared with multicast
   traffic.

   Some of the security issues discussed in IGMPv2 document also apply
   here. Please refer to IGMPv2 document [IGMPv2] for details.


5. IANA Considerations

   This document introduces the following new Types of IGMP that require
   allocation by IANA:

       0x40: IGAP Membership Report (IGAP Join)
       0x41: IGAP Membership Query  (IGAP Query)
       0x42: IGAP Leave Group       (IGAP Leave)


Acknowledgments

   Portions of this document are copied from RFC 2236 [IGMPv2]. The
   authors would like to thank Daphne Tong, Dave Allen, Abbie Barbir,
   Ghassem Koleyni ,Paul Knight, Kaori Izutsu, Akihiro Tanabe, Takashi
   Shimizu, and Atsushi Takahara for their kindness, patience, and time
   to review the document and to provide their valuable suggestions.


Appendix 1. Example of IGAP Finite State Machines on Password
            authentication

   This section provides an example of IGAP Finite State Machines (FSMs)



Hayashi, Andou, He, Tawbi, Niki                                [Page 13]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   when Password authentication mechanism is used. In this example, the
   value of Validity-Period is set to infinity, and the Basic-Leave is
   used. We also assume that an AAA server is used and the
   Authentication and Accounting packets are operated between IGAP
   routers and AAA servers.

   The example is for illustration purposes only. Implementations of the
   IGAP protocol  are suggested but not required to follow the example.
   However they should comply with the specifications presented earlier
   in this document.


A.1.1. FSM for Client

   PC1[Non Member]:
     if join group{
         send Password-Join;
         start Host-Authentication-Timer;
         transition PC2;
     }

   PC2[Waiting Authentication Message Member]:
     if Authentication-Message(Reject) received
       or Host-Authentication-Timer expired{
         stop Host-Authentication-Timer;
         transition PC1;
     }
     else if Authentication-Message(Success) received{
         stop Host-Authentication-Timer;
         transition PC3;
     }

   PC3[Idle Member]:
     if Basic-Query received{
         start Delaying-Timer;
         transition PC4;
     }
     else if leave group{
         send Basic-Leave;
         transition PC5;
     }

   PC4[Delaying Member]:
     if leave group{
         send Basic-Leave;
         stop Delaying-Timer;
         start Host-Accounting-Timer;
         set Leave-Retransmission-Counter;
         transition PC5;
     }
     else(Delaying-Timer expired){



Hayashi, Andou, He, Tawbi, Niki                                [Page 14]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


         send Password-Join;
         stop Delaying-Timer;
         transition PC2;
     }

   PC5[Waiting Accounting Message Member]:
     if Accounting-Message(Stop) received{
         stop Host-Accounting-Timer;
         transition PC1;
     }
     else if Basic-Query received{
         if (Leave-Retransmission-Counter > 0) {
             Leave-Retransmission-Counter--;
             send Basic-Leave;
             continue(no transition);
         }
     }
     else(Host-Accounting-Timer expired){
         if (Leave-Retransmission-Counter > 0) {
             Leave-Retransmission-Counter--;
             send Basic-Leave;
             restart Host-Accounting-Timer;
             continue(no transition);
         }
         else{
             stop Host-Accounting-Timer;
             transition PC1;
         }
     }


A1.2. FSM for IGAP router

   PR1[No Transfer Present]:
     if Password-Join received{
         send Authentication Request to AAA server;
         start Router-Authentication-Timer;
         transition PR2;
     }
     else if Basic-Leave received{
         if (Accounting-Retransmission-Counter >0){
            Accounting-Retransmission-Counter--;
            send Accounting-Request(Stop) to AAA server;
            transition PR5;
         }
     }

   PR2[Waiting Authentication-Response]:
     if Access-Reject received{
         send Authentication-Message(Reject);
         stop Router-Authentication-Timer;



Hayashi, Andou, He, Tawbi, Niki                                [Page 15]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


         transition PR1;
     }
     else if Access-Accept received{
         if (Immediate-Accounting == true){
             send Accounting-Request(Start) to AAA server;
             send Authentication-Message(Success);
             stop Router-Authentication-Timer;
             start Router-Accounting-Timer;
             transition PR3;
         }
         else{
             start User-Membership-Interval-Timer;
             send Authentication-Message(Success);
             stop Router-Authentication-Timer;
             transition PR6;
         }
     }
     else(Router-Authentication-Timer expired){
        if (Free-Ride == true) {
            stop Router-Authentication-Timer;
            start User-Membership-Interval-Timer;
            transition PR4;
        }
        else{
            stop Router-Authentication-Timer;
            transition to PR1;
        }
     }

   PR3[Waiting Accounting-Response(Start)]:
     if Accounting-Response received from AAA server{
         send Accounting-Message(Start);
         stop Router-Accounting-Timer;
         start User-Membership-Interval-Timer;
         transition PR4;
     }
     else(Router-Accounting-Timer expired){
         stop Router-Accounting-Timer;
         if (Accounting-Anyway == true){
            start User-Membership-Interval-Timer;
         }
         transition PR4;
     }

   PR4[Transfer Present]:
     if Password-Join received{
         restart User-Membership-Interval-Timer;
         continue(no transition);
     }
     else if Basic-Leave received{
         send Accounting-Request(Stop) to AAA server;



Hayashi, Andou, He, Tawbi, Niki                                [Page 16]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


         set Accounting-Retransmission-Counter;
         stop User-Membership-Interval-Timer;
         start Router-Accounting-Timer;
         transition PR5;
     }
     else(User-Membership-Interval-Timer expired){
         send Accounting-Request(Stop);
         start Router-Accounting-Timer;
         transition PR5;
     }

   PR5[Waiting Accounting-Response(Stop) for Leave]:
     if Accounting-Response received from AAA server{
         send Accounting-Message(stop);
         stop Router-Accounting-Timer;
         transition PR1;
     }
     else(Router-Accounting-Timer expired){
         if (Accounting-Retransmission-Counter > 0){
             Accounting-Retransmission-Counter--;
             send Accounting-Request(Stop) to AAA server;
             start Router-Accounting-Timer;
             continue(no transition);
         }
         else{
             stop Router-Accounting-Timer;
             transition PR1;
         }
     }

   PR6[Waiting Data transmission]:
     if (Data for joined group received) {
         send Accounting-Request(start) to AAA server;
         start Router-Accounting-Timer;
         transition PR3;
     }
     else if Basic-Leave received{
         send Accounting-Request(Stop) to AAA server;
         set Accounting-Retransmission-Counter;
         stop User-Membership-Interval-Timer;
         start Router-Accounting-Timer;
         transition PR5;
     }


Appendix 2. Example of IGAP Finite State Machines on Challenge-Response

   This section provides an example of IGAP Finite State Machines (FSMs)
   when Challenge-Response authentication mechanism is used. In this
   example, the value of Validity-Period is set to a finite value, and
   the Basic-Leave is used. We also assume that an AAA server is used



Hayashi, Andou, He, Tawbi, Niki                                [Page 17]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   and the Authentication and Accounting packets are operated between
   IGAP routers and AAA servers.

   The example is for illustration purposes only. Implementations of the
   IGAP protocol are suggested but not required to follow the example.
   However they should comply with the specifications presented
   earlier in this document.


A2.1. FSM for Client

   CC1[Non Member]:
     if join group{
         send Challenge-Request-Join;
         start Challenge-Timer;
         transition CC2;
     }

   CC2[Waiting Challenge Member]:
     if Challenge received{
         send Challenge-Response-Join;
         stop Challenge-Timer;
         start Host-Authentication-Timer;
         transition CC3;
     }
     else(Challenge-Timer expired){
         stop Challenge-Timer;
         transition CC1;
     }

   CC3[Waiting Authentication Message Member]:
     if Authentication-Message(Reject) received
       or Host-Authentication-Timer expired{
         stop Host-Authentication-Timer;
         transition CC1;
     }
     else if Authentication-Message(Success) received{
         stop Host-Authentication-Timer;
         transition CC4;
     }

   CC4[Idle Member]:
     if Basic-Query received{
         start Delaying-Timer;
         transition CC5;
     }
     else if leave group{
         send Basic-Leave;
         start Host-Accounting-Timer;
         transition CC6;
     }



Hayashi, Andou, He, Tawbi, Niki                                [Page 18]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   CC5[Delaying Member]:
     if leave group{
         send Basic-Leave;
         stop Delaying-Timer;
         start Host-Accounting-Timer;
         set Leave-Retransmission-Counter;
         transition CC6;
     }
     else(Delaying-Timer expired){
         send Challenge-Request-Join;
         stop Delaying-Timer;
         start Challenge-Timer;
         transition CC2;
     }

   CC6[Waiting Accounting Message Member]:
     if Accounting-Message(Stop) received{
         stop Host-Accounting-Timer;
         transition CC1;
     }
     else if Basic-Query received{
         if (Leave-Retransmission-Counter > 0){
              Leave-Retransmission-Counter--;
              send Basic-Leave;
              continue(no transition);
         }
     }
     else(Host-Accounting-Timer expired){
        if (Leave-Retransmission-Counter > 0){
            Leave-Retransmission-Counter--;
            send Basic-Leave;
            restart Host-Accounting-Timer;
            continue(no transition);
        }
        else{
            stop Host-Accounting-Timer;
            transition CC1;
        }
     }


A2.2. FSM for IGAP router

   CR1[No Transfer Present]:
     if Challenge-Request-Join received{
         send Challenge;
         start Response-Timer;
         transition CR2;
     }
     else if Basic-Leave received{
         if (Accounting-Retransmission-Counter > 0){



Hayashi, Andou, He, Tawbi, Niki                                [Page 19]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


             Accounting-Retransmission-Counter--;
             send Accounting-Request(Stop) to AAA server;
             transition CR7;
         }
     }

   CR2[Waiting Challenge-Response]:
     if Challenge-Response-Join received{
         send Authentication Request;
         stop Response-Timer;
         start Router-Authentication-Timer;
         transition CR3;
     }
     else(Response-Timer expired){
         stop Response-Timer;
         transition CR1;
     }

   CR3[Waiting Authentication-Response]:
     if Access-Reject received from AAA server{
         send Authentication-Message(Reject);
         stop Router-Authentication-Timer;
         transition CR1;
     }
     else if Access-Accept received{
         if (Immediate-Accounting == true){
             send Accounting-Request(Start) to AAA server;
             send Authentication-Message(Success);
             stop Router-Authentication-Timer;
             start Router-Accounting-Timer;
             transition CR4;
         }
         else{
             start User-Membership-Interval-Timer;
             send Authentication-Message(Success);
             stop Router-Authentication-Timer;
             transition CR8;
         }
     }
     else(Router-Authentication-Timer expired){
        if (Free-Ride == true){
            stop Router-Authentication-Timer;
            start User-Membership-Interval-Timer;
            start Validity-Timer;
            transition CR5;
        }
        else{
            stop Router-Authentication-Timer;
            transition to CR1;
        }
     }



Hayashi, Andou, He, Tawbi, Niki                                [Page 20]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   CR4[Waiting Accounting-Response(Start)]:
     if Accounting-Response received from AAA server{
         send Accounting-Message(Start);
         stop Router-Accounting-Timer;
         start User-Membership-Interval-Timer;
         start Validity-Timer;
         transition CR5;
     }
     else(Router-Accounting-Timer expired){
         stop Router-Accounting-Timer;
         if (Accounting-Anyway == true){
             start User-Membership-Interval-Timer;
         }
         start Validity-Timer;
         transition CR5;
     }

   CR5[Transfer Present]:
     if Challenge-Request-Join received{
         if Validity-Timer < Validity-Period{
             restart User-Membership-Interval-Timer;
             continue(no transition);
         }
         else(Validity-Timer expired){
             send Router-Accounting-Request(Stop);
             stop Validity-Timer;
             stop User-Membership-Interval-Timer;
             start Router-Accounting-Timer
             transition CR6;
         }
     }
     else if Basic-Leave received{
         if (Accounting-Retransmission-Counter > 0){
             Accounting-Retransmission-Counter--;
             send Accounting-Request(Stop) to AAA server;
             stop User-Membership-Interval-Timer;
             stop Validity-Timer;
             start Router-Accounting-Timer;
             transition CR7;
         }
         else{
             transition CR1;
         }
     }
     else(User-Membership-Interval-Timer expired){
         send Accounting-Request(Stop) to AAA server;
         stop Validity-Timer;
         start Router-Accounting-Timer;
         transition CR7;
     }




Hayashi, Andou, He, Tawbi, Niki                                [Page 21]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   CR6[Waiting Accounting-Response(Stop)]:
     if Accounting-Response received from AAA server{
         send Accounting-Message(Stop);
         send Challenge;
         stop Router-Accounting-Timer;
         start Response-Timer;
         transition CR2;
     }
     else(Router-Accounting-Timer expired){
         stop Router-Accounting-Timer;
         start Validity-Timer;
         transition CR5;
     }

   CR7[Waiting Accounting-Response(Stop) for Leave]:
     if Accounting-Response received{
         send Accounting-Message(stop);
         stop Router-Accounting-Timer;
         transition CR1;
     }
     else(Router-Accounting-Timer expired){
         if (Accounting-Retransmission-Counter > 0){
             Accounting-Retransmission-Counter--;
             send Accounting-Request(Stop);
             start Router-Accounting-Timer;
             continue(no transition);
         }
         else{
             transition CR1;
         }
     }

   CR8[Waiting Data transmission]:
     if Data for joined group received{
         send Accounting-Request(start);
         start Router-Accounting-Timer;
         transition CR4;
     }
     else if Basic-Leave received{
         if (Accounting-Retransmission-Counter > 0){
             Accounting-Retransmission-Counter--;
             send Accounting-Request(Stop) to AAA server;
             stop User-Membership-Interval-Timer;
             start Router-Accounting-Timer;
             transition CR7;
         }
         else{
             transition CR1;
         }
     }




Hayashi, Andou, He, Tawbi, Niki                                [Page 22]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


Appendix 3. IGAP State Machines of Query Process

   This Section describes an example of IGAP State Machines on Query
   Process.

   QR1[Initial]:
     start IGAP{
         send Basic-Query;
         start Startup-Query-Interval-Timer;
         start Startup-Query-Counter;
         transition QR2;
     }

   QR2[Startup]
     if Startup-Query-Interval-Timer expired{
         if Startup-Query-Counter < Startup-Query-Count{
             send Basic-Query;
             restart Startup-Query-Interval-Timer;
             continue(no transition)
         }
         else{
             send Basic-Query;
             stop Startup-Query-Counter;
             start Query-Interval-Timer;
         transition QR3;
         }
     }

   QR3[Affirmed Connection]:
     if Query-Interval-Timer expired{
         send Basic-Query;
         restart Query-Interval-Timer;
         continue(no transition);
   }


Appendix 4. List of Timers, Counters

   This section describes the parameters set in IGAP router and Host
   when supporting IGAP processes.


A4.1. Robustness Variable

   It is the same meaning as IGMPv2.


A4.2. Timers for Host

A4.2.1. Challenge-Timer




Hayashi, Andou, He, Tawbi, Niki                                [Page 23]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   It controls waiting time from sending Join message to receiving
   Challenge Message.

A4.2.2. Host-Authentication-Timer

   It controls waiting time from sending Response Message to receiving
   Authentication Message (accept or reject) from IGAP router.

A4.2.3. Host-Accounting-Timer

   It controls waiting time from sending Response Message to receiving
   Accounting Message (start or stop) from IGAP router.

A4.2.4. Delaying-Timer

   It controls waiting time from receiving Query to sending Join Message
   to IGAP router. It is calculated from Max Resp Time.

A4.2.5 Leave-Retransmission-Counter

   The Leave-Retransmission-Counter is the number of Leave messages a
   host retransmits after sending the first Leave message. The default
   value is 0.


A4.3. Timers and Counters for IGAP router

A4.3.1. Response-Timer

   It controls waiting time from sending Challenge Message to receiving
   Response Message.

A4.3.2. Router-Authentication-Timer

   It controls waiting time from sending Authentication request to
   receiving Authentication Response.

A4.3.3. Router-Accounting-Timer

   It controls waiting time from sending Accounting request to receiving
   Accounting Response.

A4.3.4. Validity-Timer

   This is an integer multiple of Basic-Query Interval in units of
   second, and used by IGAP router to determine whether user
   authentication is necessary or not.

A4.3.5. Query-Interval-Timer

   It is the same meaning as IGMPv2. The Query Interval is the interval



Hayashi, Andou, He, Tawbi, Niki                                [Page 24]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


   between Basic Queries.

A4.3.6. Query-Response-Interval-Timer

   It is the same meaning as IGMPv2. The Max Response Time inserted into
   the periodic Basic Queries.

A4.3.7. User-Membership-Interval-Timer

   The User Membership Interval is the amount of time that must pass
   before a IGAP router decides there are no more users of a group on
   on a network. This value MUST be ((the Robustness Variable) times
   (the Query Interval)) plus (one Query Response Interval).

A4.3.8.  Startup-Query-Interval-Timer

   It is the same meaning as IGMPv2.
   The Startup Query Interval is the interval between General Queries
   sent by a Querier on startup.

A4.3.9.  Startup-Query-Counter

   It is the same meaning as IGMPv2.
   The Startup Query Count is the number of Queries sent out on startup,
   separated by the Startup Query Interval.

A4.3.10 Accounting-Retransmission-Counter

   The Accounting-Retransmission-Counter is the number of Accounting
   messages a router retransmits after sending the first accounting
   message to a host. The default value is 0.

A4.3.11 Immediate-Accounting

   The Immediate-Accounting indicates whether a router will start the
   accounting immediately after a JOIN request is authenticated and
   authorized or start the accounting when the subscribed multicast data
   starts being forwarded. The values are TRUE and FALSE. The default
   value is FALSE.

A4.3.12 Free-Ride
   When the value is true, when Router-Authentication-Timer is expired,
   the group is free to access. This variety depends on provider's
   service.

A4.3.13 Accounting-Anyway
   When the value is true, accounting is carried out despite the
   expiration of Router-Accounting-Timer.


Normative References



Hayashi, Andou, He, Tawbi, Niki                                [Page 25]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


[IGMPv2]
   W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236,
   Xerox PARC, November 1997.

[IPRA]
   D. Katz, "IP Router Alert Option", RFC 2113, Cisco Systems,
   February 1997.

[MD5]
   R. Rivest, S. Dusse, "The MD5 Message-Digest Algorithm", RFC 1321,
   April 1992.

[RADIUS]
   C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication
   Dial In User Service (RADIUS)", RFC 2865, June 2000.

[PAP]
   B. Lloyd and W. Simpson, "PPP Authentication Protocols", RFC1334,
   October 1992.

[CHAP]
   W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)",
   RFC 1994, August 1996.


Author's Addresses

        Tsunemasa Hayashi
        NTT Network Innovation Laboratories
        1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
        Phone : +81 46 859 8790
        Email : hayashi.tsunemasa@lab.ntt.co.jp

        Daisuke Andou
        NTT Access Network Service Systems Laboratories
        1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan
        Phone : +81 43 211 2115
        Email : dandou@ansl.ntt.co.jp

        Haixiang He
        Nortel Networks
        600 Technology Park Drive
        Billerica, MA 01801, USA
        Phone : +1 978 288 7482
        Email : haixiang@nortelnetworks.com

        Wassim Tawbi
        Nortel Networks
        4655 Great America Parkway
        Santa Clara, CA 95054, USA
        Phone : +1 408 495 2362



Hayashi, Andou, He, Tawbi, Niki                                [Page 26]


Internet Draft            draft-hayashi-igap-02.txt            May, 2003


        Email : wtawbi@nortelnetworks.com

        Teruki Niki
        Matsushita Electric Industrial Co.,Ltd
        Multimedia Systems Research-Laboratory
        4-5-15 Higashi-Shinagawa Shinagawa-ku, Tokyo, 140-8632 Japan
        Phone : +81 3 5460 2741
        Email : niki.teruki@jp.panasonic.com














































Hayashi, Andou, He, Tawbi, Niki                                [Page 27]