Internet DRAFT - draft-he-magma-igmpv3-auth

draft-he-magma-igmpv3-auth









Internet Engineering Task Force             Haixiang He, Nortel Networks
INTERNET-DRAFT                                Brad Cain, Cereva Networks
                                               Thomas Hardjono, Verisign
Expire: May, 2002                                         November, 2001



             Upload Authentication Information Using IGMPv3
                  <draft-he-magma-igmpv3-auth-00.txt>



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 document describes the changes of Internet Group Management
   Protocol(IGMP) version 3 that enable a host to upload the
   authentication information to its neighboring multicast routers.


1. Introduction

   The Internet Group Management Protocol (IGMP) [1, 2, 3] is used in
   IPv4 environment to communicate IP multicast group membership
   subscriptions from a host to its neighboring multicast routers.

   The current multicast model allows any host to join the multicast
   group by issuing IGMP join message. In some scenarios such as



He, Cain, Hardjono                                              [Page 1]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


   security attack protection, a host's IGMP requests needs to be
   authenticated before a router triggers the multicast routing
   protocol.  In some other scenarios such as group access control, a
   host needs to be authorized before it can receive the multicast
   traffic.  Some solutions to these problems require a host to provide
   authentication information such as access token [4, 5] accompanying
   its IGMP requests. They also require the host's neighboring routers
   to periodically query for authentication information and authenticate
   those IGMP requests before taking related actions about IGMP
   requests.

   This document defines the necessary changes of IGMPv3 to support the
   use of IGMP to communicate the authentication information, in
   particular access token.


2. Solution Goal, Approach, and Rationale

   The IGMP state records maintained by a multicast router are used to
   trigger the multicast routing protocol that will cause the multicast
   traffic being delivered to that router. They are also used to forward
   the traffic downstream. The goal of a solution that protects the
   multicast router is to protect the IGMP state records.

   To achieve this goal, the IGMP requests should be authenticated. One
   approach is to require authentication information such as access
   token accompanying an IGMP request. Once a router receives the
   request, it will use the authentication information to authenticate
   the request. And according to the authentication results, it will
   take appropriate actions to update the IGMP state records.

   One simple and easy solution is to authenticate every IGMP request.
   In another word, this solution requires authentication information
   accompanying every IGMP request. This solution has some
   disadvantages. Authentication information is not needed if an IGMP
   request does not cause any change of the IGMP state records. So the
   extra authentication information is a waste of the bandwidth usage of
   network and it is also an extra burden of the host's processing
   power.

   One the router side, there is also some cost of providing
   authentication.  The cost maybe very high. So authentication should
   be minimized. In some circumstances, it may be tolerable to update
   the timers associated with the IGMP state records that have already
   been created without authenticating those IGMP requests for a certain
   period of time.  A solution should provide a router with an option of
   when to use the authentication.




He, Cain, Hardjono                                              [Page 2]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


   Based on the rationale above, this document proposes two new IGMPv3
   authentication messages, Authentication Query and Authentication
   Report.  These two new message coexist with the current IGMPv3
   messages. A host uses the normal IGMPv3 report message to report its
   interest. When it receives an authentication query, it will reply an
   authentication report. Besides the normal IGMPv3 query, a router also
   sends authentication query in some conditions described in section 5.


3. Authentication Message Formats

   The new Authentication Messages follow the requirements for normal
   IGMP message specified in IGMPv3 document [3]. There are two
   Authentication Messages:

           Type Number (hex)   Message Name
           -----------------   ------------
               0x31            Authentication Membership Query
               0x32            Authentication Membership Report


3.1. Authentication Membership Query

   The Authentication Membership Queries are sent by multicast router.
   The format is the same as IGMPv3 query except that the message type
   field is 0x31 instead of 0x11.

   There are also three variants of the Authentication Query message:
   General Authentication Query, Group-Specific Authentication Query,
   Group-and-Source-Specific Authentication Query. In a General
   Authentication Query, both the Group Address field and the Number of
   Sources (N) field are zero. In a Group-Specific Authentication Query,
   the Group Address field contains the multicast address of interest,
   and the Number of Sources (N) field contains zero. In a Group-and-
   Source-Specific Authentication Query, the Group Address field
   contains the multicast address of interest, and the Source Address
   [i] fields contain the source address(es) of interest.


3.2. Authentication Membership Report

   The Authentication Membership Reports are sent by IP systems. Besides
   the message type field which is 0x32 and the changes in Group Record,
   the format is the same as IGMPv3 report message.

   The new Group Record has the following internal format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



He, Cain, Hardjono                                              [Page 3]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


      |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Multicast Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Address [1]                      |
      +-                                                             -+
      |                       Source Address [2]                      |
      +-                                                             -+
      .                               .                               .
      .                               .                               .
      .                               .                               .
      +-                                                             -+
      |                       Source Address [N]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                 Auxiliary Data Record [1]                     .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                 Auxiliary Data Record [2]                     .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      .                               .                               .
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                 Auxiliary Data Record [Q]                     .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each Auxiliary Data Record has the following internal format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Aux Type   |  Aux Rec Len  |   Auth Type   | Auth Data Len |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                      Authentication Data                      .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





He, Cain, Hardjono                                              [Page 4]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


3.2.1. Aux Type

   The Aux Type field unambiguously specifies the type of the Auxiliary
   Data. This document only specifies one type of Auxiliary Data:
   Authentication Information, Aux Type = 0x01.


3.2.2. Aux Rec Len

   The Aux Rec Len field contains the length of the Auxiliary Data
   Record, in the units of 32-bits words. The length of the Auxiliary
   Data Record is not fixed. Besides the Aux Type and Aux Rec Len
   fields, the rest of the record is interpreted according to the value
   of the Aux Type field, Authentication Information in this document.


3.2.3. Auth Type

   The Auth Type field indicates the authentication mechanism being
   used.


3.2.4 Auth Data Len

   The Auth Data Len field contains the length of the useful
   Authentication Data.


3.2.5. Authentication Data

   The Authentication Data field contains the authentication information
   as well as extra padding that makes the whole Auxiliary record into
   the units of 32-bits words.


3.2.6. Record Type

   There are only two types of Group Records that may be included in an
   Authentication Report message. They are all "Current-State Record" as
   specified in IGMPv3 document. An Authentication Report is only sent
   by a system in response to an Authentication Query.


4. Host Behavior

   A host takes the same actions as described in IGMPv3 document in
   response to the event: a change of the interface reception state,
   caused by a local invocation of IPMulticastListen.



He, Cain, Hardjono                                              [Page 5]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


   A host will receive only General Query, General Authentication Query,
   Group Specific Authentication Query, Group-and-Source Specific
   Authentication Query. If all multicast routers in the same networks
   support this document, a host should not receive Group Specific
   Query, Group-and-Source Specific Query as described in section 5.

   To schedule a response to an Authentication Query, the system must
   maintain one more state in addition to the three states it has
   already maintained as described in IGMPv3 document. The new state is:

     A timer per interface for scheduling responses to General
     Authentication Queries. This timer is identified as Authentication
     Interface Timer to differentiate itself from interface timer used
     for scheduling response to General Queries.

   The group timer and the source-list are now used to schedule
   responses to Group Specific Authentication Queries and Group-and-
   Source Specific Queries. The interface timer is still used to
   schedule responses to General Queries.

   The rules used to determine if a Report needs to be scheduled and the
   type of Report to schedule are the same as in IGMPv3 document except
   a few changes. First, new rules are added to process General
   Authentication Queries. These rules are the same as rules used to
   process General Queries. Second, rules used process Group Specific
   and Group-and-Source Specific Queries are instead used to process
   Group Specific and Group-and-Source Specific Authentication Queries.

   When the interface timer expires, a normal Report message is sent.
   When the Authentication Interface Timer expires, an Authentication
   Report message is sent. Except the authentication information, this
   message contains the same information as the normal Report message
   used to response the General Queries. When the group timer expires,
   an Authentication Report message is sent. Except the authentication
   information, the message contains the same information as the normal
   Report message used to response the Group Specific and Group-and-
   Source Specific Queries.


5. Router Behavior

   Multicast routers maintain the same IGMP group membership state as
   specified in IGMPv3. They also follow the IGMPv3 Source-Specific
   forwarding rules. To protect the IGMP state records, routers maintain
   extra authentication state and there are few changes about the router
   behavior.





He, Cain, Hardjono                                              [Page 6]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


5.1. IGMP Authentication State Maintained by Multicast Routers

   Multicast routers maintain a set of authentication state records per
   attached networks. Each authentication state record conceptually is
   of the form:

           (multicast address, authentication timer)

   for group specific authentication state record or of the form:

           (multicast address, source address, authentication timer)

   for group-and-source specific authentication state record.

   Records are created when multicast routers send Authentication Query.
   And their authentication timers are set to the Last Member
   Authentication Query Interval (LMAQI). A record is deleted when the
   authentication timer time out or when an authentication current-state
   record is received that contains the record's multicast address (and
   source address in scenarios) before timer time out.


5.2. IGMP Queries

   Multicast routers use 4 types of queries: General Query, General
   Authentication Query, Group Specific Authentication Query, and
   Group-and-Source Specific Authentication Query. They SHOULD not send
   Group Specific Query and Group-and-Source Specific Query.

   Multicast routers still send General Queries periodically to request
   group membership information. These queries are used to refresh the
   group membership state of the systems on attached networks.

   Multicast routers also send General Authentication Queries
   periodically to request group membership information as well as its
   associated authentication information. These queries are also used to
   refresh the group membership state. The interval between two General
   Authentication Queries SHOULD be larger than the interval between two
   General Queries.  When sending a General Authentication Query,
   routers also create a group specific authentication state record with
   only multicast address for each IGMP state record. And the record's
   non zero timers including group and source timers are set to LMAQI.

   Multicast routers send Group Specific Authentication Queries when a
   group record needs to be created, when a group's filter-mode needs to
   be changed from INCLUDE to EXCLUDE, or when a system is leaving the
   group. A group specific authentication state record is created using
   the group record's multicast address.



He, Cain, Hardjono                                              [Page 7]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


   Multicast routers send Group-and-Source Specific Authentication
   Queries when traffic from a new source record is needed or a system
   expresses interest in not receiving traffic from particular sources.
   A group-and-source specific authentication state record is created
   using the group record's multicast and source addresses.


5.3. Action on Reception of Reports

   If all hosts in a network support this documents, multicast routers
   SHOULD receive Membership Reports with Current-State records and
   State-Change records as well as Authentication Membership Reports
   with only Current-State records.


5.3.1. Reception of Current-State Records

   When receiving Current-State records, a router updates the related
   timers. If a new group state record needs to be created or the group
   record's filter mode needs to be changed from INCLUDE to EXCLUDE, a
   router sends a Group Specific Authentication Query. If traffic from a
   new source is needed, a router sends a Group-and-Source Specific
   Authentication Query.

   The table below describes the modified actions upon reception of
   Current-State Records. The notation 'AQ(G)" is used to describe a
   Group Specific Authentication Query to G. The notation 'AQ(G,A)' is
   used to describe a Group-and-Source Specific Query to G with source-
   list A. Every time a router send an AQ(G) or AQ(G,A), it creates
   related authentication state records.

     Router State   Report Rec'd  New Router State     Actions
     ------------   ------------  ----------------     -------

     INCLUDE (A)    IS_IN (B)     INCLUDE (A)          (A*B)=GMI
                                                       Send AQ(G,B-A)

     INCLUDE (A)    IS_EX (B)     INCLUDE (A)          Send AQ(G)

     EXCLUDE (X,Y)  IS_IN (A)     EXCLUDE (X+(A-Y),Y)  (A-Y)=GMI
                                                       Send AQ(G,A*Y)

     EXCLUDE (X,Y)  IS_EX (A)     EXCLUDE (A-Y,Y)      Send AQ(G,Y-A)
                                                       (A-X-Y)=GMI
                                                       Delete (X-A)
                                                       Group Timer=GMI





He, Cain, Hardjono                                              [Page 8]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


5.3.2. Reception of State-Change Records

   When receiving State-Change records, a router updates its records and
   may change its state to reflect the new desired membership state of
   the network. If some sources are requested to be no longer forwarded
   to a group, a router sends a Group-and-Source Specific Authentication
   Query to query sources. It lowers the source timers for those sources
   to Last Member Query Interval (LMQI). Similarly, when a router sends
   Group Specific Authentication Query, it lowers the group timer for
   that group to LMQI.

   Also if a new group state record needs to be created or the group
   record's filter mode needs to be changed from INCLUDE to EXCLUDE, a
   router sends a Group Specific Authentication Query. If traffic from a
   new source is needed, a router sends a Group-and-Source Specific
   Authentication Query.

   The table below describes the modified actions upon reception of
   State-Change Records.

     Router State   Report Rec'd New Router State      Actions
     ------------   ------------ ----------------      -------

     INCLUDE (A)    ALLOW (B)    INCLUDE (A)           (B*A)=GMI
                                                       Send AQ(G,B-A)

     INCLUDE (A)    BLOCK (B)    INCLUDE (A)           Send AQ(G,A*B)
                                                       (A*B)=LMQI

     INCLUDE (A)    TO_EX (B)    INCLUDE (A)           Send AQ(G)

     INCLUDE (A)    TO_IN (B)    INCLUDE (A)           (A*B)=GMI
                                                       Send AQ(G,A-B)
                                                       (A-B)=LMQI
                                                       Send AQ(G,B-A)

     EXCLUDE (X,Y)  ALLOW (A)    EXCLUDE (X+(A-Y),Y)   (A-Y)=GMI
                                                       Send AQ(G,A*Y)

     EXCLUDE (X,Y)  BLOCK (A)    EXCLUDE (X+(A-Y),Y)   (A-X-Y)=Group Timer
                                                       Send AQ(G,A-Y)

     EXCLUDE (X,Y)  TO_EX (A)    EXCLUDE (A-Y,Y)       Send AQ(G,Y-A)
                                                       (A-X-Y)=Group Timer
                                                       Delete (X-A)
                                                       Send AQ(G,A-Y)
                                                       Group Timer=GMI




He, Cain, Hardjono                                              [Page 9]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


     EXCLUDE (X,Y)  TO_IN (A)    EXCLUDE (X+(A-Y),Y)   (A-Y)=GMI
                                                       Send AQ(G,A*Y)
                                                       Send AQ(G,X-A)
                                                       (X-A)=LMQI
                                                       Send AQ(G)
                                                       Group Timer=LMQI


5.3.3. Reception of Authentication Current-State Records

   When receiving Authentication Current-State records, a router
   triggers the authentication module through the authentication APIs
   described in section 7. For each record that is authenticated, the
   related IGMP state record is updated.

   When updating the IGMP state records, a router takes the same actions
   as the actions a normal IGMP router takes upon reception of Current-
   State records. The same table is used.

     Router State   Report Rec'd  New Router State      Actions
     ------------   ------------  ----------------      -------

     INCLUDE (A)    IS_IN (B)     INCLUDE (A+B)         (B)=GMI

     INCLUDE (A)    IS_EX (B)     EXCLUDE (A*B,B-A)     (B-A)=0
                                                        Delete (A-B)
                                                        Group Timer=GMI

     EXCLUDE (X,Y)  IS_IN (A)     EXCLUDE (X+A,Y-A)     (A)=GMI

     EXCLUDE (X,Y)  IS_EX (A)     EXCLUDE (A-Y,Y*A)     (A-X-Y)=GMI
                                                        Delete (X-A)
                                                        Delete (Y-A)
                                                        Group Timer=GMI


6. Group-and-Source Specific Authentication Information

   In some scenarios especially in SSM [6,7], Group-and-Source Specific
   authentication information is required. Without changing the format
   and interpretation of the current IGMPv3 report, a group record with
   a single source address has to be used to upload Group-and-Source
   Specific authentication information.

   But this method does not apply to a group if the group's filter mode
   is EXCLUDE since a record whose record type is MODE_IS_EXCLUDE cannot
   be split into multiple records.




He, Cain, Hardjono                                             [Page 10]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


7. The API for Authenticating IGMP Requests

   Within a router, there is an Application Programming Interface or API
   that is used by the IGMP module to authenticate the IGMP requests.
   The API must support the following operation or any logical
   equivalent:

       bool IGMPAllowed(multicast-address, source-list, auth record)

   where the "auth record" contains the authentication information that
   is in the IGMP request.


8. New Timer

   This document introduces one new timer. It is configurable.


8.1. Authentication Query Interval

   The Authentication Query Interval is the interval between General
   Authentication Queries. Default: 300 seconds.

   The Authentication Query Interval should be larger than Query
   Interval since authentication is more expensive and should be used
   less.


References

[1] Deering, S., "Host Extension for IP Multicasting", RFC 1112,
    August 1989.
[2] Fenner, W., "Internet Group Management Protocol, Version2",
    RFC 2236, November 1997.
[3] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A.,
    "Internet Group Management Protocol, Version 3", Internet-Draft,
    January 2001.
[4] He, H., Hardjono, T., and Cain, B., "Simple Multicast Receiver
    Access Control", Internet-Draft, work in progress.
[5] Hardjono, T. and Cain, B., "Key Establishment for IGMP
    Authentication in IP Multicast", IEEE European Conference on
    Universal Multiservice Networks (ECUMN), CERF, Colmar, France,
    September 2000.
[6] Holbrook, H., and Cain, B., "Using IGMPv3 For Source-Specific
    Multicast", draft-holbrook-idmr-igmpv3-ssm-01.txt, March 2001.
[7] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP",
    Internet-Draft, work in Progress.




He, Cain, Hardjono                                             [Page 11]





Internet Draft     draft-he-magma-igmpv3-auth-00.txt           May, 2002


Author's  Address:

     Haixiang He
     Nortel Networks
     600 Technology Park Drive
     Billerica, MA 01821
     Phone: 978-288-7482
     Email: haixiang@nortelnetworks.com

     Brad Cain
     Cereva Networks
     Email: bcain@cereva.com

     Thomas Hardjono
     Verisign
     401 Edgewater Place, Suite 208
     Wakefield, MA 01880
     Email: thardjono@verisign.com

































He, Cain, Hardjono                                             [Page 12]