Internet Engineering Task Force Tsunemasa Hayashi, NTT
Internet Draft Daisuke Andou, NTT
October, 2002 Haixiang He, Nortel Networks
Expires: April, 2003 Wassim Tawbi, Nortel Networks
Teruki Niki, Matsushita Electric Industrial
IGMP for user Authentication Protocol (IGAP)
<draft-hayashi-igap-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
IP Multicast applications are becoming more common. Two key concerns
raised by the providers of such applications are the lack of control
on what users can get multicast traffic and a method for tracking
user usage (such as how long these users are joined to a multicast
group).
This document introduces the IGMP for user Authentication Protocol
(IGAP). IGAP extends the existing IGMPv2 protocol to add user
authentication functionality. IGAP enables an IP multicast service
provider to authenticate requests to join a specific multicast group
based on user information.
Table of Contents
1. Introduction
2. Motivations
3. Applicability Statement
4. IGAP Protocol Overview
5. IGAP Message Formats
5.1. Type
Hayashi, Andou, He, Tawbi, Niki [Page 1]
Internet Draft draft-hayashi-igap-00.txt October, 2002
5.2. Max Response Time
5.3. Checksum
5.4. Group Address
5.5. Version
5.6. Report Type
5.7. # of Aux (N)
5.8. Reserved
5.9. Auxiliary Data Records
5.9.1. User Account (Aux Type 0x01)
5.9.2. Password (Aux Type 0x11)
5.9.3. Challenge Value (Aux Type 0x12)
5.9.4. Response Value (Aux Type 0x13)
5.9.5. Authentication Result (Aux Type 0x21)
5.9.6. Accounting Action Result (Aux Type 0x22)
5.9.7. Notification (Aux Type 0x23)
5.9.8. Error (Aux Type 0x24)
6. IGAP Packet Type
6.1. Basic Join
6.2. Password mechanism Join
6.3. Challenge-response mechanism Join Challenge Request
6.4. Challenge-response mechanism Join Response
6.5. Basic Query
6.5.1. General-and-Basic Query
6.5.2. Group-Specific-and-Basic Query
6.6. Challenge-response mechanism Challenge
6.7. Authentication Message
6.8. Accounting Message
6.9. Notification Message
6.10. Error Message
6.11. Basic Leave
6.12. Password mechanism Leave
6.13. Challenge-response mechanism Leave Challenge Request
6.14. Challenge-response mechanism Leave Response
7. IGAP State Machines
8. List of Timers, Counters, and their Default Values
9. Security Considerations
1. Introduction
IP Multicast applications are becoming more common. One issue is the
lack of access control and the ability to effectively collect
per-user usage information. This concern discourages the deployment
of IP multicast services.
The current IP multicast model provides by nature a non-secure
non-controlled way for hosts attached to a network to access
multicast traffic. The wide deployment of non-shared access networks
(such as dial, DSL or switched Ethernet) facilitates providing access
control for multicast traffic.
Hayashi, Andou, He, Tawbi, Niki [Page 2]
Internet Draft draft-hayashi-igap-00.txt October, 2002
This document introduces IGMP for user Authentication Protocol
(IGAP). IGAP extends the existing IGMPv2 [IGMPv2] protocol to add
authentication functionality via permitting known authentication
mechanisms such as password mechanism and challenge-response
mechanism to be incorporated into IGMP protocol sequences. 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. Authenticated and
authorized requests enable a provider to effectively collect the
usage information for a particular multicast group.
2. Motivations
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.
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. This model can make it difficult for a service
provider to generate enough revenue to sustain multicast services
such as IP multicast based Internet TV.
The wide deployment of non-shared access networks (such as dial, DSL
or switched Ethernet) enables a provider to protect its revenue
sources by means of controlling user's access to multicast traffic.
A provider can enforce such access control through static
configuration on the last hop network devices such as Ethernet
switches or routers. However the rules to control the access to
multicast data may change dynamically or the rules may be very
specific such as user-based rules instead of end system based rules
that a network device is not always able to check. This leads to the
need for a comprehensive way to authenticate and authorize end
systems before they are granted access to some multicast groups.
Another issue that prevents the wide deployment of IP multicast
service is the lack of multicast network management functions such
as effective multicast accounting. For example, when deploying IP
multicast based Internet TV, a service provider wants to collect
some accounting information for a specific TV program such as how
many viewers for this TV program and how long they watch this TV
program. This accounting information is very important for content
providers who own the TV programs.
IGAP introduced in this document enables the dynamic multicast
receiver access control for non-shared access networks as well as
effective multicast accounting. Hence it encourages the deployment
of new commercial IP multicast services.
Hayashi, Andou, He, Tawbi, Niki [Page 3]
Internet Draft draft-hayashi-igap-00.txt October, 2002
IGAP uses a user-based authentication model whereby the
authentication procedures added to IGMP simply bind the user to a
specific host for the duration of group membership. The benefits of
a user-based model are well known. The decoupling of service identity
from host addressing offers operational simplicity, in particular
with respect to adds, moves, and changes.
IGAP can also be used in non-commercial environments such as
enterprises. For example, in an enterprise where switched Ethernet is
widely deployed in the last hop, IGAP can be used for closed
videoconference. IGAP provides a mechanism to allow the access to the
videoconference, only if the user is an authenticated user who is all
owed to join the videoconference.
3. Applicability Statement
IGAP is designed to add authentication capability to IGMP
transactions controlling multicast group membership. The transactions
flow between an IGAP client (host or host proxy) and an authorizing
gateway (authGW). The authGW is assumed to be 1 hop from the IGAP
client, such that the client does not have a route that bypasses the
authGW (or set of authGWs). An IGAP client MUST authenticate itself
to an authGW in order to join a multicast group.
The IGAP model further assumes that the authGW that gates access to
the multicast group is a trusted entity by the hosts and that the
hosts desiring multicast access are untrusted by the authGW. The
authGW is assumed to have access to authoritative information as to
IGAP client privileges and is able to log usage statistics.
4. IGAP Protocol Overview
IGAP is based on IGMPv2 [IGMPv2] and simply extends the IGMPv2
message format. Details not clearly specified in this document
default to those specified in IGMPv2. For example, all IGAP messages
described in this document are sent with IP time-to-live (TTL) set to
1, and use the IP Router Alert option [IPRA] in their IP header as
per the IGMPv2 requirements.
Like IGMP, IGAP messages are encapsulated in IP datagrams and the IP
protocol number in the IP header is 2. The value in the IGMPv2/IGAP
Type field in the header permits IGAP messages to be distinguished
from IGMP messages.
IGAP specifies different behaviors for IGAP clients and for authGWs.
If a router also wants to join some multicast groups, it can perform
both parts of the protocol.
IGAP must be implemented on all candidate IGAP clients desiring use
Hayashi, Andou, He, Tawbi, Niki [Page 4]
Internet Draft draft-hayashi-igap-00.txt October, 2002
of access controlled multicast services. Similarly IGAP-enabled
authGWs must be interposed between IGAP clients and the network to
provide suitable access control.
IGAP clients send IGAP Report messages when they want to join an
access controlled multicast group or in response to an IGAP Query
message. Besides the normal group membership information, the IGAP
clients also attach appropriate user authentication information based
on the security/authentication mechanism employed/requested by the
authGW and requested in the IGAP Query messages received. IGAP
clients send IGAP Leave messages to leave a multicast group. AuthGWs
periodically verify membership via sending IGAP Query messages.
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 function or mechanism.
These functions or mechanisms can be located in different servers,
within on server, or even within the authGWs. In this document, we
use AAA servers as an example for these functions or mechanisms.
This document describes only the operations between IGAP clients and
authGWs, and omits those about between authGWs and back-end
Authentication, Authorization, and Accounting functions or
mechanisms.
When an authGW receives an IGAP Report message, it first checks
whether authentication and authorization are needed or not. If
authentication and authorization are needed, the authGW sends the
IGAP client's group join request information as well as its user
authentication information to an authentication and authorization
server. Based on the server's results of authentication and
authorization processes, the authGW grants or denies the IGAP
client's access request. In addition, the authGW sends an
Authentication message to the IGAP client to inform the client of
the results.
When the IGAP client's access request is granted, the authGW informs
the accounting server to start accounting when it starts forwarding
related multicast traffic into the client's network. When the IGAP
client leaves the multicast group (either via silent departure or an
explicit leave), the authGW informs the accounting server to stop
accounting. Once it receives the response from the accounting server,
it notifies the IGAP client with an Accounting message.
IGAP can support the use of any authentication mechanism such as,
simple and basic password mechanism, more advanced challenge-response
mechanism, access token, etc. This document only specifies the
protocol supports for both the password mechanism and the
Hayashi, Andou, He, Tawbi, Niki [Page 5]
Internet Draft draft-hayashi-igap-00.txt October, 2002
challenge-response mechanism. IGAP is designed to be extensible and
the supports for other authentication mechanisms can be easily
specified.
When authentication, authorization and accounting are not needed for
a specific multicast group, an authGW sends a Notification message to
the IGAP client when it receives its IGAP Report or Leave messages.
When an authGW gets no response from the AAA servers or it does not
receive the requested multicast traffic from upstream multicast
routers, it sends an Error message to the affected IGAP clients.
5. IGAP Message Formats
IGAP messages have the following 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 (bit)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Max Resp Time | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Report Type | # of Aux (N) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auxiliary Data Records
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
where each Auxiliary Data Record has the following format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| Aux Type | Aux Data Len | Aux Data (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Upper 8 bytes of the header correspond to those of IGMPv2. This part
is called "IGMPv2 compatible part". The next 3 bytes, called the
"IGAP standard part", are used by all IGAP packet types and carry
Version, Report Type, Number of Auxiliary Data Record fields. The
Auxiliary Data Records are used to carry the information needed for
authentication and accounting. This part is called "IGAP optional
part".
5.1. Type
Currently, there are three types of IGAP messages.
0x40 = IGAP Membership Report (IGAP Join)
Hayashi, Andou, He, Tawbi, Niki [Page 6]
Internet Draft draft-hayashi-igap-00.txt October, 2002
A membership report sent from the IGAP client to authGW, is used to
join a multicast group, and to reply to an IGAP Membership Query
sent from authGW. Source address of IP header is IP address of the
IGAP client sending the packet, and destination address of IP header
is desired Group Address. Other details follow those of the IGMPv2
Membership report.
0x41 = IGAP Membership Query
This type, sent from authGW to IGAP clients, asks for the current
status of multicast packet reception and Group Address. As in IGMPv2,
there are two sub-types: General Query and Group Specific Query. The
destination address of the former is the all-system multicast group
(224.0.0.1). For the latter, it' is the Group Address that IGAP
clients are currently receiving. The features of these sub-types are
same as per IGMPv2.
0x42 = IGAP Leave Group
This type, sent from IGAP client to authGW, is used to leave a
multicast group. The IP Header includes source address (IP address of
the IGAP client sending the packet), and destination address
(224.0.0.2). Other details follow those of IGMPv2 Leave message.
5.2. Max Response Time
The Max Response Time field is meaningful only for Membership Query
messages (Type 0x41), and specifies the maximum allowed time before
sending a response; the units are 0.1 seconds. In all other messages,
it is set to zero by the sender and ignored by receivers.
To prevent excessive burstiness of IGAP traffic on a subnet, the IGAP
clients on the subnet should choose a random delay time less than the
Max Response Time, and send their Membership Report after this time.
5.3. Checksum
The checksum is the 16-bit one's complement of the one's complement
sum of the whole IGAP message (the entire IP payload). This algorithm
is as described in IGMPv2.
5.4. Group Address
In a Membership Query message, the group address field is set to the
group address being queried. 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.
Hayashi, Andou, He, Tawbi, Niki [Page 7]
Internet Draft draft-hayashi-igap-00.txt October, 2002
5.5. Version
Version field is set to 0x10 as the value to identify IGAP packets.
5.6. Report Type
Report Type field indicates the type of message transferred within
the IGAP packet. Usage of this field is described later.
In Type 0x40 (IGAP Join), there are four Report Types as follows.
0x01 : Basic Join
0x02 : Password Mechanism Join
0x03 : Challenge-Response Mechanism Join Challenge Request
0x04 : Challenge-Response Mechanism Join Response
In Type 0x41 (IGAP Query), there are seven Report Types as follows.
0x21 : Basic Query
0x22 : Challenge-Response Mechanism Challenge
0x23 : Authentication Message
0x24 : Accounting Message
0x25 : Notification Message
0x26 : Error Message
In Type 0x42 (IGAP Leave), there are four Report Types as follows.
0x41 : Basic Leave
0x42 : Password Mechanism Leave
0x43 : Challenge-Response Mechanism Leave Challenge Request
0x44 : Challenge-Response Mechanism Leave Response
5.7. # of Aux (N)
This field indicates the number of Auxiliary Data Record in the
packet.
5.8. Reserved
This field is set to 0xff.
5.9. Auxiliary Data Records
An IGAP packet can contain 0 or many Auxiliary Data Records. The Aux
Type field is 1 byte long and specifies the type of the Auxiliary
Data Record. The Aux Data Len field is 1 byte long and specifies the
length of the auxiliary data in bytes. The Aux Data field contains
Hayashi, Andou, He, Tawbi, Niki [Page 8]
Internet Draft draft-hayashi-igap-00.txt October, 2002
the appropriate data. This document only specifies the following
Auxiliary Data Records.
5.9.1. User Account (Aux Type 0x01) used in all Type
The User Account record contains the account information of a user.
This record is only used in the Join or Leave messages.
5.9.2. Password (Aux Type 0x11): used in Type 0x40 and 0x42
The Password record contains the password of a user account. This
record is only used in the Join or Leave messages and in the
environment where password authentication mechanism is used.
5.9.3. Challenge Value (Aux Type 0x12): used in Type 0x41
The Challenge Value record contains the challenge information. This
record is only used in the Query messages and in the environment
where challenge-response authentication mechanism is used. The first
byte of the Aux Data field indicates the challenge ID.
5.9.4. Response Value (Aux Type 0x13): used in Type 0x40 and 0x42
The Response Value record contains the response information. This
record is only used in the Join or Leave messages and in the
environment where challenge-response authentication mechanism is
used. The first byte of the Aux Data field indicates the challenge
ID.
5.9.5. Authentication Result (Aux Type 0x21): used in Type 0x41
The Authentication Result record contains the result of user
authentication. This record is only used in the Authentication
messages.
The Aux Data field is 1 byte long. This document specifies the
following values.
0x11 : Success
0x12 : Reject
5.9.6. Accounting Action Result (Aux Type 0x22): used in Type 0x41
The Accounting Action Result record contains the result of the
accounting actions that an authGW takes. This record is only used in
Hayashi, Andou, He, Tawbi, Niki [Page 9]
Internet Draft draft-hayashi-igap-00.txt October, 2002
the Accounting messages.
The Aux Data field is 1 byte long. This document specifies the
following values.
0x11 : Start
0x12 : Stop
5.9.7. Notification (Aux Type 0x23): used in Type 0x41
The Notification record contains the information about the status in
IGAP process. This record is only used in the Notification messages.
The Aux Data field is 1 byte long. This document specifies the
following values.
0x11 : Multicast packets delivery start
0x12 : Multicast packets delivery stop
5.9.8. Error (Aux Type 0x24): used in Type 0x41
The Error record contains the error information in IGAP process. This
record is only used in the Error messages.
The Aux Data field is 1 byte long. This document specifies the
following values.
0x11 : Response time out of authentication server
6. IGAP Packet Type
IGAP Packet type is determined by the Report Type field.
Some types of packets take an auxiliary data. When other auxiliary
data which is not specified this document added to IGAP packet, it
should not be discarded it. We show a auxiliary data by each IGAP
packet we need at least here.
6.1. Basic Join
Type : 0x40
Group Address : connected group address
Report Type : 0x01
Auxiliary data record : User Account
This packet type is used in the case which the join process does not
require the authentication process.
Hayashi, Andou, He, Tawbi, Niki [Page 10]
Internet Draft draft-hayashi-igap-00.txt October, 2002
6.2. Password Mechanism Join
Type : 0x40
Group Address : connected group address
Report Type : 0x02
Auxiliary data record : User Account and Password
This packet type is used in the case which the join process require
password authentication process.
6.3. Challenge-Response Mechanism Join Challenge Request
Type : 0x40
Group Address : connected group address
Report Type : 0x03
Auxiliary data record : User Account
This packet type is used to initiate the challenge process for
Challenge-response authentication mechanism. AuthGW received this
packet issues Challenge packet.
6.4. Challenge-Response Mechanism Join Response
Type : 0x40
Group Address : connected group address
Report Type : 0x04
Auxiliary data record : User Account and Response Value
This packet type is used to respond to the Challenge issued by the
authGW. The Response Value is determined from two parameters. One is
the Challenge Value, which is in the Challenge packet. The other is
the value calculated from the user password by MD5 [MD5].
6.5. Basic Query
This packet type is used in the case which authGW checks whether the
IGAP client(s) are receiving multicast traffic at regular intervals,
and authGW confirms the IGAP client's request to leave a multicast
group. There are two sub-types of Basic Query, as described in
section 3.1. In the case of General Query, i.e. destination address
of IP header is the all-systems multicast group (224.0.0.1), it's
called the General-and-Basic Query. In this sub-type, the value of
Group Address field is set to zero. In the case of Group Specific
Query, i.e. destination address of IP header is the desired group
address, it's called the Group-Specific-and-Basic Query. In this
sub-type, the value of Group Address field is equal to the value of
the desired destination address. This packet type doesn't have to
have IGAP optional part.
Hayashi, Andou, He, Tawbi, Niki [Page 11]
Internet Draft draft-hayashi-igap-00.txt October, 2002
6.5.1. General-and-Basic Query
Type : 0x41
Group Address : (set to zero)
MaxRespTime : given value (default : 0x64)
Report Type : 0x21
6.5.2. Group-Specific-and-Basic Query
Type : 0x41
Group Address : connected group address
MaxRespTime : given value (default : 0x64)
Report Type : 0x21
6.6. Challenge-Response Mechanism Challenge
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x22
Auxiliary data record : User Account and Challenge Value
This packet type is used in the case which authGW responds to CHAP
Join Challenge Request from an IGAP client. The AuthGW sends this
packet to notify Challenge Value. The IGAP client that received this
packet replies with a Join Response packet.
6.7. Authentication Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x23
Auxiliary data record : User Account and Authentication Result
This packet type is used in the case which authGW provides
information about the result of authentication. The Message field
holds one of two values: either authentication succeed or
authentication reject. The process adopted by the IGAP client upon
receiving this packet type is up to implementation, however, neither
value must impact other IGAP process.
6.8. Accounting Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Hayashi, Andou, He, Tawbi, Niki [Page 12]
Internet Draft draft-hayashi-igap-00.txt October, 2002
Report Type : 0x24
Auxiliary data record : User Account and Accounting Action Result
This packet type is used in the case which authGW provides
information about accounting status. The Message field holds one of
two values: one indicates the start of accounting, and the other
indicates the termination of accounting. The process adopted by the
IGAP client upon receiving this packet type is up to implementation,
however, neither value must impact other IGAP process.
6.9. Notification Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x25
Auxiliary data record : User Account and Notification
This packet type is used in the case which authGW provides
information about a correct status in IGAP process, except
authentication and accounting. The process adopted by the IGAP client
upon receiving this packet type is up to implementation, however,
neither value must impact other IGAP process.
6.10. Error Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x26
Auxiliary data record : User Account and Error
This packet type is used in the case which authGW provides
information about an error status in IGAP process, except
authentication and accounting. The process adopted by the IGAP client
upon receiving this packet type is up to implementation, however,
neither value must impact other IGAP process.
6.11. Basic Leave
Type : 0x42
Group Address : connected group address
Report Type : 0x41
Auxiliary data record : User Account
This packet type is used in the case which the leave process does not
require the authentication process.
Hayashi, Andou, He, Tawbi, Niki [Page 13]
Internet Draft draft-hayashi-igap-00.txt October, 2002
6.12. Password mechanism Leave
Type : 0x42
Group Address : connected group address
Report Type : 0x42
Auxiliary data record : User Account and Password
This packet type is used in the case which the leave process require
password authentication process.
6.13. Challenge-Response Mechanism Leave Challenge Request
Type : 0x42
Group Address : connected group address
Report Type : 0x43
Auxiliary data record : User Account
This packet type is used to initiate the challenge process for
challenge-response authentication. AuthGW received this packet issues
Challenge packet.
6.14. Challenge-Response Mechanism Leave Response
Type : 0x42
Group Address : connected group address
Report Type : 0x44
Auxiliary data record : User Account and Response Value
This packet type is used to respond to the Challenge issued by the
authGW. The algorithm used to calculate the Response value is the
same method of Challenge-response Join Response.
7. IGAP State Machines
This Section describes examples of IGAP State Machines. The example
of FSM is shown about each pattern as follows.
Note:
-There are two ways of leaving a multicast group: General Leave
Process and Fast Leave Process. General Leave Process basically
equals the leave process of IGMPv2.
Fast Leave Process dispenses with IGAP Query packets. When AuthGW
receives IGAP Leave message from the user client, it stops sending
multicast packets without sending IGAP Query packet. Fast Leave
Process is recommended when fast response for IGAP Leave is needed.
-About operation of General Query, it is the same as FSM of IGMPv2.
Hayashi, Andou, He, Tawbi, Niki [Page 14]
Internet Draft draft-hayashi-igap-00.txt October, 2002
7.1. FSM for Client
C1[Non Member]:
if join group{
send Challenge-Request-Join;
start Challenge-Timer;
transition C2;
}
C2[Waiting Challenge Member]:
if Challenge received{
send Challenge-Response-Join;
stop Challenge-Timer;
start Authenticated-Timer;
transition C3;
}
else(Challenge-Timer expired){
stop Challenge-Timer;
transition C1;
}
C3[Waiting Authentication Message Member]:
if Authentication-Message(Reject) received
or Error-Message(Response time out) received
or Authenticated-Timer expired{
stop Authenticated-Timer;
transition C1;
}
else if Authentication-Message(Success) received
stop Authenticated-Timer;
transition C4;
}
C4[Idle Member]:
if General-Query received
or Group-Specific-Query received{
start Delaying-Timer;
transition C5;
}
else if leave group{
send Basic-Leave;
transition C6;
}
C5[Delaying Member]:
if leave group{
send Basic-Leave;
stop Delaying-Timer;
transition C6;
}
Hayashi, Andou, He, Tawbi, Niki [Page 15]
Internet Draft draft-hayashi-igap-00.txt October, 2002
else(Delaying-Timer expired){
send Challenge-Request-Join;
stop Delaying-Timer;
start Challenge-Timer;
transition C2;
}
C6[Waiting Accounting Message Member]:
if Accounting-Message(Stop) received{
transition C1;
}
else if General-Query received{
send Basic-Leave;
continue(no transition);
}
7.2. FSM for AuthGW
A1[No Transfer Present]:
if Challenge-Request-Join received{
send Challenge;
start Response-Timer;
transition A2;
}
else if Basic-Leave received{
send Accounting-Request(Stop);
transition A8;
}
A2[Waiting Challenge-Response]:
if Challenge-Response-Join received{
send Authentication Request;
stop Response-Timer;
start Authentication-Timer;
transition A3;
}
else(Response-Timer expired){
stop Response-Timer;
transition A1;
}
A3[Waiting Authentication-Response]:
if Access-Reject received{
send Authentication-Message(Reject);
stop Authentication-Timer;
transition A1;
}
Hayashi, Andou, He, Tawbi, Niki [Page 16]
Internet Draft draft-hayashi-igap-00.txt October, 2002
else if Access-Accept received{
send Accounting-Request(Start);
send Authentication-Message(Success);
stop Authentication-Timer;
start Accounting-Timer;
transition A4;
}
else(Authentication-Timer expired){
send Error-Message(Response time out);
stop Authentication-Timer;
start Validity-Timer;
transition A5;
}
A4[Waiting Accounting-Response(Start)]:
if Accounting-Response received{
send Accounting-Message(Start);
stop Accounting-Timer;
start Validity-Timer;
transition A5;
}
else(Accounting-Timer expired){
send Error-Message(Response time out);
stop Accounting-Timer;
start Validity-Timer;
transition A5;
}
A5[Transfer Present]:
if Challenge-Request-Join received{
if Validity-Timer < Validity-Period{
continue(no transition);
}
else(Validity-Timer expired){
send Accounting-Request(Stop);
stop Validity-Timer;
start Accounting-Timer
transition A6;
}
}
else if Basic-Leave received{
if General Leave Process{
send Group-Specific-Query;
stop Validity-Timer;
start Last-Member-Query-Interval-Timer;
transition A7;
}
Hayashi, Andou, He, Tawbi, Niki [Page 17]
Internet Draft draft-hayashi-igap-00.txt October, 2002
else if Fast Leave Process{
send Accounting-Request(Stop);
stop Validity-Timer;
transition A8;
}
}
A6[Waiting Accounting-Response(Stop)]:
if Accounting-Response received{
send Accounting-Message(Stop);
send Challenge;
stop Accounting-Timer;
start Response-Timer;
transition A2;
}
else(Accounting-Timer expired){
send Error-Message(Response time out);
stop Accounting-Timer;
start Validity-Timer;
transition A5;
}
A7[Waiting Membership Report]:
if Challenge-Request-Join received{
if Validity-Timer < Validity-Period{
stop Last-Member-Query-Interval-Timer;
clear Last-Member-Query-Counter;
transition A5;
}
else(Validity-Timer expired){
send Accounting-Request(Stop);
stop Validity-Timer;
stop Last-Member-Query-Interval-Timer;
start Accounting-Timer;
clear Last-Member-Query-Counter;
transition A6;
}
}
else(Last-Member-Query-Interval-Timer expired){
if Last-Member-Query-Counter < Last-Member-Query-Count{
send Group-Specific-Query;
restart Last-Member-Query-Interval-Timer;
increment Last-Member-Query-Counter;
continue(no transition);
}
Hayashi, Andou, He, Tawbi, Niki [Page 18]
Internet Draft draft-hayashi-igap-00.txt October, 2002
else(Last-Member-Query-Counter expired){
send Accounting-Request(Stop);
stop Validity-Timer;
stop Last-Member-Query-Interval-Timer;
start Accounting-Timer;
clear Last-Member-Query-Counter;
transition A8;
}
}
A8[Waiting Accounting-Response(Stop) for Leave]:
if Accounting-Response received{
send Accounting-Message(stop);
stop Accounting-Timer;
transition A1;
}
else(Accounting-Timer expired){
send Error-Message(Response time out);
stop Accounting-Timer;
transition A1;
}
8. List of Timers, Counters
This section describes the parameters set in AuthGW and Client when
supporting IGAP processes.
8.1. Timers and Counters for Client
8.1.1. Challenge-Timer
It controls waiting time from sending Join message to receiving
Challenge Message.
8.1.2. Authenticated-Timer
It controls waiting time from sending Response Message to receiving
Authentication Message (accept or reject) from AuthGW.
8.1.3. Delaying-Timer
It controls waiting time from receiving Query to sending Join Message
to AuthGW. It is calculated from Max Resp Time.
8.2. Timers and Counters for AuthGW
Hayashi, Andou, He, Tawbi, Niki [Page 19]
Internet Draft draft-hayashi-igap-00.txt October, 2002
8.2.1. Robustness Variable
It is the same meaning as IGMPv2.
Default: 2.
8.2.2. Response-Timer
It controls waiting time from sending Challenge Message to receiving
Response Message.
8.2.3. Authentication-Timer
It controls waiting time from sending Authentication request to
receiving Authentication Response.
8.2.4. Accounting-Timer
It controls waiting time from sending Accounting request to receiving
Accounting Response.
8.2.5. Validity-Period (Validity-Timer)
This is an integer multiple of General-Query Interval in units of
second, and used by AuthGW to determine whether user authentication
is necessary or not.
8.2.6. Query-Response-Interval (Query-Response-Interval-Timer)
It is the same meaning as IGMPv2. The Max Response Time inserted into
the periodic General Queries.
Default: 100 (10 seconds)
8.2.7. Last-Member-Query-Interval (Last-Member-Query-Interval-Timer)
It is the same meaning as IGMPv2. The Last-Member-Query-Interval is
the Max Response Time inserted into Group-Specific Queries sent in
response to Leave Group messages, and is also the amount of time
between Group-Specific Query messages.
Default: 10 (1 second)
8.2.8. Last-Member-Query-Count
It is the same meaning as IGMPv2. The Last-Member-Query-Count is the
number of Group-Specific Queries sent before the router assumes there
Hayashi, Andou, He, Tawbi, Niki [Page 20]
Internet Draft draft-hayashi-igap-00.txt October, 2002
are no local members.
Default: the Robustness Variable.
9. Security Considerations
IGAP is based around an asymmetrical trust model in which the authGW
does not trust the IGAP client, but the IGAP client trusts the authGW
therefore may not be suitable for use in isolation where mutual
authentication is required.
IGAP supports a number of authentication mechanisms and inherits the
security concerns of each, especially when there is shared media
between the IGAP client and the authGW.
IGAP does not encrypt multicast traffic. For multicast content
encryption related technology, please refer to other IETF work. IGAP
does not obstruct snooping of multicast traffic by unauthorized hosts
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.
References
[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.
Author's Addresses
Tsunemasa Hayashi
NTT Network Innovation Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
Phone : +81 468 59 8790
Email : hayashi@exa.onlab.ntt.co.jp
Hayashi, Andou, He, Tawbi, Niki [Page 21]
Internet Draft draft-hayashi-igap-00.txt October, 2002
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
Phone : 1 978 288 7482
Email : haixiang@nortelnetworks.com
Wassim Tawbi
Nortel Networks
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@trl.mei.co.jp
Hayashi, Andou, He, Tawbi, Niki [Page 22]