Internet DRAFT - draft-andou-igmp-auth
draft-andou-igmp-auth
Internet Engineering Task Force Daisuke Andou, NTT
INTERNET-DRAFT Takako Sato, NTT
June, 2002 Tsunemasa Hayashi, NTT
Expires: December, 2002 Akihiro Tanabe, NTT
Kaori Izutsu, NTT
Yoshinori Goto, NTT
Yukikuni Nishida, NTT
Wataru Inoue, NTT
IGMP for user Authentication Protocol (IGAP)
<draft-andou-igmp-auth-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to 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
This memo describes IGAP, which allows user IP user clients and IP
routers or network access servers to verify whether they can
participate in a multicast group they hope and transport some
information about it. IGAP is derived from IGMPv2, which can make
users join a multicast group, who has the claim to participate a
multicast group in a service. It's important for service providers
to protect their revenue source.
1. Introduction
IGMP for user Authentication Protocol (IGAP) allows user clients to
connect to network gateways for access-controlled multicast services.
These gateways (such as routers and called "authGW" hereafter) have
the ability to authenticate the user client's authority to join/leave
a multicast group. The security functions offered by IGAP will
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 1]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
encourage the development of new commercial services. This memo
describes only the operations between user client and authGW, and
omits those about between authGW and authentication servers.
2. Aspects of IGAP
IGAP is designed to transport the information for user authentication
and accounting, based on IGMPv2 [IGMPv2], for IP Multicast services.
IGAP basically adopts the IGMPv2 message format and extends it only
slightly. Details not clearly specified in this document are taken to
follow the IGMPv2 equivalents. For example, all IGAP messages
described in this document are sent via IP TTL 1, and use the IP
Router Alert option [IPRA] in their IP header as per the IGMPv2
requirements.
IGAP messages are encapsulated in IP datagrams the same as IGMPv2,
and the IP protocol number in the IP header is 2, the same as IGMPv2.
Note that the value in the IGAP Type field in the header, which is
also used by IGMPv2, differs from that of IGMPv2. User clients and
routers can distinguish IGAP from IGMPv2 by this field.
IGAP can support the use of any security/authentication system. As an
example, the user authentication information can include encrypted
user passwords. IGAP supports both PAP [PAP] and CHAP [CHAP]
mechanisms.
IGAP must be implemented on all user clients wishing to join a
protected multicast service and all authGWs. AuthGWs support both
IGMPv2 and IGAP. The processing of IGAP packets has no impact on the
processing of IGMPv2 packets.
3. IGAP Header Format
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 | Reserved | CHAP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Account Size | Message Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| User Account |
| |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 2]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Upper 8 bytes of the header are equal to those of IGMPv2. This part
is called "IGMPv2 compatible part". Lower 40 bytes are the fields
that include new information defined in IGAP. Upper 2 bytes of this
area, called the "IGAP standard part", are used by all IGAP packet
types and carry Version, Report Type, Reserved, and CHAP ID field.
Lower 38 bytes are used to carry the information needed for
authentication and accounting. This part is called "IGAP optional
part". Some IGAP header fields are not used in some processes.
Note that IGAP messages may be longer than 48 bytes, especially
future versions of IGAP. Any future IGAP implementation must
recognize the first ten bytes. The IGAP checksum is always computed
over the whole IP payload, not just the first 48 bytes. This chapter
describes all of the fields.
3.1. Type
Currently, there are three types of IGAP messages.
0x40 = IGAP Membership Report (IGAP Join)
This type, sent from user client to authGW, is used to join a
multicast group, and to reply to a IGAP Membership Query sent from
authGW. Source address of IP header is IP address of the user client
sending the packet, and destination address of IP header is desired
Group Address. Other details basically follow those of IGMPv2
Membership report.
0x41 = IGAP Membership Query
This type, sent from authGW to user client, 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's Group Address which user clients
are now receiving. The features of these sub-types are same as per
IGMPv2.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 3]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
0x42 = IGAP Leave Group
This type, sent from user client to authGW, is used to leave a
multicast group. The IP Header includes source address (IP address
of the user client sending the packet), and destination address
(224.0.0.2). Other details
basically follow those of IGMPv2 Membership report.
3.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 user
clients on the subnet should choose a random delay time less than the
Max Response Time, and send their Membership Report after this time.
3.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
equals that of IGMPv2.
3.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.
3.5. Version
Version field is set to 0x10 as the value to identify IGAP packets.
3.6. Report Type
Report Type field indicates the type of message transferred within
the IGAP packet. Usage of this field is described in Chapter 4.
In Type 0x40 (IGAP Join), there are four Report Types as follows.
0x01 : Basic Join
0x02 : PAP Join Authentication Request
0x03 : CHAP Join Challenge Request
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 4]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
0x04 : CHAP Join Response
In Type 0x41 (IGAP Query), there are seven Report Types as follows.
0x21 : Basic Query
0x22 : User-Specific Query
0x23 : CHAP Challenge
0x24 : Authentication Message
0x25 : Accounting Message
0x26 : Notification Message
0x27 : Error Message
In Type 0x42 (IGAP Leave), there are four Report Types as follows.
0x41 : Basic Leave
0x42 : PAP Leave Authentication Request
0x43 : CHAP Leave Challenge Request
0x44 : CHAP Leave Response
3.7. Reserved
This field is set to 0xff unless used in a service.
3.8. CHAP ID
CHAP ID field is meaningful only when CHAP Authentication is used.
AuthGW sets it when sending a CHAP Challenge packet to a user client.
User client uses the value in this field in order to create the CHAP
Response to reply to the CHAP Challenge. AuthGWs use the value of
this field to check the correspondence between CHAP Response and
CHAP Challenge. If this field is not used, it is set to the default
value of 0x00.
3.9. Account Size
This field indicates the size of User Account field in units of
bytes. If this field is not used, it is set to the default value of
0x00.
3.10. Message Size
This field indicates the size of Message field in units of bytes. If
this field is not used, it is set to the default value of 0x00.
3.11. Reserved
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 5]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
This field is set to 0xff unless used in a service.
3.12. User Account
This field indicates the user account to be authenticated. The size
of this field is 16 bytes. If the size value occupies less than 16
bytes, the value is followed by 0xff.
3.13 Message
This field is used according to Report Type. If this field is used
for authentication, it carries user password. If CHAP is used, the
password is encrypted.
The size of this field is 16 bytes. If the value of the size of a
message occupies less than 16 bytes, the value is followed by 0xff.
4. IGAP Packet Type
IGAP Packet type is determined by the Report Type field. In the
following descriptions, fields that are not specifically mentioned
are assumed to be "unused". Regardless of the values in unused
fields, authGWs should process the packet correctly. Chapter.3
provides details about the fields not shown in this chapter.
4.1. Basic Join
Type : 0x40
Group Address : connected group address
Report Type : 0x01
User Account : user ID
Message : (unused)
This packet type is used in the case which the join process does not
require the authentication process.
4.2. PAP Join Authentication Request
Type : 0x40
Group Address : connected group address
Report Type : 0x02
User Account : user ID
Message : user password (not encrypted)
This packet type is used in the case which the join process require
PAP authentication process.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 6]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
4.3. CHAP Join Challenge Request
Type : 0x40
Group Address : connected group address
Report Type : 0x03
User Account : user ID
Message : (unused)
This packet type is used to initiate the challenge process for CHAP
authentication. AuthGW received this packet issues CHAP Challenge
packet described in Chapter 4.7.
4.4. CHAP Join Response
Type : 0x40
Group Address : connected group address
Report Type : 0x04
User Account : user ID
Message : Response Value
This packet type is used to respond to the CHAP Challenge issued by
the authGW. The Response Value is determined from two parameters.
One is the Challenge Value, which is in the CHAP Challenge packet,
described in chapter 4.7. The other is the value calculated from the
user password by MD5 [MD5].
4.5. Basic Query
This packet type is used in the case which authGW checks whether the
user client(s) are receiving multicast traffic at regular intervals,
and authGW confirms the user 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.
4.5.1. General-and-Basic Query
Type : 0x41
Group Address : (set to zero)
MaxRespTime : given value (default : 0x64)
Report Type : 0x21
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 7]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
IGAP optional part : (unused)
4.5.2. Group-Specific-and-Basic Query
Type : 0x41
Group Address : connected group address
MaxRespTime : given value (default : 0x64)
Report Type : 0x21
IGAP optional part : (unused)
4.6. User-Specific Query
This packet type is used on similar case of Basic Query, but this
packet type has IGAP optional part, so authGW can identify the
user(s) who is receiving a multicast packet, or leaving. There are
also two sub-types as Basic Query. For General Query the first
sub-type is called the General-and-User-Specific Query. In this
sub-type, the value of Group Address field is set to zero. For Group
Specific Query, the sub-type is called the Group-and-User-Specific
Query. In this sub-type, the value of Group Address field is equal
to the value of the desired destination address.
4.6.1. General-and-User-Specific Query
Type : 0x41
Group Address : (set to zero)
MaxRespTime : given value (default : 0x64)
Report Type : 0x22
User Account : user ID
Message : (unused)
4.6.2. Group-and-User-Specific Query
Type : 0x41
Group Address : connected group address
MaxRespTime : given value (default : 0x64)
Report Type : 0x22
User Account : user ID
Message : (unused)
4.7. CHAP Challenge
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x23
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 8]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
User Account : user ID
Message : Challenge Value
This packet type is used in the case which authGW responds to CHAP
Join Challenge Request from user client. AuthGW sends this packet to
notify Challenge Value. User client received this packet issues CHAP
Join Response packet described in Chapter 4.4.
4.8. Authentication Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x24
User Account : user ID
Message : 0x11 (Authentication Success)
or 0x21 (Authentication Reject)
or other value (vendor specific)
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 user client upon
receiving this packet type is up to implementation, however, neither
value must impact other IGAP process. Vendors may add their own
specific values to the Message field, but the values used must not
impact any other IGAP process.
4.9. Accounting Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x25
User Account : user ID
Message : 0x11 (Accounting Start)
or 0x21 (Accounting Stop)
or other value (vendor specific)
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
user client upon receiving this packet type is up to implementation,
however, neither value must impact other IGAP process. The same is
true for the vendor-specified values.
4.10. Notification Message
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 9]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x26
User Account : user ID
Message : vendor specific value
This packet type is used in the case which authGW provides
information about an correct status in IGAP process, except
authentication and accounting. The process adopted by the user
client upon receiving this packet type is up to implementation,
however, neither value must impact other IGAP process. The value of
Message field in this packet type isn't defined in this document.
Vendors may add their own specific values to the Message field, but
the values used must not impact any other IGAP process.
4.11. Error Message
Type : 0x41
MaxRespTime : given value (default : 0x64)
Group Address : connected group address
Report Type : 0x27
User Account : user ID
Message : vendor specific value
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 user
client upon receiving this packet type is up to implementation,
however, neither value must impact other IGAP process. The value of
Message field in this packet type isn't defined in this document.
The same is true for the vendor-specified values.
4.12. Basic Leave
Type : 0x42
Group Address : connected group address
Report Type : 0x41
User Account : user ID
Message : (unused)
This packet type is used in the case which the leave process does
not require the authentication process.
4.13. PAP Leave Authentication Request
Type : 0x42
Group Address : connected group address
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 10]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
Report Type : 0x42
User Account : user ID
Message : user password (not encrypted)
This packet type is used in the case which the leave process require
PAP authentication process.
4.14. CHAP Leave Challenge Request
Type : 0x42
Group Address : connected group address
Report Type : 0x43
User Account : user ID
Message : (unused)
This packet type is used to initiate the challenge process for CHAP
authentication. AuthGW received this packet issues CHAP Challenge
packet described in Chapter 4.7.
4.15. CHAP Leave Response
Type : 0x42
Group Address : connected group address
Report Type : 0x44
User Account : user ID
Message : Response Value
This packet type is used to respond to the CHAP Challenge issued by
the authGW. The algorithm used to calculate the Response value is
the same method of CHAP Join Response.
References
[IGMPv2]
W. Fenner, "Internet Group Management Protocol, Version 2",
RFC 2236, Xerox PARC, November 1997.
[PAP]
B.Lloyd, W. Simson, "PPP Authentication Protocols", RFC 1334,
Octover, 1992.
[CHAP]
W. Simson, "PPP Challenge Handshake Authentication Protocol (CHAP)",
RFC 1994, August 1996.
[IPRA]
D. Katz, "IP Router Alert Option", RFC 2113, Cisco Systems,
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 11]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
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.
[RADACCT]
C. Rigney, "RADIUS Accounting", RFC 2866, Livingston, June 2000.
Author's Addresses
Daisuke Andou, Takako Satou, Akihiro Tanabe, Kaori Izutsu,
Yoshinori Gotou
NTT Access Network Service Systems Laboratories
1-6 Nakase Mihiama-ku, Chiba-shi, Chiba, 261-0023 Japan
Phone : +81 43 211 2115
Email : {dandou, t-sato, atanabe, izutsu, goto}@ansl.ntt.co.jp
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
Yukikuni Nishida, Wataru Inoue
NTT Cyber Solutions Laboratories
1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan
Phone : +81 468 59 3496
Email : {nishida.yukikuni, inoue.wataru}@lab.ntt.co.jp
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 12]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
Appendix 1. Examples of Vendor Specific Authentication Messages
This appendix provides examples of Message field contents as
specified by the vendor for Authentication Message (see Chapter 4.8).
The vendor must enter the appropriate values in each message except
for the values specified by this document, i.e. 0x11 (Authentication
Success) and 0x21 (Authentication Reject).
The cases wherein the user can't receive the multicast packets
requested are described below. These messages indicate the reason
for the failure of authentication, and they are sent instead of the
Authentication Reject message (0x21).
0x31 : Unknown User Account
When the user ID in the User Account field (Chapter 3.12) is not
registered on the Authentication server, authGW sends this message
packet to user client.
0x32 : Unknown Group Address
When authGW receives notification that the group address in the Group
Address field (Chapter 3.4) is not used in the service requested from
authentication server, authGW sends this message packet to user
client.
0x33 : Request to participate in a multicast group rejected
When the user doesn't have a valid claim to participate in the
multicast group specified in the Group Address field, authGW sends
this message packet to user client.
0x41 : Invalid Group Address
When the group address in the Group Address field is not registered
with the address list in authGW, authGW sends this message packet to
user client. In this case, authGW doesn't send any packet to the
authentication server. The usage of this message is described in
Appendix 9.
Appendix 2. Examples of Vendor Specific Accounting Messages
This appendix provides examples of Message field values entered by
the vendor into the Accounting Message (see Chapter 4.9). The vendor
must enter the appropriate values in each message except for the
values specified by this document, i.e. 0x11 (Accounting Start) and
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 13]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
0x21 (Accounting Stop).
0x31 : Notification of charge-free
When the accounting process is not needed, authGW sends this message
packet to user client.
0x32 : Notification of excess time
In the case where there is a time limit to participate in a multicast
group and the user client sending an IGAP join packet has already
reached the time limit, authGW sends this message packet to user
client.
Appendix 3. Examples of Vendor Specific Notification Message
This appendix provides examples of Message field values entered by
the vendor into Notification Message (see Chapter 4.10).
0x11 : Notification of delivery
When authGW starts or continues to send multicast packets, authGW
sends this message packet to user client.
0x12 : Notification of delivery stop
When authGW stops sending multicast packets, authGW sends this
message packet to user client.
0x13 : Notification of time out
If there is a time limit to participate in a multicast group and time
out been triggered while user client is participating in the
multicast group, authGW sends this message packet to user client.
Appendix 4. Examples of Vendor Specific Error Messages
This appendix describes the examples of Message field values entered
by the vendor into Error Message (see Chapter 4.11).
0x11 : Response time out of authentication server
When the response packet indicating acceptance or rejection didn't
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 14]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
arrive at authGW from the authentication server in authentication
process, authGW determines that authentication server is "dead",
and sends this message packet to user client. The usage of this
message is described in Chapter A-3 of Appendix 5.
0x12 : Multicast packets not being delivered
When authGW doesn't receive multicast packets of the desired group
address, e.g. router due to network accident, authGW sends this
message packet to user client. The usage of this message is
described in Chapter A-4 of Appendix 5.
Appendix 5. IGAP sequence with PAP mechanism
This appendix describes examples of IGAP sequences with PAP
mechanism. In the figures in this appendix, IGAP packet types are
abbreviated as follows.
IGAP Join (Type:0x40)
PAP Join Authentication Request (Report Type:0x02) : PAP Join
IGAP Membership Query (Type:0x41)
General-and-Basic Query (Report Type:0x21) : G&B Query
Group-Specific-and-Basic Query (Report Type:0x21) : GS&B Query
Authentication Message (Report Type:0x24) : Auth Message
Accounting Message (Report Type:0x25) : Acct Message
Notification Message (Report Type:0x26) : Ntf Message
Error Message (Report Type:0x27) : Err Message
IGAP Leave (Type:0x42)
Basic Leave (Report Type:0x41) : Bsc Leave
In the examples of this appendix, destination address of IP header
in Authentication Message, Accounting Message, Notification Message
and Error Message, is IP address of user client. RADIUS is used as
authentication with PAP and accounting mechanism. User client should
have a function to display notification message depending on Message
packet received, so the user can know what happened in IGAP process.
In the figures in this appendix, transferred packet has the
following form.
Type Name[Type (No.)]
(Report Type Name [Report Type (No.)])
(Message[(No.)])
(Message[(No.)]) is described for the cases where Report Type is
Authentication Message, Accounting Message, Notification Message or
Error Message.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 15]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
Arrowheads in the figure have the following meanings.
-----> : IGAP packet
====>> : Multicast packet
Types of Packet transferred between AuthGW and RADIUS server are
fully compliant with RADIUS specifications.
A. Process for user client to start receiving multicast packets
This chapter describes the process whereby user client can start
(or not to start) to receive multicast packets. In the process, user
client sends IGAP Join message to authGW, and authGW asks
authentication (RADIUS) server whether desired multicast packets can
be transferred to the user client, if authentication is needed, and
notifies the result to the user client via one of the IGAP Membership
Query messages. The decision whether authentication is needed or not
in the process is entrusted to authGW. Details of the decision are
described in Appendix.9.
A-1. Access accept
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | Access |
|--------------------->| Request |
| |----------------->|
| Query[0x41] | Access |
| (Auth Message[0x24]) | Accept |
| (Message[0x11]) |<-----------------|
|<---------------------| |
| Multicast traffic | Accounting |
|<<====================| Request(Start) |
| |----------------->|
| Query[0x41] | Accounting |
| (Acct Message[0x25]) | Response |
| (Message[0x11]) |<-----------------|
|<---------------------| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 16]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
A-2. Access reject
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | Access |
|--------------------->| Request |
| |----------------->|
| Query[0x41] | Access |
| (Auth Message[0x24]) | Reject |
| (Message[0x21]) |<-----------------|
|<---------------------| |
| | |
A-3. No response (time out) of RADIUS server
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | Access |
|--------------------->| Request |
| |----------------->|
| Query[0x41] | |
|(Error Message[0x27]) | (No Response) |
| (Message[0x11]) | |
|<---------------------| |
| | |
AuthGW sets three parameters for communication with the
authentication server: RADIUS Retrying Count, RADIUS Transmit
Interval and RADIUS Waiting Interval. These parameters are
described in Appendix 8.
If the response packet from the RADIUS server indicating acceptance
or rejection fails to arrive at authGW, authGW resends Access Request
at intervals of RADIUS Retrying Interval until the number of
retransmissions reaches RADIUS Retrying Count. When RADIUS Transmit
Waiting Interval expires, authGW determines that the authentication
server is dead, and sends IGAP Error Message packet to user client.
A-4. Access to invalid address
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | |
|--------------------->| |
| Query[0x41] | |
| (Auth Message[0x24]) | |
| (Message[0x41]) | |
|<---------------------| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 17]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
AuthGW can identify whether multicast address sent from user client
is available. (described in Appendix 9). If the multicast address is
not registered with the address list in authGW, authGW determines
that this address is invalid, and sends IGAP Error Message packet to
user client.
A-5. Multicast packets not being delivered to authGW
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | Access |
|--------------------->| Request |
| |----------------->|
| | Access |
| | Accept |
| |<-----------------|
|(No Multicast Packet) | |
| | |
| query[0x41] | |
|(Error Message[0x27]) | |
| (Message[0x12]) | |
|<---------------------| |
| | |
When authGW can't send multicast packets of the desired group address
even though authGW has received Access Accept, authGW sends IGAP
Error Message packet to user client. Even if authentication is not
needed, authGW sends the same error message.
A-6. Neither authentication nor accounting is needed
(e.g. Free Channel)
client AuthGW RADIUS server
v v v
| Join[0x40] | |
| (PAP Join[0x02]) | |
|--------------------->| |
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (Ntf Message[0x26]) | |
| (Message[0x11]) | |
|<---------------------| |
| | |
AuthGW doesn't have to send Authentication Message and Accounting
Message and instead sends Notification Message instead.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 18]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
B. Process to continue receiving multicast packet for user client
This chapter describes the process whereby the user client who has
already received multicast packets, continues to receive them or not.
In the process, authGW sends IGAP Membership Query message
(described in Chapter 3.1) to user client to query whether it is
receiving the multicast packets or not, as is done in IGMPv2. The
Query message is sent at regular intervals, the period of which is
decided by Query Interval [IGMPv2]. Upon receiving IGAP Membership
Query message, user client sends IGAP Join message to authGW as the
reply. User client set the interval randomly in replying to IGAP
Membership Query message, but the value is always less than Max Resp
Time (described in Chapter 3.2).
In some processes, user client is re-authenticated. The interval of
re-authentication depends on Validity Period. This value is set in
authentication (RADIUS) server, and is sent to authGW. The value of
Validity Period is an integer multiple of Query Interval in units of
second. For example, if the value of Query Interval is 60 and the
value of Validity Period is 600, authGW asks the authentication
(RADIUS) server every 10 processes as to whether requested multicast
packets should be transferred to the user client.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 19]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
B-1. Access accept
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Join[0x40] | |
| (PAP Join[0x02]) | Accounting |
|--------------------->| Request(Stop) |
| |----------------->|
| | Accounting |
| Query[0x41] | Response |
| (Acct Message[0x25]) |<-----------------|
| (Message[0x21]) | |
|<---------------------| Access |
| | Request |
| |----------------->|
| Query[0x41] | Access |
| (Auth Message[0x24]) | Accept |
| (Message[0x11]) |<-----------------|
|<---------------------| Accounting |
| | Request(Start) |
| |----------------->|
| Query[0x41] | Accounting |
| (Acct Message[0x25]) | Response |
| (Message[0x11]) |<-----------------|
|<---------------------| |
| | |
| Continue to cast | |
| Multicast traffic | |
|<<====================| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 20]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
B-2. Access reject
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Join[0x40] | |
| (PAP Join[0x02]) | Accounting |
|--------------------->| Request(Stop) |
| |----------------->|
| | Accounting |
| Query[0x41] | Response |
| (Acct Message[0x25]) |<-----------------|
| (Message[0x21]) | |
|<---------------------| Access |
| | Request |
| |----------------->|
| Query[0x41] | Access |
| (Auth Message[0x24]) | Reject |
| (Message[0x21]) |<-----------------|
|<---------------------| |
| | |
| Traffic Stop | |
| X<<======| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 21]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
B-3. No response (time out) of RADIUS server
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Join[0x40] | |
| (PAP Join[0x02]) | Accounting |
|--------------------->| Request(Stop) |
| |----------------->|
| Query[0x41] | |
|(Error Message[0x27]) | (No Response) |
| (Message[0x11]) | |
|<---------------------| |
| | |
| Query[0x41] | |
| (Acct Message[0x25]) | |
| (Message[0x21]) | |
|<---------------------| |
| | |
| Continue to cast | |
| Multicast traffic | |
|<<====================| |
| | |
AuthGW sets three parameters when communicating with the
authentication server as is described in Chapter A-3 of Appendix 5.
These parameters are described in Appendix 9.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 22]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
B-4. Multicast packets not being delivered to authGW
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| join[0x40] | |
| (PAP join[0x02]) | |
|--------------------->| |
| Query[0x41] | |
| (Ntf Message[0x26]) | |
| (Message[0x11]) | |
|<---------------------| |
| | |
| Continue to cast | |
| Multicast traffic | |
|<<====================| |
| | |
B-5. Network down
client AuthGW RADIUS server
v v v
| Network down | |
| X<<======| |
| Query[0x41] | |
|(Error Message[0x27]) | |
| (Message[0x12]) | |
|<---------------------| |
| | |
If multicast packets are not being transferred to authGW, authGW
indicates this by releasing IGAP Error Message.
C. Process to stop receiving multicast packets for user client
There are two ways of leaving a multicast group: Basic Leave Process
and Fast Leave Process. Basic Leave Process basically equals the
leave process of IGMPv2. When AuthGW receives IGAP Leave message from
the user client, it responds by sending Group-Specific Query to the
user client (described in Chapter 3.1). Details of the Query message
basically follow those of IGMPv2 Membership Query. If authGW doesn't
receive any IGAP Join packets from the user client, it determines
that the user client no longer desires to be a multicast group
member, and stops sending multicast packets.
On the other hand, Fast Leave Process dispenses with IGAP Query
packets. When AuthGW receives IGAP Leave message from the user
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 23]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
client, it stops sending multicast packets without sending IGAP Query
packet. Fast Leave Process is recommended when fast response for IGAP
Leave is needed.
User client should be able to set resend number of IGAP Leave message
and resend interval. These values improve the robustness of IGAP
process, e.g. second leave packet reaches authGW, even if first leave
packet is lost, which ensures completion of the leave process.
In both processes, the decision whether authentication is needed or
not is entrusted to authGW. For simplicity, none of the examples in
this appendix use authentication.
C-1. Success of Basic Leave Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| (No Response) | |
| | |
| Traffic Stop | Accounting |
| X<<======| Request(Stop) |
| |----------------->|
| | Accounting |
| Query[0x41] | Response |
| (Acct Message[0x25]) |<-----------------|
| (Message[0x21]) | |
|<---------------------| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 24]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
C-2. Success of Fast Leave Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Traffic Stop | Accounting |
| X<<======| Request(Stop) |
| |----------------->|
| | Accounting |
| Query[0x41] | Response |
| (Acct Message[0x25]) |<-----------------|
| (Message[0x21]) | |
|<---------------------| |
| | |
C-3. No response (time out) of user client
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| (No Response) | |
| | |
| Traffic Stop | Accounting |
| X<<======| Request(Stop) |
| |----------------->|
| | Accounting |
| Query[0x41] | Response |
| (Acct Message[0x25]) |<-----------------|
| (Message[0x21]) | |
|<---------------------| |
| | |
General-and-Basic Query Interval is described in Chapter B of
Appendix 5. The number of resent Query messages is described in
Appendix 8.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 25]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
C-4. No response (time out) of RADIUS server in Basic Leave Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| (No Response) | |
| | |
| Traffic Stop | Accounting |
| X<<======| Request(Stop) |
| |----------------->|
| Query[0x41] | |
|(Error Message[0x27]) | (No Response) |
| (Message[0x11]) | |
|<---------------------| |
| | |
| Query[0x41] | |
| (Acct Message[0x25]) | |
| (Message[0x21]) | |
|<---------------------| |
| | |
AuthGW sets three parameters when communicating with the
authentication server as is described in Chapter A-3 of Appendix 5.
These parameters are described in Appendix 9.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 26]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
C-5. No response (time out) of RADIUS server in Fast Leave Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Traffic Stop | Accounting |
| X<<======| Request(Stop) |
| |----------------->|
| Query[0x41] | |
|(Error Message[0x27]) | (No Response) |
| (Message[0x11]) | |
|<---------------------| |
| | |
| Query[0x41] | |
| (Acct Message[0x25]) | |
| (Message[0x21]) | |
|<---------------------| |
| | |
AuthGW sets three parameters when communicating with the
authentication server as is described in Chapter A-3 of Appendix 5.
These parameters are described in Appendix 9.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 27]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
C-6. No response (time out) of user client if neither authentication
nor accounting is needed (e.g. Free Channel) in Basic Leave
Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (GS&B Query[0x21]) | |
|<---------------------| |
| (No Response) | |
| | |
| Traffic Stop | |
| X<<======| |
| Query[0x41] | |
| (Ntf Message[0x26]) | |
| (Message[0x12]) | |
|<---------------------| |
| | |
C-7. No response (time out) of user client if neither authentication
nor accounting is needed (e.g. Free Channel) in Fast Leave Process
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Leave[0x42] | |
| (Bsc Leave[0x41]) | |
|--------------------->| |
| Traffic Stop | |
| X<<======| |
| Query[0x41] | |
| (Ntf Message[0x26]) | |
| (Message[0x12]) | |
|<---------------------| |
| | |
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 28]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
C-8. No response (time out) of user client if neither authentication
nor accounting is needed (e.g. Free Channel)
client AuthGW RADIUS server
v v v
| Multicast traffic | |
|<<====================| |
| | |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| Query[0x41] | |
| (G&B Query[0x21]) | |
|<---------------------| |
| (No Response) | |
| | |
| Traffic Stop | |
| X<<======| |
| Query[0x41] | |
| (Ntf Message[0x26]) | |
| (Message[0x12]) | |
|<---------------------| |
| | |
Appendix 6. IGAP sequence with CHAP mechanism
This appendix provides examples of IGAP sequence with CHAP mechanism.
In the figures in this appendix, in addition to IGAP packet types
used in Appendix.5, the following packet type abbreviations are
used.
IGAP Join (Type:0x40)
CHAP Join Challenge Request (Report Type:0x03) : CHAP Join
CHAP Join Response (Report Type:0x04) : CHAP Join Resp
IGAP Membership Query (Type:0x41)
CHAP Challenge (Report Type:0x23) : CHAP Chllng
In the figures in this appendix, the transferred packets have the
following form.
Type Name[Type (No.)]
(Report Type Name [Report Type (No.)])
(Message[(No.)])
This appendix describes only the case of access accept. In the case
of access reject, CHAP process is replaced by PAP process.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 29]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
client AuthGW RADIUS server
v v v
| Join[0x40] *1 | |
| (CHAP Join[0x03]) | |
|--------------------->| |
| | |
| (Making "S") *2 |
| | |
| Query[0x41] *3 | |
| (CHAP Chllng[0x23]) | |
|<---------------------| |
| | |
(A=fMD5(S,PW)) *4 | |
| | |
| Join[0x40] *5 | |
|(CHAP Join Resp[0x04])| |
|--------------------->| |
| | Access |
| | Request *6 |
| |----------------->|
| | (A'=fMD5(S,PW)) *7
| | (A'=A?) *8
| Query[0x41] | Access |
| (Auth Message[0x24]) | Accept *9 |
| (Message[0x11]) |<-----------------|
|<---------------------| |
| Multicast traffic | Accounting |
|<<====================| Request(Start) |
| |----------------->|
| Query[0x41] | Accounting |
| (Acct Message[0x25]) | Response |
| (Message[0x11]) |<-----------------|
|<---------------------| |
| | |
| | |
Explanation of the sequence in the figure
*1 : CHAP Join Challenge Request
User client sends CHAP Join Challenge Request message to authGW.
*2 : Making "S"
AuthGW creates a random digit S.
*3 : CHAP Challenge
AuthGW makes a CHAP ID, and sends CHAP Challenge message to user
client.
*4 : A=fMD5(S, PW)
User client calculates Hash Value A from S and user password using
Hash Function MD5.
*5 : CHAP Join Response
User Client sends CHAP Join Response message to authGW.
*6 : Access Request
AuthGW sends Access Request with A and S to RADIUS server.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 30]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
*7 : A'=fMD5(S, PW)
RADIUS server calculates Hash Value A' from S and user password
configured in RADIUS server using Hash Function MD5.
*8 : A'=A?
If A' equals A, Join request of user is accepted.
*9 : Access Accept
RADIUS server sends Access Accept.
The steps after *9 are the same as in the PAP process.
Appendix 7. RADIUS Attribute
Appendix.5 and 6 provide examples of using the RADIUS server. This
chapter describes the attributes needed. In addition to existing
attributes, defined in RFC2865 and 2866, two attributes are defined
as vendor specific values. They are Auth-Multicast-Address and
Validity-Period. Other details basically follow the specifications of
RFC2865 and 2866.
Auth-Multicast-Address (Type:26, Vendor Type:90)
This value is the desired multicast address as is sent by AuthGW to
RADIUS server. RADIUS server knows the multicast addresses that each
user can receive. If this address is not one of the approved
addresses, Access Reject is sent to authGW.
Validity-Period (Type:26, Vendor Type:93)
RADIUS server sends this attribute to authGW to notify
Validity-Period described in Appendix 8.
Needed attributes are as follows.
(1) Access Request
User-Name (Type:1)
User-Password (Tvpe:2) notice : used with PAP
CHAP-Password (Type:3) notice : used with CHAP
NAS-IP-Address (Type:4)
NAS-Port (Type:5)
Auth-Multicast-Address (Type:26, Vendor Type:90)
CHAP Challenge (Tvpe:60) notice : used with CHAP
(2) Access Accept
User-Name (Type:1)
Auth-Multicast-Address (Type:26, Vendor Type:90)
Validity-period (Type:26, Vendor Type:93)
(3) Access Reject
No attribute is used.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 31]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
(4) Accounting Request (Start)
User-Name (Type:1)
NAS-IP-Address (Type:4)
NAS-Port (Type:5)
Auth-Multicast-Address (Type:26, Vendor Type:90)
Acct-Status-Type (Start) (Tvpe:40)
Acct-Session-ID (Tvpe:44)
(5) Accounting Request (Stop)
User-Name (Type:1)
NAS-IP-Address (Type:4)
NAS-Port (Type:5)
Auth-Multicast-Address (Type:26, Vendor Type:90)
Acct-Status-Type (Stop) (Tvpe:40)
Acct-Output-Octets (Type:43)
Acct-Session-ID (Type:44)
Acct-Session-Time (Type:46)
Acct-Output-Packets (Type:48)
Acct-Terminate-Cause (Type:49)
(6) Accounting Response
No attribute is used.
Appendix 8. Parameters set in authGW and user client when supporting
IGAP
This appendix describes the parameters set in authGW and/or user
client when supporting IGAP processes. "Reference list" details the
chapters that explain the usage of each parameter in the IGAP
process.
8-1. RADIUS Retrying Count
Range : 1~100 (Default : 3)
Implemented : AuthGW
Reference list: A-3, B-3, C-4, C-5
This is the limitation value for the number of user request
(Access Request or Accounting Request) at the same time, when AuthGW
sends the request to RADIUS server. See also chapters 8-2 and 8-3.
8-2. RADIUS Retrying Interval
Range : 1~100 seconds (Default : 5)
Implemented : AuthGW
Reference list: A-3, B-3, C-4, C-5
This is the interval for sending Access Request or Accounting
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 32]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
Request to RADIUS server in units of seconds. See also chapters 8-1
and 8-3.
8-3. RADIUS Waiting Interval
Implemented : AuthGW
Reference list: A-3, B-3, C-4, C-5
This is the product Radius Transmit Count and Radius Retrying
Interval in units of seconds, and used by authGW in determining
whether RADIUS server is alive or not.
8-4. General-and-Basic Query Count
Range : 1~10 (Default 3)
Implemented : AuthGW
Reference list: B-1 ~ B-4, C-3, C-8
This is the limitation value for number of General-and-Basic Query
at the same time, when AuthGW sends it to user client. See the
chapter 8-5, 8-6 and 8-7, too.
8-5. General-and-Basic Query Interval
Range : 1~647 seconds (Default : 125)
Implemented : AuthGW
Reference list: B-1 ~ B-4, C-3, C-8
This is the interval for sending General-and-Basic Query to user
client. See also chapters 8-4, 8-6 and 8-7.
8-6. General-and-Basic Query Max Resp Time
Implemented : AuthGW
Reference list : B-1 ~ B-4, C-3, C-8
This is equal to Max Resp Time in IGAP packet, and used by authGW to
calculate General-and-Basic Query Waiting Interval. See also chapter
8-7.
8-7. General-and-Basic Query Waiting Interval
Implemented : AuthGW
Reference list: B-1 ~ B-4, C-3, C-8
This is calculated as follows.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 33]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
(General-and-Basic Query Waiting Interval) =
(General-and-Basic Query Count) X (General-and-Basic Query Interval)
+ (General-and-Basic Query Max Resp Time)
It's used by authGW to determine whether user clients under authGW
are alive or not. This process is almost same as the IGMPv2
equivalent.
8-8. Group-Specific-and-Basic Query Count
Range : 0~10 seconds (Default : 2)
Implemented : AuthGW
Reference list: C-2, C-5, C-7
This is the limitation value for number of Group-Specific-and-Basic
Query at the same time, when AuthGW sends it to user client. See also
chapters 8-9 and 8-10.
8-9. Group-Specific-and-Basic Query Max Resp Time
Range : 0~100 seconds (Default : 5)
Implemented : AuthGW
Reference list: C-2, C-5, C-7
This is equal to Max Resp Time in IGAP packet, and used by authGW to
determine whether user client participating in a multicast group is
alive or not. See also chapters 8-8 and 8-10.
8-10. Group-Specific-and-Basic Query Waiting Interval
Implemented : AuthGW
Reference list: C-2, C-5, C-7
This is calculated as follows.
It's used by authGW to determine whether user clients under authGW
are alive or not in Basic Leave Process. This process is almost the
same as the IGMPv2 equivalent.
It is calculated as follows.
(Group-Specific-and-Basic Query Waiting Interval) =
(Group-Specific-and-Basic Query Count) X
(Group-Specific-and-Basic Query Max Resp Time)
8-11. Validity Period
Range : 0~10,000 seconds (Default : 0)
Implemented : AuthGW
Reference list: B-1 ~ B-4, C-3, C-8
This is an integer multiple of Query Interval in units of second, and
used by authGW to determine whether user authentication is necessary
or not. See also chapter B of Appendix.5.
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 34]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
8-12. Basic Leave Count
Range : 1~15 (Default 2)
Implemented : user client
Reference list: C-2, C-5, C-7
This is the maximum number of times Basic Leave can be sent to
authGW.
8-13. Join Interval
Range : 0.1~3 (Default 0.1)
Implemented : AuthGW, user client
This is used as the interval authGW waits to receive IGAP Join
message from user client. If authGW receives more than two IGAP Join
messages from the same user client during this interval, it must
discard all Join messages, except the first one. In addition, user
client must not send more than two IGAP Join messages to authGW
during this interval.
8-14. AuthGW Response Waiting Interval
Range : 0~100 (Default 10)
Implemented : AuthGW, user client
This is used as the interval user client waits for IGAP Membership
Query message packet. When user client didn't receive any message
from authGW during this interval, it may determine authGW is dead,
but this determination must not impact the other IGAP processes.
Appendix 9. Configuration of Group Address in authGW
The decision whether authentication is needed or not depends on
desired group address. AuthGW has a list of those group addresses or
subnet addresses associated with each group address. Each group
address or subnet address has a flag indicating the necessity of
authentication. For example, the authGW list may look like this.
239.192.1.0/24 : Auth
239.192.2.0/24 : No-Auth
239.192.3.1 : Auth
239.192.3.2 : No-Auth
Notice : List file should not be a text file.
Flag "Auth" means that authentication is needed, and "No-Auth" means
that authentication is not needed. When authGW receives IGAP Join
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 35]
Internet Draft draft-andou-igmp-auth-01.txt June, 2002
message, if the value in Group Address field is 239.192.1.* (from
239.192.1.0 to 239.192.1.255) or 239.192.3.1, authentication process
(PAP or CHAP) is performed between authGW and authentication server,
for example, using RADIUS server, authGW sends Access Request to
RADIUS server (see Chapter A-1 of Appendix 5).
If the value in Group Address field is 239.192.2.* (from 239.192.2.0
to 239.192.2.255) or 239.192.3.2, the authentication process is not
run, and authGW sends the multicast packets to the user client at
once (see Chapter A-6 of Appendix 5).
If the value in Group Address field is not in the list, e.g.
239.192.4.1, authGW may determine that this value is invalid, at
which point it would send Error Message with 0x41 set in the Message
field to the user client (see Appendix 1 and Chapter A-4 of Appendix
5).
Andou, Sato, Hayashi, Tanabe, Izutsu, Goto, Nishida, Inoue [Page 36]
