< draft-ietf-mip6-radius-04.txt   draft-ietf-mip6-radius-05.txt >
Network Working Group A. Lior Network Working Group A. Lior
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Intended status: Standards Track K. Chowdhury Intended status: Standards Track K. Chowdhury
Expires: August 28, 2008 Starent Networks Expires: January 15, 2009 Starent Networks
H. Tschofenig H. Tschofenig
Siemens Siemens
February 25, 2008 July 14, 2008
RADIUS Mobile IPv6 Support RADIUS Mobile IPv6 Support
draft-ietf-mip6-radius-04.txt draft-ietf-mip6-radius-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines new attributes to facilitate Mobile IPv6 This document defines new attributes to facilitate Mobile IPv6
operationrs using RADIUS infratstructure. The operations include operations using RADIUS infrastructure. The operations include
bootstrapping of information required by the Mobile and the interface bootstrapping of information required by the Mobile Node and the
between the Home Agent and the RADIUS server used to assist MIP6 interface between the Network Access Server, Home Agent and the
operations. RADIUS server used to assist MIP6 operations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. RADIUS Transaction in Integrated Scenario . . . . . . . . 7 3.1. RADIUS Transaction in Integrated Scenario . . . . . . . . 7
3.2. RADIUS Transactions in Split Scenario . . . . . . . . . . 8 3.2. RADIUS Transactions in Split Scenario . . . . . . . . . . 8
4. RADIUS Attribute Overview . . . . . . . . . . . . . . . . . . 11 4. Use of existing RADIUS Attributes . . . . . . . . . . . . . . 11
4.1. MIP6-Feature-Vector . . . . . . . . . . . . . . . . . . . 11 4.1. User-Name . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 11 4.2. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 11 4.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 11
4.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 11 4.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . . . 11
4.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 11 4.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . 11
4.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 12 4.6. Session-Timeout . . . . . . . . . . . . . . . . . . . . . 11
4.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 12 4.7. Message Authenticator . . . . . . . . . . . . . . . . . . 12
4.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 12 5. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 13
4.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 12 5.1. MIP6-Feature-Vector Attribute . . . . . . . . . . . . . . 13
4.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 12 5.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 14
4.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 13 5.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 16
4.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 13 5.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 16
4.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 13 5.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 17
4.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 13 5.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 19
4.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 20
5. Use of existing RADIUS Attributes . . . . . . . . . . . . . . 14 5.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 21
5.1. User-Name . . . . . . . . . . . . . . . . . . . . . . . . 14 5.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 22
5.2. Service-Type . . . . . . . . . . . . . . . . . . . . . . . 14 5.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 22
5.3. NAS-Port-Type . . . . . . . . . . . . . . . . . . . . . . 14 5.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 23
5.4. Calling-Station-Id . . . . . . . . . . . . . . . . . . . . 14 5.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 23
5.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key . . . . . . . 14 5.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 24
5.6. Session-Timeout . . . . . . . . . . . . . . . . . . . . . 14 5.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 25
5.7. Message Authenticator . . . . . . . . . . . . . . . . . . 15 5.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 25
6. RADIUS attributes . . . . . . . . . . . . . . . . . . . . . . 16 6. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. MIP6-Feature-Vector Attribute . . . . . . . . . . . . . . 16 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA) . . . . . . 27
6.2. MIP6-HA Attribute . . . . . . . . . . . . . . . . . . . . 17 6.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 27
6.3. MIP6-HA-FQDN Attribute . . . . . . . . . . . . . . . . . . 18 6.1.2. HA allocation in the ASP (visited network) . . . . . . 29
6.4. MIP6-HL-Prefix Attribute . . . . . . . . . . . . . . . . . 19 6.2. Use of RADIUS In Split Scenario . . . . . . . . . . . . . 29
6.5. MIP6-HOA Attribute . . . . . . . . . . . . . . . . . . . . 20 6.2.1. Split using IKEv2 . . . . . . . . . . . . . . . . . . 29
6.6. MIP6-DNS-MO Attribute . . . . . . . . . . . . . . . . . . 21 6.2.2. Split and Mobile IPv6 Authentication Protocol . . . . 33
6.7. MIP6-Careof-Address . . . . . . . . . . . . . . . . . . . 22 7. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 37
6.8. MIP6-MN-AAA-SPI . . . . . . . . . . . . . . . . . . . . . 23 7.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 37
6.9. MIP6-Authenticator . . . . . . . . . . . . . . . . . . . . 24 7.2. Service Authorization . . . . . . . . . . . . . . . . . . 37
6.10. MIP6-MAC-Mobility-Data . . . . . . . . . . . . . . . . . . 24 7.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 38
6.11. MIP6-Timestamp . . . . . . . . . . . . . . . . . . . . . . 25 7.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 38
6.12. MIP6-MN-HA-SPI . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Provisioning of Configuration Parameters . . . . . . . . . 38
6.13. MIP6-Algorithm-Type . . . . . . . . . . . . . . . . . . . 26 8. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 39
6.14. MIP6-Replay-Mode . . . . . . . . . . . . . . . . . . . . . 26 9. Diameter Considerations . . . . . . . . . . . . . . . . . . . 42
6.15. MIP6-Nonce . . . . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7. Message Flows . . . . . . . . . . . . . . . . . . . . . . . . 29 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
7.1. Use of RADIUS in Integrated Scenario (MSA=ASA) . . . . . . 29 11.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 44
7.1.1. HA allocation in the MSP . . . . . . . . . . . . . . . 29 11.2. New Registry: Mobility Capability . . . . . . . . . . . . 44
7.1.2. HA allocation in the ASP (visited network) . . . . . . 31 11.3. Addition of existing values . . . . . . . . . . . . . . . 44
7.2. Use of RADIUS In Split Scenario (MSA!=ASA) . . . . . . . . 31 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
7.2.1. Mobile Service Provider and Mobile Service 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authorizer are the same entity. . . . . . . . . . . . 31 13.1. Normative References . . . . . . . . . . . . . . . . . . . 46
7.2.2. Mobile Service Provider and Mobile Service 13.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authorizer are different entities. . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
8. Goals for the HA-AAA Interface . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 50
8.1. General Goals . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Service Authorization . . . . . . . . . . . . . . . . . . 35
8.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 36
8.4. MN Authentication . . . . . . . . . . . . . . . . . . . . 36
8.5. Provisioning of Configuration Parameters . . . . . . . . . 36
9. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 37
10. Diameter Considerations . . . . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. Registration of new AVPs . . . . . . . . . . . . . . . . . 42
12.2. New Registry: Mobility Capability . . . . . . . . . . . . 42
12.3. Addition of existing values . . . . . . . . . . . . . . . 42
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.1. Normative References . . . . . . . . . . . . . . . . . . . 44
14.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
This document covers two aspects of MIP6 operations: bootstrapping of This document covers two aspects of MIP6 operations: bootstrapping of
information required by a Mobile IPv6 Mobile using the AAA information required by a Mobile IPv6 Mobile using the AAA
infrastructure and the interaction between the MIPv6 HA and the AAA infrastructure and the interaction between the Network Access
infrastructure. Server(NAS), MIPv6 Home Agent (HA) and the Authentication
Authorization and Accounting (AAA) infrastructure.
Mobile IPv6 specification [10] requires a Mobile Node (MN) to perform Mobile IPv6 specification [14] requires a Mobile Node (MN) to perform
registration with an HA with information about its current point of registration with an HA with information about its current point of
attachment (Care-of Address). The HA creates and maintains binding attachment (Care-of Address). The HA creates and maintains binding
between the MN's HOA and the MN's Care-of Address. between the MN's Home Address (HOA) and the MN's Care-of Address.
In order to register with a HA, the MN needs to know some information In order to register with a HA, the MN needs to know some information
such as, the Home Link prefix, the HA Address, the HOA, the Home Link such as, the Home Link prefix, the HA Address, the HOA, the Home Link
prefix Length and security related information in order to secure the prefix Length and security related information in order to secure the
Binding Update. Binding Update.
The aforementioned set of information may be statically provisioned The aforementioned set of information may be statically provisioned
in the MN. However, static provisioning of this information has its in the MN. However, static provisioning of this information has its
drawbacks. It increases provisioning and network maintenance burden drawbacks. It increases provisioning and network maintenance burden
for the operator. Moreover, static provisioning does not allow load for the operator. Moreover, static provisioning does not allow load
skipping to change at page 4, line 43 skipping to change at page 4, line 44
Dynamic assignment of Mobile IPv6 home registration information is a Dynamic assignment of Mobile IPv6 home registration information is a
desirable feature for ease of deployment and network maintenance. desirable feature for ease of deployment and network maintenance.
For this purpose, the RADIUS infrastructure, which is used for access For this purpose, the RADIUS infrastructure, which is used for access
authentication, can be leveraged to assign some or all of the authentication, can be leveraged to assign some or all of the
necessary parameters. The RADIUS server in the Access Service necessary parameters. The RADIUS server in the Access Service
Provider (ASP) or in the Mobility Service Provider's (MSP) network Provider (ASP) or in the Mobility Service Provider's (MSP) network
may return these parameters to the AAA client. The AAA client might may return these parameters to the AAA client. The AAA client might
either be the NAS, in case of the integrated scenario, or the HA, in either be the NAS, in case of the integrated scenario, or the HA, in
case of the split scenario. The terms integrated and split are case of the split scenario. The terms integrated and split are
described in the terminology section and were introduced in [11]. described in the terminology section and are introduced in [15].
The second aspect of MIP6 and RADIUS interworking is the interaction The second aspect of MIP6 and RADIUS interworking is the interaction
between the HA and the AAA using the RADIUS AAA protocols. From a between the HA and the AAA using the RADIUS AAA protocols. From a
mobility service provider (MSP) perspective, it is important to mobility service provider (MSP) perspective, it is important to
verify that the MN is authenticated and authorized to utilize Mobile verify that the MN is authenticated and authorized to utilize Mobile
IPv6 service and that such services are accounted for. Thus, prior IPv6 service and that such services are accounted for. Thus, prior
to processing the Mobile IPv6 registrations, the HA, participates in to processing the Mobile IPv6 registrations, the HA, participates in
the authentication of the MN to verify the MN's identity. The HA the authentication of the MN to verify the MN's identity. The HA
alsoparticipates in the Mobile IPv6 authorization process involving also participates in the Mobile IPv6 authorization process involving
the RADIUS infrastructure. The HA, due to its role in traffic the RADIUS infrastructure. The HA, due to its role in traffic
forwarding, may also perform accounting for the Mobile IPv6 service forwarding, may also perform accounting for the Mobile IPv6 service
provided to the MN. This document specifies the interaction between provided to the MN. This document specifies the interaction between
the HA and the RADIUS server and aligns with the work done in with the NAS, HA and the RADIUS server and aligns with the work done in
the Diameter specifications described in [12]. with the Diameter specifications described in [16] and [17].
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
General mobility terminology can be found in [13]. The following General mobility terminology can be found in [18]. The following
additional terms, as defined in [11], are used in this document: additional terms, as defined in [15], are used in this document:
Access Service Authorizer (ASA): Access Service Authorizer (ASA):
A network operator that authenticates a mobile node and A network operator that authenticates a mobile node and
establishes the mobile node's authorization to receive Internet establishes the mobile node's authorization to receive Internet
service. service.
Access Service Provider (ASP): Access Service Provider (ASP):
A network operator that provides direct IP packet forwarding to A network operator that provides direct IP packet forwarding to
skipping to change at page 7, line 10 skipping to change at page 7, line 10
Integrated Scenario: Integrated Scenario:
A scenario where the mobility service and the network access A scenario where the mobility service and the network access
service are authorized by the same entity. service are authorized by the same entity.
3. Solution Overview 3. Solution Overview
This document addresses the authentication, authorization and This document addresses the authentication, authorization and
accounting functionality required by MIPv6 bootstrapping and accounting functionality required by MIPv6 bootstrapping and
Authentication as outlined in the MIPv6 bootstrapping problem Authentication as outlined in the MIPv6 bootstrapping problem
statement document (see [11]). As such, the AAA functionality for statement document (see [15]). As such, the AAA functionality for
the integrated and the split scenario needs to be defined. This the integrated and the split scenario needs to be defined. This
requires the ability to offer support for the HA to AAA server and requires the ability to offer support for the HA to AAA server and
the network access server(NAS) to AAA server communication. the network access server(NAS) to AAA server communication.
To highlight the main use cases, we briefly describe the integrated To highlight the main use cases, we briefly describe the integrated
and the split scenarios in Section 3.1 and Section 3.2, respectively. and the split scenarios in Section 3.1 and Section 3.2, respectively.
3.1. RADIUS Transaction in Integrated Scenario 3.1. RADIUS Transaction in Integrated Scenario
In the integrated scenario MIPv6 bootstrapping is provided as part of In the integrated scenario MIPv6 bootstrapping is provided as part of
the network access authentication procedure. Figure 1 shows the the network access authentication procedure. Figure 1 shows the
participating entity. participating entities.
+---------------------------+ +-----------------+ +---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(/MSP) | |Access Service Provider | |ASA/MSA/(/MSP) |
|(Mobility Service Provider)| | | |(Mobility Service Provider)| | |
| | | +-------+ | | | | +-------+ |
| +-------+ | | |Remote | | | +-------+ | | |Remote | |
| |Local | RADIUS | | |RADIUS | | | |Local | RADIUS | | |RADIUS | |
| |RADIUS |-------------------------|Server | | | |RADIUS |-------------------------|Server | |
| |Proxy | | | +-------+ | | |Proxy | | | +-------+ |
| +-------+ | | ^ | | +-------+ | | ^ |
skipping to change at page 8, line 14 skipping to change at page 8, line 14
procedure, the NAS/RADIUS client interacts with the MN. As shown in procedure, the NAS/RADIUS client interacts with the MN. As shown in
Figure 1, the authentication and authorization happens via a RADIUS Figure 1, the authentication and authorization happens via a RADIUS
infrastructure. infrastructure.
At the time of authorizing the user for IPv6 access, the RADIUS At the time of authorizing the user for IPv6 access, the RADIUS
server in the MSA detects that the user is authorized for Mobile IPv6 server in the MSA detects that the user is authorized for Mobile IPv6
access. Based on the MSA's policy, the RADIUS server may allocate access. Based on the MSA's policy, the RADIUS server may allocate
several parameters to the MN for use during the subsequent Mobile several parameters to the MN for use during the subsequent Mobile
IPv6 protocol interaction with the HA. IPv6 protocol interaction with the HA.
Depending on the details of the solution interaction with the DHCPv6 Depending on the details of the solution, interaction with the DHCPv6
server may be required, as described in [2]. server may be required, as described in [2].
3.2. RADIUS Transactions in Split Scenario 3.2. RADIUS Transactions in Split Scenario
In the split scenario, Mobile IPv6 bootstrapping is not provided as In the split scenario, Mobile IPv6 bootstrapping is not performed as
part of the network access authentication procedure. Other RADIUS part of the network access authentication procedure. Other RADIUS
transactions such as authentication and authorization, accounting and transactions such as authentication and authorization, accounting and
parameter configuration for MIP6 service is provided by the HA to parameter configuration for MIP6 service is provided by the HA to
RADIUS transactions. RADIUS transactions.
The Mobile IPv6 RADIUS transaction are executed with the Mobility The Mobile IPv6 RADIUS transaction are executed with the Mobility
Service Provider when desired by the MN. Two variations can be Service Provider when desired by the MN. Two scenarios can be
considered: considered:
1. the MSA and the MSP are the same entity. 1. The MSA and the MSP are the same entity.
2. the MSA and the MSP are different entities. 2. The MSA and the MSP are different entities.
Since scenario (2) is the more generic scenario we show it in Since scenario (2) is the more generic scenario we show it in
Figure 2. Figure 2.
+----------------------+ +----------------------+
| | | |
|Mobility +-------+ | |Mobility +-------+ |
|Service |Remote | | |Service |Remote | |
|Authorizer |RADIUS | | |Authorizer |RADIUS | |
|(MSA) |Server | | |(MSA) |Server | |
skipping to change at page 9, line 31 skipping to change at page 9, line 31
|Node |-------------|RADIUS |-------------- |RADIUS | | |Node |-------------|RADIUS |-------------- |RADIUS | |
| | IKEv2 | |Client | |Proxy | | | | IKEv2 | |Client | |Proxy | |
+-------+ | +-----------+ +-------+ | +-------+ | +-----------+ +-------+ |
+----------------------------------------+ +----------------------------------------+
Figure 2: Mobile IPv6 service access in the split scenario (MSA != Figure 2: Mobile IPv6 service access in the split scenario (MSA !=
MSP) MSP)
As shown in Figure 2 the interaction between the RADIUS client and As shown in Figure 2 the interaction between the RADIUS client and
the RADIUS server is triggered by the protocol interaction between the RADIUS server is triggered by the protocol interaction between
the MN and the HA/RADIUS client using IKEv2 [14] or MIPv6 the MN and the HA/RADIUS client using IKEv2 [19] or MIPv6
Authentication Protocol [3]. The important aspect is, however, that Authentication Protocol [3]. The important aspect is, however, that
for these two approaches several different authentication and key for these two approaches, several different authentication and key
exchange solutions are available. To establish IPsec security exchange solutions are available. To establish IPsec security
associations, protecting of Mobile IPv6 signaling messages IKEv2 is associations for the protection of Mobile IPv6 signaling messages,
used [14]. IKEv2 supports EAP-based authentication, certificates and IKEv2 is used [19]. IKEv2 supports EAP-based authentication,
pre-shared secrets. For protecting using the MIPv6 Authentication certificates and pre-shared secrets. For protection of MObile IPv6
Protocol [3] a mechanism has been designed that is very similar to signaling messages using the MIPv6 Authentication Protocol [3] a
the one used by Mobile IPv4. mechanism has been designed that is very similar to the one used by
Mobile IPv4.
The ability to use different credentials has an impact on the The ability to use different credentials has an impact on the
interaction between the HA (acting as a Diameter client) and the interaction between the HA (acting as a RADIUS client) and the RADIUS
RADIUS Server. For that reason this document illustrates the usage Server. For that reason this document illustrates the usage of these
of these authentication mechanisms with different subsections for: authentication mechanisms with different subsections for:
o IKEv2 usage with EAP o IKEv2 usage with EAP
o IKEv2 usage with certificates and pre-shared secrets o IKEv2 usage with certificates and pre-shared secrets
o MIPv6 Authentication Protocol o MIPv6 Authentication Protocol
For accounting of Mobile IPv6 services provided to the MN, this For accounting of Mobile IPv6 services provided to the MN, this
specification uses the accounting application defined in [4]. specification uses the RADIUS based accounting defined in [4].
Additionally, the MN might instruct the RADIUS server (via the HA) to Additionally, the MN might instruct the RADIUS server (via the HA) to
perform a dynamic DNS update. perform a dynamic DNS update.
4. RADIUS Attribute Overview 4. Use of existing RADIUS Attributes
4.1. MIP6-Feature-Vector
The MIP6-Feature-Vector when included in an Access-Request packet is
used by the NAS or the HA to indicate supported MIP6 features. For
example, a NAS uses this attribute to indicate whether it can provide
a local home agent.
When included in an Access-Accept packet, the MIP6-Feature-Vector is
used by the RADIUS Server to indicate supported MIP6 features and to
select advetized feature by the NAS. For example, if the NAS
indicated support for local home agent assignment, the RADIUS server
authorizes the NAS to support local home agent assignment by echoing
the setting the same flag in the Access-Accept packet.
4.2. MIP6-HA Attribute
In the case of bootstrapping, the RADIUS server may decide to assign
a HA to the MN that is in close proximity to the point of attachment
(e.g., as determined by the NAS-ID). There may be other reasons for
dynamically assigning HAs to the MN, for example to share the traffic
load. The attribute also contains the prefix length so that the MN
can easily infer the Home Link prefix from the HA address.
The MIP-Home-Agent-Address AVP contains the IPv6 address of the Home
Agent. The Home Agent address is the same as in the received BU
message.
4.3. MIP6-HA-FQDN Attribute
The RADIUS server may assign an FQDN of the HA to the MN. The mobile
node can perform DNS query with the FQDN to derive the HA address.
4.4. MIP6-HL-Prefix Attribute
For the same reason as the HA assignment, the RADIUS server may
assign a Home Link that is in close proximity to the point of
attachment (NAS-ID). The MN can perform [10] specific procedures to
discover other information for Mobile IPv6 registration.
4.5. MIP6-HOA Attribute
In the bootstrapping case, the RADIUS server may assign a HOA to the
MN. This allows the network operator to support mobile devices that
are not configured with static addresses. The attribute also
contains the prefix length so that the MN can easily infer the Home
Link prefix from the HA address.
In the case of interaction with the HA, the MIP6-HOA contains the
Home Agent assigned IPv6 Home Address of the Mobile Node.
If the MIP6-HOA AVP contains unspecified IPv6 address (0::0) in a
request message, then the Home Agent expects the RADIUS server to
assign the Home Address in a subsequent reply message. In case the
RADIUS server assigns only a Home Network Prefix to the Mobile Node
the lower 64 bits of the MIP-Mobile-Node-Address AVP provided address
MUST be set to zero.
4.6. MIP6-DNS-MO Attribute
By using this payload the RADIUS client instructs the RADIUS server
to perform a dynamic DNS update. When this payload is included in
the reverse direction, i.e., from the RADIUS server to the RADIUS
client, it informs about the status of the dynamic DNS update. When
the payload is sent from the RADIUS client to the RADIUS server then
the response MUST include the MIP6-DNS-MO attribute.
4.7. MIP6-Careof-Address
The MIP6-Careof-Address contains the IPv6 Care-of Address of the
Mobile Node. The Home Agent extracts this IP address from the
received BU message.
4.8. MIP6-MN-AAA-SPI
The MIP6-MN-AAA-SPI attribute contains an SPI code extracted from the
Mobility Message Authentication Option included in the received BU
message.
4.9. MIP6-Authenticator
The MIP6-Authenticator contains the Authenticator Data from the
received BU message. The Home Agent extracts this data from the MN-
AAA Mobility Message Authentication Option included in the received
BU message and sends it to the RADIUS Server.
The RADIUS server computes its own version of the Authenticator Data
from the received MIP6-MAC-Mobility-Data (see below) and compares it
to the value received in the MIP6-Authenticator from the HA. If the
values match then the Mobile Node is authenticated.
4.10. MIP6-MAC-Mobility-Data
The MIP6-MAC-Mobility-Data contains the calculated MAC_Mobility_Data,
as defined in [3].
4.11. MIP6-Timestamp
The MIP6-Timestamp contains the timestamp value from the Mobility
message replay protection option, defined in [3]. The Home Agent
extracts this value from the received BU message, if available.
The support for replay protection is an optional feature in [3].
When the RADIUS server checks the timestamp provided by the MN via
the HA and recognizes a clock-drift (outside a locally defined replay
protection window) then it MUST initiate the re-synchronization
procedure by returning an Access-Accept packet with Result-Code set
to MIP6-TIMESTAMP-MISMATCH and attaches the MIP6-Timestamp including
it's current time back to the HA.
4.12. MIP6-MN-HA-SPI
The MIP6-MN-HA-SPI is part of a group of attributes used with the
MIPv6 Authentication Protocol. The attributes contains an SPI code
provided by the RADIUS server for the Mobile IPv6 MN-HA.
4.13. MIP6-Algorithm-Type
The MIP6-Algorithm-Type is part of a group of attributes used with
the MIPv6 Authentication protocol and contains Algorithm identifier
for the associated Mobile IPv6 MN-HA Authentication Option. The
Diameter server selects the algorithm type. Existing algorithm types
are defined in RFC 4004 that also fulfill current RFC 4285
requirements.
4.14. MIP6-Replay-Mode
The MIP6-Replay-Mode is part of a group of attributes used with the
MIPv6 Authentication protocol and contains the replay modes as
defined in RFC4004 to be used by the HA.
4.15. MIP6-Nonce
The MIP6-Nonce is part of a group of attributes used with the MIPv6
Authentication protocol and contains the nonce to send to the Mobile.
5. Use of existing RADIUS Attributes
5.1. User-Name 4.1. User-Name
If authentication via IKEv2 is used then the User-Name attribute If authentication via IKEv2 is used then the User-Name attribute
SHALL be set to the IDi payload received in the IKE_AUTH exchange. SHALL be set to the IDi payload received in the IKE_AUTH exchange.
In the case of the Mobile IPv6 Authentication Protocol the User-
Name(1) attribute is set to the value received in the MN-NAI mobility
option as defined in [20].
5.2. Service-Type 4.2. Service-Type
If the HA uses Service-Type(6) is SHALL set its value to "Framed"(2). The HA uses Service-Type(6) to indicate whether the Access-Request
operation is for Authentication and Authorization or just
Authorization.
5.3. NAS-Port-Type 4.3. NAS-Port-Type
In order for the AAA to distingiues the source of the Access-Request In order for the AAA to distinguish the source of the Access-Request
NAS-Port-Type(61) is used as follows: NAS-Port-Type(61) is used as follows:
When the Access-Request originates from an MIP6 HA, NAS-Port-Type When the Access-Request originates from an MIP6 HA, NAS-Port-Type
MUST be included and its value set to HA6(IANA-TBD1). MUST be included and its value set to HA6(IANA-TBD1).
5.4. Calling-Station-Id 4.4. Calling-Station-Id
In the split-scenario, the HA SHOULD use the Calling-Station-Id(31) In the split-scenario, the HA SHOULD use the Calling-Station-Id(31)
to send the MN's COA to the AAA. If used, the string value of the to send the MN's COA to the AAA. If used, the string value of the
Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA. Calling-Station-Id(31) should be set to the 128-bit MN IPv6 COA.
5.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key 4.5. Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key
To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize To transport the MSK from the RADIUS to the HA, RADIUS SHALL utilize
the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. The the MS-MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. The
first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key, first up to 32 octets of the MSK is stored into the MS-MPPE-Recv-Key,
and the next up to 32 octets are stored into the MS-MPPE-Send-Key. and the next up to 32 octets are stored into the MS-MPPE-Send-Key.
The encryption of these attributes is described in [5]. The encryption of these attributes is described in [5].
5.6. Session-Timeout 4.6. Session-Timeout
The use of Session-Timeout attribue during bootstrapping operations The use of Session-Timeout attribute during bootstrapping operations
is covered by various RFC's. is covered by various RFC's.
The use of Session-Timeout attribute during the EAP exchanges between The use of Session-Timeout attribute during the EAP exchanges between
the HA and the RADIUS server are as per [6]. the HA and the RADIUS server are as per [6].
In the case of the RADIUS server sending Session-Timeout to the HA in In the case of the RADIUS server sending Session-Timeout to the HA in
the Access-Accept packet, the HA SHALL use this time as the MIP the Access-Accept packet, the HA SHALL use this time as the MIP
Registration Lifetime. Registration Lifetime.
5.7. Message Authenticator 4.7. Message Authenticator
The use of Message Authenticator is mandated during EAP AAA The use of Message Authenticator is mandated during EAP AAA
procedures by [6]. In the case of the HA sending an Access-Request procedures by [6]. In the case of the HA sending an Access-Request
where EAP is not used, then the HA MUST also include the Message where EAP is not used, then the HA MUST also include the Message
Autheticator attribute in the Access-Request packet. Authenticator attribute in the Access-Request packet.
6. RADIUS attributes 5. RADIUS attributes
This section defines format and syntax for the attribute that carries This section defines format and syntax for the attribute that carries
the Mobile IPv6 parameters that are described in the previous the Mobile IPv6 parameters that are described in the previous
section. section.
The attributes MAY be present in Access-Request, Access-Accept, and The attributes MAY be present in Access-Request, Access-Accept, and
Accounting-Request packets. Accounting-Request packets.
6.1. MIP6-Feature-Vector Attribute 5.1. MIP6-Feature-Vector Attribute
Exactly one of this attribute MUST be sent by the NAS or HA in an Exactly one of this attribute MUST be sent by the NAS or HA in an
Access-Request packet to inidcate support for MIP6. Access-Request packet to inidcate support for MIP6. For example, a
NAS uses this attribute to indicate whether it can provide a local
home agent.
Exactly one of this attribute MUST be sent by the RADIUS server in an Exactly one of this attribute MUST be sent by the RADIUS server in an
Access-Accept packet to indicate support for MIP6 and to select Access-Accept packet to indicate support for MIP6 and to select
features advetized by the NAS or the HA. features advetized by the NAS or the HA. For example, if the NAS
indicated support for local home agent assignment, the RADIUS server
authorizes the NAS to support local home agent assignment by echoing
the setting the same flag in the Access-Accept packet.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MIP6 Features Vectors | | Type | Length | MIP6 Features Vectors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIP6 Features Vectors cont. | | MIP6 Features Vectors cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIP6 Features Vectors cont. | | MIP6 Features Vectors cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 29 skipping to change at page 14, line 34
In a case the Home Agent or the HAAA cannot authorize the In a case the Home Agent or the HAAA cannot authorize the
use of route optimization then the Home Agent will send a use of route optimization then the Home Agent will send a
Binding Acknowledgement with a Status Code set to Binding Acknowledgement with a Status Code set to
ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This
Status Code indicates that the binding registration Status Code indicates that the binding registration
succeeded but the Home Agent will fail all possible succeeded but the Home Agent will fail all possible
subsequent route optimization attempts because of subsequent route optimization attempts because of
subscription or operator policy. subscription or operator policy.
6.2. MIP6-HA Attribute 5.2. MIP6-HA Attribute
One or more of this attribute MAY be sent by the NAS to the RADIUS In the case of bootstrapping, the RADIUS server may decide to assign
server in an Access-Request packet as a proposal by the NAS to a HA to the MN that is in close proximity to the point of attachment
allocate a local HA to the MN. (e.g., as determined by the NAS-ID). There may be other reasons for
dynamically assigning HAs to the MN, for example to share the traffic
load. The attribute also contains the prefix length so that the MN
can easily infer the Home Link prefix from the HA address.
One or more of this attribute MAY be sent by the RADIUS server to the In the case of bootstrapping, one or more of this attribute MAY be
NAS in an Access-Accept packet. The attribute carries the HA address sent by the NAS to the RADIUS server in an Access-Request packet as a
that may be assigned to the MN. proposal by the NAS to allocate a local HA to the MN.
In the case of bootstrapping, one or more of this attribute MAY be
sent by the RADIUS server to the NAS in an Access-Accept packet. The
attribute carries the HA address that may be assigned to the MN.
[EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO [EDITOR: WHAT IS THIS ABOUT?] This attribute MAY be MIP6-DNS-MO
Attribute sent by the NAS to the RADIUS server in an Access-Request Attribute sent by the NAS to the RADIUS server in an Access-Request
packet as a hint to suggest a dynamic HA that may be assigned to the packet as a hint to suggest a dynamic HA that may be assigned to the
MN. The RADIUS server MAY use this value or may ignore this MN. The RADIUS server MAY use this value or may ignore this
suggestion. suggestion.
If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA- If available at the NAS, at least MIP6-HA attribute and/or MIP6-HA-
FQDN SHOULD appear in accounting packets to indicate the identity of FQDN SHOULD appear in accounting packets to indicate the identity of
the serving HA for this session. the serving HA for this session.
One and only one of this attribute SHALL be sent to the RADIUS server In the case of split, the MIP6-HA attribute contains the IPv6 address
by the HA. The value is set to the value of the Home Agent address of the Home Agent as received in the BU message. One and only one of
recieved in the BU. this attribute SHALL be sent by the HA to the RADIUS server.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA | | IPv6 address of assigned HA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. | | IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 44 skipping to change at page 16, line 11
sender, and MUST be ignored by the receiver. sender, and MUST be ignored by the receiver.
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the Home Link. This field indicates the prefix length of the Home Link.
IPv6 address of assigned HA: IPv6 address of assigned HA:
128-bit IPv6 address of the assigned HA. 128-bit IPv6 address of the assigned HA.
6.3. MIP6-HA-FQDN Attribute 5.3. MIP6-HA-FQDN Attribute
One or more instance of this attribute MAY be sent by the NAS to the In the case of bootstrapping, one or more instance of this attribute
RADIUS server in an Access-Request packet as a hint to suggest a MAY be sent by the NAS to the RADIUS server in an Access-Request
dynamic HA that may be assigned to the MN. The RADIUS server MAY use packet as a hint to suggest a dynamic HA that may be assigned to the
this value or may ignore this suggestion. MN. The RADIUS server MAY use this value or may ignore this
suggestion.
One or more of this attribute is sent by the RADIUS server to the NAS In the case of bootstrapping, one or more of this attribute is sent
in an Access-Accept packet. The attribute carries the FQDN of the by the RADIUS server to the NAS in an Access-Accept packet. The
assigned HA. attribute carries the FQDN of the assigned HA. The mobile node can
perform DNS query with the FQDN to derive the HA address.
If available at the NAS, at least MIP6-HA-FQDN attribute and/or If available at the NAS, at least MIP6-HA-FQDN attribute and/or
MIP6-HA SHOULD appear in accounting packets to indicate the identity MIP6-HA SHOULD appear in accounting packets to indicate the identity
of the serving HA for this session. of the serving HA for this session.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | FQDN of the assigned HA ..... | Type | Length | FQDN of the assigned HA .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 27 skipping to change at page 16, line 44
Type: Type:
ASSIGNED-HA-FQDN-TYPE to be defined by IANA. ASSIGNED-HA-FQDN-TYPE to be defined by IANA.
Length: Length:
Variable length. Variable length.
FQDN of the assigned HA: FQDN of the assigned HA:
The data field MUST contain a FQDN as described in [15]. The data field MUST contain a FQDN as described in [21].
6.4. MIP6-HL-Prefix Attribute 5.4. MIP6-HL-Prefix Attribute
This attribute is sent by the RADIUS-MIP server to the NAS in an In the case of bootstrapping, this attribute MAY be sent by the NAS
Access-Accept packet and carries the assigned Home Link prefix. to the RADIUS server in an Access-Request packet along with the
MIP6-HA and/or MIP6-HA-FQDN attribute as a hint to suggest a Home
Link prefix that may be assigned to the MN. The RADIUS server MUST
use this value if it accepts the NAS's HA suggestion.
This attribute MAY be sent by the NAS to the RADIUS server in an In the case of bootstrapping, this attribute is sent by the RADIUS
Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN server to the NAS in an Access-Accept packet and carries the assigned
attribute as a hint to suggest a Home Link prefix that may be Home Link prefix that is in close proximity to the point of
assigned to the MN. The RADIUS server MUST use this value if it attachment (NAS-ID). The MN can perform [14] specific procedures to
accepts the NAS's HA suggestion. discover other information for Mobile IPv6 registration.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Home Link Prefix | | Home Link Prefix |
| | | |
skipping to change at page 20, line 26 skipping to change at page 17, line 44
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the Home Link. This field indicates the prefix length of the Home Link.
Home Link Prefix: Home Link Prefix:
Home Link prefix (upper order bits) of the assigned Home Link Home Link prefix (upper order bits) of the assigned Home Link
where the MN should send binding update. where the MN should send binding update.
6.5. MIP6-HOA Attribute 5.5. MIP6-HOA Attribute
This attribute is sent by the RADIUS server to the NAS in an Access- In the bootstrapping case, this attribute is sent by the RADIUS
Accept packet. The attribute carries the assigned Home IPv6 Address server to the NAS in an Access-Accept packet. The attribute carries
for the MN. the assigned Home IPv6 Address for the MN. This allows the network
operator to support mobile devices that are not configured with
static addresses. The attribute also contains the prefix length so
that the MN can easily infer the Home Link prefix from the HA
address.
This attribute MAY be sent by the NAS to the RADIUS server in an This attribute MAY be sent by the NAS to the RADIUS server in an
Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN Access-Request packet along with the MIP6-HA and/or MIP6-HA-FQDN
attribute as a hint to suggest a Home Address that may be assigned to attribute as a hint to suggest a Home Address that may be assigned to
the MN. The RADIUS server MUST use this value if it accepts the the MN. The RADIUS server MUST use this value if it accepts the
NAS's HA suggestion. NAS's HA suggestion.
In the case of split, in Access-Request packet, the MIP6-HOA contains
the IPv6 Home Address assigned by the HA to the MN. If the MIP6-HOA
AVP contains unspecified IPv6 address (0::0), then the Home Agent
expects the RADIUS server to assign the Home Address in a subsequent
Access-Accept packet. In case the RADIUS server assigns only a Home
Network Prefix to the Mobile Node the lower 64 bits of the MIP-
Mobile-Node-Address AVP provided address MUST be set to zero.
If available at the NAS, this attribute SHOULD appear in the If available at the NAS, this attribute SHOULD appear in the
accounting packets so that the IPv6 addressed used for this session accounting packets so that the IPv6 addressed used for this session
is known in the accounting stream. is known in the accounting stream.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 21, line 25 skipping to change at page 19, line 9
sender, and MUST be ignored by the receiver. sender, and MUST be ignored by the receiver.
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the Home Link. This field indicates the prefix length of the Home Link.
Assigned IPv6 HOA: Assigned IPv6 HOA:
IPv6 HOA that is assigned to the MN. IPv6 HOA that is assigned to the MN.
6.6. MIP6-DNS-MO Attribute 5.6. MIP6-DNS-MO Attribute
The MIP6-DNS-MO attribute is used for triggering a DNS update by the In the case of bootstrapping, the MIP6-DNS-MO attribute is included
RADIUS server and to return the result to the RADIUS client. The by the NAS in an Access-Request packet and MUST set its value to the
request MUST carry the MN's FQDN but the attribute carried in MN's FQDN to indicate to the RADIUS server to perform a dynamic DNS
response to the request MAY not carry a FQDN value. update. Upon receiving this attribute, the RADIUS server SHALL
perform a dynamic update of the DNS and MUST inlcude the MIP6-DNS-MO
attribute in the Access-Accept indicating the result of the dynmaic
DNS update.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved-1 | Status | | Type | Length | Reserved-1 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved-2 | FQDN ... |R| Reserved-2 | FQDN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
DNS-UPDATE-TYPE to be defined by IANA. DNS-UPDATE-TYPE to be defined by IANA.
Length: Length:
Variable length. Variable length.
skipping to change at page 22, line 45 skipping to change at page 20, line 32
Reserved-2: Reserved-2:
Reserved for future use. The bits MUST be set to zero by the Reserved for future use. The bits MUST be set to zero by the
sender, and MUST be ignored by the receiver. sender, and MUST be ignored by the receiver.
FQDN of the MN: FQDN of the MN:
In an Access-Request packet the data field MUST contain a FQDN. In an Access-Request packet the data field MUST contain a FQDN.
In an Access-Accept packet the data field MAY contain an FQDN. In an Access-Accept packet the data field MAY contain an FQDN.
FQDN is described in [15]. FQDN is described in [21].
6.7. MIP6-Careof-Address 5.7. MIP6-Careof-Address
This attribute is available to be sent from the HA to the RADIUS In the case of split, this attribute is sent from the HA to the
Server. The value of the attribute is the IPv6 addresss of the RADIUS Server and contains the IPv6 addresss of the Care-of Address
Care-of Address of the MN extracted from the BU message. of the MN extracted from the BU message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length | | Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| Assigned IPv6 COA | | Assigned IPv6 COA |
| | | |
skipping to change at page 23, line 37 skipping to change at page 21, line 25
sender, and MUST be ignored by the receiver. sender, and MUST be ignored by the receiver.
Prefix-Length: Prefix-Length:
This field indicates the prefix length of the COA Link. This field indicates the prefix length of the COA Link.
Assigned IPv6 COA: Assigned IPv6 COA:
IPv6 COA that is assigned to the MN. IPv6 COA that is assigned to the MN.
6.8. MIP6-MN-AAA-SPI 5.8. MIP6-MN-AAA-SPI
Is available to be sent in an Access-Accept packet from the RADIUS
server to he HA. It is part of a group of attributes used with the
MIPv6 Authentication Protocol and contains the Security Parameter
Index used to reference the MN-HA mobility security association.
This attribute MUST be present in an Access-Request sent from the HA In the case of split, this attribute MUST be present in an Access-
to the RADIUS Server when using MIPv6 Authentication Protocol. Request sent from the HA to the RADIUS Server when using MIPv6
Authentication Protocol. The MIP6-MN-AAA-SPI attribute contains an
SPI code extracted from the Mobility Message Authentication Option
included in the received BU message.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI | | Type | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI cont. | | SPI cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA. ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA.
Length: Length:
6 octets 6 octets
Integer representing a Security Parameter Index. Integer representing a Security Parameter Index.
6.9. MIP6-Authenticator 5.9. MIP6-Authenticator
This attribute is sent from the HA to the RADIUS server and contains In the case of split, this attribute is sent from the HA to the
the Authenticator data from the BU message. The HA extract the data RADIUS server and contains the Authenticator data from the BU
form the MN-AAA Mobility Message Authentication Option if included in message. The HA extract the data form the MN-AAA Mobility Message
the received BU message. Authentication Option if included in the received BU message.
This attribute MUST be present in an Access-Request sent from the HA Upon receiving this attribute from the HA, the RADIUS server computes
to the RADIUS Server when using MIPv6 Authentication Protocol. its own version of the Authenticator Data from the received MIP6-MAC-
Mobility-Data (see below) and compares it to the value received in
the MIP6-Authenticator from the HA. If the values match then the
Mobile Node is authenticated.
In the case of split, this attribute MUST be present in an Access-
Request sent from the HA to the RADIUS Server when using MIPv6
Authentication Protocol.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authenticator Data | | Type | Length | Authenticator Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator Data cont .... | Authenticator Data cont ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA. ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA.
Length: Length:
Variable length Variable length
String. An octetstring representing authenticator data. String. An OctetString representing authenticator data.
6.10. MIP6-MAC-Mobility-Data 5.10. MIP6-MAC-Mobility-Data
Attribute is sent from the HA to the RADIUS Server. The attribute In the case of split, the MIP6-MAC-Mobility-Data attribute is sent
contains the calculated MAC_Mobility_Data as defined in [3]. from the HA to the RADIUS Server. The attribute contains the
calculated MAC_Mobility_Data as defined in [3].
This attribute MUST be present in an Access-Request sent from the HA This attribute MUST be present in an Access-Request sent from the HA
to the RADIUS Server when using MIPv6 Authentication Protocol. to the RADIUS Server when using MIPv6 Authentication Protocol.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MAC Mobility Data | | Type | Length | MAC Mobility Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Mobility Data cont .... | MAC Mobility Data cont ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA. ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA.
Length: Length:
Variable length Variable length
String. An octetstring representing authenticator data. String. An OctetString representing authenticator data.
6.11. MIP6-Timestamp 5.11. MIP6-Timestamp
This attribute is sent from the HA to the RADIUS server when The MIP6-Timestamp contains the timestamp value from the Mobility
performing MIP6 Authentication protocol. The attribute MUST appear message replay protection option, defined in [3]. The Home Agent
in the Access-Request if the attribute is present in the Mobility extracts this value from the received BU message, if available.
message replay protection. Otherwise the attribute MUST NOT appear
in the Access-Request packet.
TBD there is an issue here. In the diameter protocol, if there is a The support for replay protection is an optional feature in [3].
time mismatch we return a result code that states that there was a When the RADIUS server checks the timestamp provided by the MN via
time mistmatch and we return this value. In RADIUS land we return an the HA and recognizes a clock-drift (outside a locally defined replay
Access-Reject but we cant really return any other attributes. protection window) then it MUST initiate the re-synchronization
procedure by returning an Access-Accept packet with Result-Code set
to MIP6-TIMESTAMP-MISMATCH and attaches the MIP6-Timestamp including
it's current time back to the HA.
6.12. MIP6-MN-HA-SPI In the case of split, this attribute is sent from the HA to the
RADIUS server when performing MIP6 Authentication protocol. The
attribute MUST appear in the Access-Request if the attribute is
present in the Mobility message replay protection. Otherwise the
attribute MUST NOT appear in the Access-Request packet.
Is available to be sent in an Access-Accept packet from the RADIUS [EDITOR'S NOTE] there is an issue here. In the diameter protocol, if
server to he HA. It is part of a group of attributes used with the there is a time mismatch we return a result code that states that
MIPv6 Authentication Protocol and contains the Security Parameter there was a time mismatch and we return this value. In RADIUS land
Index used to reference the MN-HA mobility security association. we return an Access-Reject but we cant really return any other
attributes.
5.12. MIP6-MN-HA-SPI
In the case of split, the MIP6-MN-HA-SPI available to be sent in an
Access-Accept packet from the RADIUS server to he HA. It is part of
a group of attributes used with the MIPv6 Authentication Protocol and
contains the Security Parameter Index used to reference the MN-HA
mobility security association.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI | | Type | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI cont. | | SPI cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA. ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA.
Length: Length:
6 octets 6 octets
Integer representing a Security Parameter Index. Integer representing a Security Parameter Index.
6.13. MIP6-Algorithm-Type 5.13. MIP6-Algorithm-Type
Is available to be sent in an Access-Accept packet from the RADIUS In the case of split, the MIP6-Algorithm-Type is available to be sent
server to the HA. It is part of a group of attributes used with the in an Access-Accept packet from the RADIUS server to the HA. It is
MIPv6 Authentication protocol and contains the algorith type. part of a group of attributes used with the MIPv6 Authentication
protocol and contains the algorithm type.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | enumeration | | Type | Length | enumeration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enumeration cont. | | enumeration cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA. ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA.
Length: Length:
6 octets 6 octets
Integer representing an enumeration as supported by [16]: Integer representing an enumeration as supported by [22]:
2: HMAC-SHA-1 [8] 2: HMAC-SHA-1 [8]
6.14. MIP6-Replay-Mode 5.14. MIP6-Replay-Mode
Is available to be sent in an Access-Accept packet from the RADIUS In the case of split, the MIP6-Replay-Mode is available to be sent in
server to the HA. It is part of a group of attribute used with the an Access-Accept packet from the RADIUS server to the HA. It is part
MIPv6 Authentication protocol and contains the replay mode as defined of a group of attribute used with the MIPv6 Authentication protocol
in RFC4004 to be used by the HA. and contains the replay mode as defined in RFC4004 to be used by the
HA.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | enumeration | | Type | Length | enumeration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enumeration cont. | | enumeration cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA. ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA.
Length: Length:
6 octets 6 octets
Integer representing an enumeration as supported by [16]: Integer representing an enumeration as supported by [22]:
1: None. 1: None.
2: Timestamps. 2: Timestamps.
3: Nonces. 3: Nonces.
6.15. MIP6-Nonce 5.15. MIP6-Nonce
Is available to be sent in an Access-Accpet packet from the RADIUS In the case of split, the MIP6-Nonce is available to be sent in an
Server to the HA. It is part of a group of attributes used with the Access-Accept packet from the RADIUS Server to the HA. It is part of
MIPv6 Authentication protocol and contains the nonce to send to the a group of attributes used with the MIPv6 Authentication protocol and
MN. contains the nonce to send to the MN.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nonce | | Type | Length | nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA. ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA.
Length: Length:
Variable length Variable length
String. A binary string repesenting a nonce. String. A binary string representing a nonce.
7. Message Flows 6. Message Flows
7.1. Use of RADIUS in Integrated Scenario (MSA=ASA) 6.1. Use of RADIUS in Integrated Scenario (MSA=ASA)
This section is based on [2] and uses the previously defined RADIUS This section is based on [2] and uses the RADIUS attributes that are
attributes. defined in this document.
7.1.1. HA allocation in the MSP 6.1.1. HA allocation in the MSP
RADIUS is used to authenticate the MN, to authorize it for the RADIUS is used to authenticate the MN, to authorize it for the
mobility service and to send information about the assigned HA to the mobility service and to send information about the assigned HA to the
NAS. NAS.
| |
--------------ASP------>|<--ASA+MSA-- --------------ASP------>|<--ASA+MSA--
| |
+----+ +------+ +-------+ +-------+ +----+ +------+ +-------+ +-------+
| | |RADIUS| | | | | | | |RADIUS| | | | |
skipping to change at page 29, line 48 skipping to change at page 27, line 48
| | 4 | | | | 4 | |
| |------------>| | | |------------>| |
| | | | | | | |
| | 5 | | | | 5 | |
| |<------------| | | |<------------| |
| | | | | | | |
| 6 | | | | 6 | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
HA allocation in the MSP Figure 3: HA allocation in the MSP
In step (1), the MN executes the normal network access authentication In step (1), the MN executes the network access authentication
procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS procedure (e.g., IEEE 802.11i/802.1x, PANA) with the NAS. The NAS
acts as an authenticator in "pass-through" mode, i.e., the endpoint acts as an authenticator in "pass-through" mode, i.e., the endpoint
of the authentication dialogue is the MN's home RADIUS server. This of the authentication dialogue is the MN's home RADIUS server. This
is the typical scenario in case the messages involved in the is the typical scenario in case the messages involved in the
authentication protocol are transported in EAP. authentication protocol are transported in EAP.
As per [6], the NAS encapsulates/decapsulates EAP packets into/from As per [6], the NAS encapsulates/de-capsulates EAP packets into/from
RADIUS packets until an Access-Response (either an Access-Accept or RADIUS packets until an Access-Response (either an Access-Accept or
an Access/Reject packet is received by the NAS). This concludes the an Access/Reject packet is received by the NAS). This concludes the
network access authentication phase. network access authentication phase.
If the NAS has the ability to support MIP6 Bootstrapping it includes If the NAS has the ability to support MIP6 Bootstrapping it includes
the MIP6-Feature-Vector in the first Access-Request message and the MIP6-Feature-Vector in the first Access-Request message and
indicates whether it supports MIP6 bootstrapping and/or local home indicates whether it supports MIP6 bootstrapping and/or local home
agent assignment by setting the appropriate flags therein. agent assignment by setting the appropriate flags therein.
If the NAS indicates support for Local home agent assignment, then it If the NAS indicates support for local home agent assignment, then it
may also include the MIP6-HA Attribute(s) and/or MIP6-HA-FQDN may also include the MIP6-HA attribute(s) and/or MIP6-HA-FQDN
Attribute(s) as a proposal to the RADIUS server of the HA to assign attribute(s) as a proposal to the RADIUS server to indicate that the
in the ASP. HA is to be assigned in the ASP.
In step (2), the RADIUS server sends an Access-Accept packet with the In step (2), the RADIUS server sends an Access-Accept packet with the
MIP6-Feature-Vector with the Local Home Agent Assignment flag set or MIP6-Feature-Vector with the Local Home Agent Assignment flag set or
cleared. If the flag is cleared then the RADIUS server needs to cleared. If the flag is cleared then the RADIUS server needs to
provide one or more Home Agent(s) to be assigned to the MN. If the provide one or more Home Agent(s) to be assigned to the MN. If the
flag is set, then it indicates to the NAS that it can assign HA to flag is set, then it indicates to the NAS that it can assign HA to
the MN; the RADIUS server may also include one or mroe HA addresses the MN; the RADIUS server may also include one or more HA addresses
thus indicating that the NAS can either allocate a local HA or one thus indicating that the NAS can either allocate a local HA or one
specified by the RADIUS server. specified by the RADIUS server.
In step (3) the MN sends a DHCPv6 Information Request message to In step (3) the MN performs home information discovery procedures as
all_DHCP_Relay_Agents_and_Servers. In the OPTION_ORO, Option Code specified in [DHCPv6 for Home Info Discovery in MIPv6][hiopt]. The
for the Home Network Identifier Option shall be included in that MN sends a DHCPv6 Information-request message including the Home
message. The Home Network Identifier Option should have id-type of Network Information option according to the stateless DHCPv6
1, the message is a request to discover home network information that procedures [23] and [24]. The MN MUST also include the Option code
pertains to the given realm, i.e., the user's home domain (identified for the Home Network Information option in the Option Request option
by the NAI of the MN). The OPTION_CLIENTID is set by the MN to in the request. The id-type of the Home Network Identifier Option is
identify itself to the DHCP server. set to 1 indicating that the MN is requesting to discover the home
network information that pertains to the given realm, i.e., the
user's home domain (identified by the NAI of the MN). The
OPTION_CLIENTID is set by the MN to identify itself to the DHCP
server.
In step (4) the DHCP relay agent forwards this request to the DHCP In step (4) the DHCP relay agent forwards this request to the DHCP
server. The OPTION_MIP6-RELAY-Option is included in this forwarded server. The OPTION_MIP6-RELAY-Option is included in this forwarded
message. This option carries the RADIUS MIP6-HA Attribute from the message. This option carries the RADIUS MIP6-HA attribute received
Access-Accept packet. If the NAS recieved the MIP6-HA-FQDN in the in the Access-Accept packet.
Access-Accept it peforms a DNS lookup to resolve the MIP6-HA address.
In step (5), the DHCP server identifies the client (by DUID) and In step (5), the DHCP server identifies the client (by DUID) and
finds out that it requests HA information in the MSP (by the Home finds out that it requests HA information in the MSP (by the Home
Network Identifier Option = 1). The DHCP server extracts the HA Network Identifier Option = 1). The DHCP server extracts the HA
address from OPTION_MIP6-RELAY-Option and places it into Home Network address from OPTION_MIP6-RELAY-Option and places it into Home Network
Information Option in the Reply message. Information Option in the Reply message.
In step (6), the Relay Agent forwards the Reply Message to the MN. In step (6), the Relay Agent forwards the Reply Message to the MN.
On reception of this message, the HA address or the FQDN of the HA is On reception of this message, the HA address or the FQDN of the HA is
available at the MN. available at the MN.
7.1.2. HA allocation in the ASP (visited network) 6.1.2. HA allocation in the ASP (visited network)
This scenario is similar to the one described in Section 6.1.1. The This scenario is similar to the one described in Section 7.1.1. The
difference is in step (4), where the type-id field in the Home difference is in step (4), where the type-id field in the Home
Network Identifier Option is set to zero, indicating that a HA is Network Identifier Option is set to zero, indicating that a HA is
requested in the ASP instead of in the MSP. Thus, the information requested in the ASP instead of in the MSP. Thus, the information
received by the home RADIUS server, via the DHCP relay, in the received by the home RADIUS server, via the DHCP relay, in the
OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP
server allocates a HA from its list of possible HAs and returns it in server allocates a HA from its list of possible HAs and returns it in
the Reply message (Home Network Information Option). the Reply message (Home Network Information Option).
7.2. Use of RADIUS In Split Scenario (MSA!=ASA) 6.2. Use of RADIUS In Split Scenario
7.2.1. Mobile Service Provider and Mobile Service Authorizer are the In this section we present the call flows used in the Split scenario.
same entity. In the Split scenario the MN can be authenticated and authorized for
Mobile IPv6 by using IKEv2 or the Mobile IPv6 Authentication Protocol
[3]. The authentication and or authorization takes place between the
HA and the RADIUS server.
The assumption in this scenario is that the MN has the domain name of 6.2.1. Split using IKEv2
the MSP preconfigured.
In this scenario there is no relationship between the network access This section describes IKEv2 based authentication and authorization
authentication procedure and the MIPv6 bootstrapping procedure. for the SPLIT scenario using IKEv2 and EAP and IKEv2 with
Certificates and Preshared Keys.
In order to learn the IP address of the HA, the MN either performs a 6.2.1.1. IKEv2 and EAP
DNS lookup of the HA Name or a DNS lookup by service name. In the
first case, the MN is preconfigured with the FQDN of the HA, and thus
sends a DNS request, where QNAME = name of HA, QTYPE='AAAA' (request
for IPv6 address of HA). A DNS reply message is returned by the DNS
server with the HA address.
The MN then runs IKEv2 [17] with the HA in order to set up IPsec SAs The use of IKEv2 with EAP between the MN and the HA allows the AAA to
(MN-HA). As part of this,the MN authenticates itself to the RADIUS authenticate the MN. When EAP is used with IKEv2, the RADIUS EAP
server in the MSA domain, and obtains authorization for mobility procedures, as defined in [6], are used. EAP methods that do not
service (including the Home Address). establish a shared key SHOULD NOT be used, as they are subject to a
number of man-in-the-middle attacks as stated in Section 2.16 and
Section 5 of RFC 4306 [25]. Attributes specific to Mobile IPv6
bootstrapping are added to the AAA packets.
The MN shares credentials with the RADIUS server in the MSA domain. Figure 4 shows the message flow involved during the authentication
The RADIUS communication between the HA and the this RADIUS server is phase when EAP is used.
also secured by RADIUS-specific mechanisms (e.g., IPsec). Using EAP
within IKEv2 [17], the MN is authenticated and authorized for the
IPv6 mobility service and is also assigned a HOA.
The setup of SAs and mutual authentication between MN and AAAH using ----------------------------ASP--------->|<-----MSA/MSP
RADIUS (and EAP) is similar to the one described for Diameter
protocol in [12]. The described mechanism ensureas that common
keying material will be available at the MN and HA after successful
completion.
----------------------------ASP--------->|<-----MSA/MSP +----+ IKEv2 +----+ RADIUS (EAP) +--------------------+
| MN |<----------->| HA |<-------------------->| Home RADIUS Server |
+----+ +----+ +--------------------+
+----+ IKEv2 +----+ RADIUS (EAP) +--------------------+ Mobile Home RADIUS
| MN |<----------->| HA |<-------------------->|Remote RADIUS Server| Node Agent Server
+----+ +----+ +--------------------+ | | |
| HDR, SAi1, KEi, Ni (1) | |
|-------------------------------->| |
| | |
| HDR, SAr1, KEr, Nr, [CERTREQ](2)| |
|<--------------------------------| |
| | |
| HDR, SK{IDi,[CERTREQ,] [IDr,] | |
| [CP(CFG_REQUEST),] | |
| SAi2, TSi, TSr} (3) | |
|-------------------------------->| Access-Request |
| | (EAP-Response) (4) |
| |-------------------------->|
| | |
| | Access-Challenge |
| | (EAP-Request) (5) |
| HDR, SK{IDr, [CERT,] AUTH, EAP} |<--------------------------|
|<------------------------------- | |
| | |
| HDR, SK{EAP} | |
|-------------------------------->|Access-Request(EAP-Res.) |
| |-------------------------->|
| | |
| |Access-Challenge(EAP-Req.) |
| HDR, SK{EAP-Request} |<--------------------------|
|<--------------------------------| |
| | |
| HDR, SK{EAP-Response} | |
|-------------------------------->|Access-Request (EAP-Res.) |
| |-------------------------->|
| ... | ... |
| | |
| |Access-Accept(EAP-Success) |
| (6)|<--------------------------|
| HDR, SK{EAP-Success} | |
|<--------------------------------| |
| | |
| HDR, SK{AUTH} | |
|-------------------------------->| |
| | |
| HDR, SK{AUTH, [CP(CFG_REPLY,] | |
| SAr2, TSi, TSr} | |
|<--------------------------------| |
| | |
MN HA Remote RADIUS server Figure 4: Split Scenario Exchange Using IKEv2 and EAP
-- -- --------------------
IKE_SA_INIT
<------------------------------>
HDR, SK{IDi,[CERTREQ,] [IDr,] Before this scenario started the MN has to know the IP address of the
SAi2, TSi, TSr} HA to use. The MN may be configured with the HA-IP address or the
-------------------------------> FQDN of the HA to use or with a mobility service name. In the case
RADIUS Access-Request(EAP-Response) where the MN is configured with the domain name of the HA or a
----------------------------------> mobility service name, it uses DNS to resolve the IP address of the
RADIUS Access-Challenge(EAP-Request) HA to use. Alternatively, MN could have received the information by
<----------------------------------- performing a DHCP request as per [26]
HDR, SK {IDr, [CERT,] AUTH,
EAP }
<-------------------------------
HDR, SK {EAP}
-------------------------------->
RADIUS Access-Request(EAP-Response)
---------------------------------->
RADIUS Access-Challenge(EAP-Request)
<-----------------------------------
HDR, SK{EAP-Request}
<-------------------------------
HDR, SK{EAP-Response}
-------------------------------->
RADIUS Access-Request(EAP-Response)
---------------------------------->
... ...
RADIUS Access-Accept(EAP-Success) The MN and the HA start the interaction with an IKE_SA_INIT
<------------------------ exchange(1)(2). In this phase cryptographic algorithms are
negotiated, nonces and Diffie-Hellman parameters are exchanged.
HDR, SK{EAP-Success} Exchange (3) starts the IKE_AUTH phase. This second phase of IKEv2
<------------------------------- authenticates the previous messages, exchanges identities and
HDR, SK{AUTH} certificates and establishes the first CHILD_SA. It is used to
-------------------------------> mutually authenticate the MN (acting as an IKEv2 Initiator) and the
HDR, SK {AUTH, SAr2, TSi, TSr } HA (acting as an IKEv2 Responder). The identity of the user/MN is
<------------------------------- provided in the IDi field. The MN indicates its willingness to be
authenticated via EAP by omitting the AUTH field in message (3) (see
Section 2.16 of [25]).
Split Scenario Exchange As part of the authentication process, the MN MAY request a Home-
Address, a Home Prefix or suggests one, see [27], using a CFG_REQUEST
payload in the exchange(3).
MN and HA start with an IKE_SA_INIT to setup the IKE SA (messages The HA extracts the IDi field from exchange (3) and sends a RADIUS
defined in the IKEv2 specification [17], negotiating crypto Access-Request packet(4) towards the authenticating RADIUS server.
algorithms and running DH key exchange). IKEv2 supports integration The User-Name(1) attribute is set to the value received in the IDi
with EAP. The MN indicates its desire to use EAP by not including field and the EAP-Payload attribute contains a EAP-Response/ Identity
the AUTH payload in the third message. However, it indicates its with the identity extracted from the IDi field. The Access-Request
identity (NAI) by using the IDi field. If the HA supports EAP for packet is integrity protected by the Message-Authenticator(89)
authentication, as per [6] it forwards the identity to the Remote attribute.
RADIUS server by sending a RADIUS Access-Request packet containing
the identity in the EAP-Payload AVP and in the RADIUS User-Name
attribute. Based on this identity, the Remote RADIUS server chooses
authentication method and sends the first EAP-Request in the RADIUS
Access-Challenge packet. During the EAP authentication phase, the HA
relays EAP packets between the MN and the Remote RADIUS server. If
the authentication succeeds and if the MN is authorized to use Mobile
IPv6 service, the Remote RADIUS server sends a RADIUS Access-Accept
packet containing the EAP-Success and the AAA-Key derived from the
EAP authentication method. EAP authentication methods that do not
derive keys are not recommended. This key is used by both MN and HA
to generate the AUTH payload. In subsequent messages, MN and HA
setup IPsec SAs for Mobile IPv6.
7.2.2. Mobile Service Provider and Mobile Service Authorizer are This message is routed to the MN's home RADIUS server/EAP server.
different entities. The RADIUS server selects the EAP method and replies with the RADIUS
Access-Challenge packet(5). Depending on the type of EAP method
chosen, a number of Access-Request and Access-Challenge exchanges are
conducted to execute the EAP method between the MN and the RADIUS
server/EAP server.
The HA address discovery is performed as described in Section 6.2.1. At the end of the EAP authentication phase, the RADIUS server
indicates the result of the authentication by either sending an
Access-Accept packet(6) containing EAP-Success or an Access-Reject
packet containing EAP-Reject. The last IKEv2 message sent by the HA
contains the Home Address or the Home Prefix. In the latter case, a
CREATE_CHILD_SA exchange is necessary to setup IPSec SAs for Mobile
IPv6 signaling.
In some deployment scenarios, the HA may also acts as a IKEv2
Responder for IPSec VPN access. A problem in this case is that the
IKEv2 responder may not know if IKEv2 is used for Mobile IPv6 service
or for IPSec VPN access service. A network operator needs to be
aware of this limitation. The MN may provide a hint of the intended
service, for example, by using different identities in the IKE_AUTH
message for the IPSec VPN service and Mobile IPv6 service. However,
the use of different identities during the IKEv2 negotiation is
deployment specific. Another possibility is to make the distinction
on the MN subscription basis. In this case the RADIUS server can
inform the HA during the IKEv2 negotiation whether the MN is
provisioned with an IPSec VPN access service or Mobile IPv6 service.
+----+ IKEv2 +----+ RADIUS (EAP)+------+ RADIUS(EAP)+------+ Eventually, when the HA receives a Binding Update (BU), the HA
| MN |<----------> | HA |<----------->|Local |<---------->|Remote| authenticates and authorizes the MN. It is RECOMMENDED that the HA
+----+ +----+ |RADIUS| |RADIUS| sends a RADIUS accounting request message every time it receives a
|Proxy | |Server| BU. Alternatively, if the HA does not support RADIUS Accounting, it
+------+ +------+ SHOULD send a User-Session-Notification packet as defined in [9] to
inform the AAA server that the mobile ip session has termianted.
MSP#MSA Exchange 6.2.1.2. IKEv2 and Certificates
The scenario is similar to previously described scenarios with the When IKEv2 is used with certificate-based authentication, the HA
difference of utilizing AAA roaming agreements between the MSP and performs the authentication of the MN based on the received
the MSA. certificate. The RADIUS server is used to authorize the MN for the
Mobile IPv6 service. The IDi payload extracted from the IKE_AUTH
message MUST correspond to the identity in the MN's certificate.
This identity is then used by the HA to populate the User-Name(1)
attribute in the succeeding Access-Request packet. The Service-
Type(6) attribute is set to Authorize-Only and the RADIUS packet MUST
be protected with the Message-Authenticator(89) attribute. Further
PKI-related procedures such as certificate revocation checking are
out of scope of this document.
8. Goals for the HA-AAA Interface EDITOR's note: we have to differentiate the CERT case from the PSK
case to the AAA.
6.2.1.3. IKEv2 and Preshared Keys
When IKEv2 is used with PSK-based initiator authentication, RADIUS is
used to obtain the Pre-shared Key and authorize the MN for the Mobile
IPv6 service. The IDi payload extracted from the IKE_AUTH message
has to contain an identity that is meaningful for the RADIUS
infrastructure, such as a Network Access Identifier (NAI), and is
then used by the HA to populate the User-Name(1) attribute in the
Access-Request packet. The Service-Type(6) is set to Authorize-Only.
The HA includes TBD attribute that when present in an Access-Request
packet acts as a hint to the RADIUS server that it MUST provide the
Pre-Shared-Key in the Access-Accept packet. The Access-Request
packet MUST be integrity protected by the Message-Authenticator(89)
attribute.
Upon receiving the Access-Request packet the RADIUS server replies
with an Access-Accept or an Access-Reject if the MN is not authorized
for MIP6 service. In the case of Access-Accept, if the RADIUS server
received the TBD attribute (in the Access-Request) it SHALL include
the Pre-Shared Key associated with the NAI received in the User-
Name(1) attribute. The Pre-Shared key is delivered using the MS-
MPPE-Recv-Key and the MS-MPPE-Send-Key as defined in [5]. This
attribute must be encrypted using the procedures defined in section
3.5 of [10]. The Access-Accept MUST be integrity protected using
Message-Authenticator(89) attribute. The Access-Accept packet may
contain other MIP6 authorization attributes.
EDITOR's note: The preshared key as defined in IKEv2 should not be
delivered raw to the HA. Instead it should be hashed as defined in
IKEv2: prf(Shared Secret,"Key Pad for IKEv2") section 2.15. To have
the AAA server do this, the AAA server must be told what prf function
to use. This can be achieved by sending the PRF function in the
Access-Request. Recall the previous editor's note we need a hint to
tell the AAA to fetch the key. This could be the hint.
6.2.2. Split and Mobile IPv6 Authentication Protocol
Figure 5 shows the message sequence between the MN, the HA and the
RADIUS server during the registration when Mobile IPv6 Authentication
Protocol is used. A BU and a Binding Acknowledgement (BA) messages
are used in the binding registration process.
Receiving a BU at the HA initiates a MIP6-Request to be sent to the
RADIUS server. The RADIUS server in turn responds with an Access-
Accept or an Access-Reject. The HA may assign a Home Address to the
MN and provide it to the Diameter server in the MIP6-HOA attribute.
According to [3] the MN uses the Mobile Node Identifier Option,
specifically the MN-NAI mobility option (as defined in [20]) to
identify itself. The HA MUST copy the MN-NAI mobility option value
to the User-Name(1) attribute in the Access-Request packet.
The procedure described in this specification for the Mobile IPv6
Authentication Protocol is only needed for the initial BU received by
the HA. When the HA receives subsequent BUs, they are processed
locally in the HA using the MN-HA key received from the AAA. It is
RECOMMENDED that the HA sends an accounting request packet or a User-
Session-Notification packet as defined in [9] every time it receives
a Binding Update. However, the HA MAY re-authorize the MN with the
RADIUS server at any time depending on the deployment and the local
policy.
In the case where the BU contains the MN-AAA Mobile Message
Authentication Option, the HA extracts the Mobility SPI from the
Mobility Message Authentication Option and sends it to the RADIUS
server in the MIP6-MN-AAA-SPI attribute. The HA also extract the
Authentication Data from the Message Authentication Option and
includes it in the Access-Request in the MIP6-Authenticator
attribute. If the Mobility SPI has the well-know value HMAC-SHA1_SPI
(see section 8 of [3]), then the hash_fn() is HMAC_SHA1. When
HMAC_SHA1 is used, the BU is authenticate by the AAA using HMAC_SHA1
authenticaiton. In that case, MAC_Mobility Data is calcualted by the
HA as per [3] and included in the Access-Request packet in the MIP6-
MAC-Mobility-Data attribute. The MIP6-Timestamp attribute is set to
the value contained in the mobility message prelay protection option
defined in [3] if available. If the MN-HA Authentication Option is
included in the BU, the HA extract the SPI value and includes it in
the Access-Request packet in the MIP6-MN-HA-SPI attribute.
Upon receiving the Access-Request packet the RADIUS server uses the
User-Name(1) attribute and the MIP6-MN-AAA-SPI attribute to fetch the
AAA-KEY. The RADIUS server then uses that key and the data received
in the MIP6-MAC-Mobility-Data attribute to compute its own version of
the authentication data. The MN is authenticated if the
authentication data computed matches the authentication data received
in the Access-Request in the MIP6-Authenticator attribute.
If the MN is authenticated and is authorized for MIP6 service, the
RADIUS server responds back with an Access-Accpet otherwise it
responds with an Access-Reject. In the case of Access-Accept and if
the MIP6-MN-HA-SPI value was inclued in the Access-Request packet,
the RADIUS server includes the MN-HA security association parameters
associated with the MN-HA SPI and the NAI received in the User-Name
attributes in the MS-MPPE-Recv-Key, MS-MPPE-Send-Key, MIP6-Algorithm-
Type, MIP6-Replay-Mode, MIP6-Nonce. The MS-MPPE-Recv-Key, MS-MPPE-
Send-Key must be encrypted using the procedures defined in section
3.3 of [10]. The RADIUS Access-Accept packet MUST be integrity
protected using Message-Authenticator(89) attribute.
If the RADIUS server detected a replay attack when checking the MIP6-
Timesampt received in the Access-Request fromt he HA. The RADIUS
server SHAL respond back with an Access-Reject.
In some architectures and network deployments the MN-HA security
associations may be established as a result of a successful network
access authentication. In such deployments, both MN and RADIUS
server share the keying material required for computation and
validation of the MN-HA Authentication Option, and a Security
Parameter Index (SPI) for indexing an appropriate security
association. Upon receiving a BU with only a MN-HA Authentication
Option, the HA retrieves the keying material required for the
computation and validation of the MN-HA Authentication Option from
the RADIUS server. The RADIUS request packet sent by the HA MUST
contain the Service-Type(6) attribute set to "Authorize-Only" and the
MIP6-MN-HA-SPI set to the value of the SPI in the MN-HA
Authentication Option. The RADIUS server uses the NAI and the SPI
value to locate the matching security association for the MN-HA and
return correct keying material back to the HA in the MS-MPPE-Recv-
Key, MS-MPPE-Send-Key. The returned keying material MUST be
encrypted using the procedure defined in section 3.3 [10]. The
RADIUS Access-Accept packet MUST be integrity protected using
Message-Authenticator(89) attribute.
Mobile Home Diameter
Node Agent Server
| | |
| | |
| Binding Update |RADIUS Access-Request|
|------------------------------------>|-------------------->|
| (Mobile Node Identifier Option, | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | |
| | |
| Binding Acknowledgement |RADIUS Access-Accept |
| |or Access-Reject |
|<------------------------------------|<--------------------|
| (Mobile Node Identifier Option | |
| Mobility Message Replay Protection | |
| Option, Authentication Option) | |
| | Acct-Request(start) |
| |-------------------->|
Figure 5: Mobile IPv6 Bootstrapping using the Mobile IPv6
Authentication Protocol
7. Goals for the HA-AAA Interface
Here, we follow the classification and labels listed in the MIPv6- Here, we follow the classification and labels listed in the MIPv6-
AAA-Goals document [18]. AAA-Goals document [28].
8.1. General Goals 7.1. General Goals
G1.1-G1.4 Security G1.1-G1.4 Security
These are standard requirements for a AAA protocol - mutual These are standard requirements for a AAA protocol - mutual
authentication, integrity, replay protection, confidentiality. IPsec authentication, integrity, replay protection, confidentiality. IPsec
can be used to achieve the goals. Goal G1.5 regarding inactive peer can be used to achieve the goals. Goal G1.5 regarding inactive peer
detection needs further investigations since heartbeat messages do detection needs further investigations since heartbeat messages do
not exist (like in the Diameter case, Watch-Dog-Request/Answer). not exist (like in the Diameter case, Watch-Dog-Request/Answer).
8.2. Service Authorization 7.2. Service Authorization
G2.1. The AAA-HA interface should allow the use of Network Access G2.1. The AAA-HA interface should allow the use of Network Access
Identifier (NAI) to identify the MN. The User-Name attribute can be Identifier (NAI) to identify the MN. The User-Name attribute can be
used for the purpose to carry the NAI. used for the purpose to carry the NAI.
G2.2 The HA should be able to query the AAAH server to verify Mobile G2.2 The HA should be able to query the AAAH server to verify Mobile
IPv6 service authorization for the MN. Any node implementing RADIUS IPv6 service authorization for the MN. Any node implementing RADIUS
functionality[9] can possibly initiate a request message. In functionality[11] can possibly initiate a request message. In
combination with the ability of the RADIUS protocol to carry EAP combination with the ability of the RADIUS protocol to carry EAP
messages [6] , our solution will enable an HA to query a RADIUS messages [6] , our solution will enable an HA to query a RADIUS
server and verify MIPv6 authorization for the MN. server and verify MIPv6 authorization for the MN.
G2.3 The AAAH server should be able to enforce explicit operational G2.3 The AAAH server should be able to enforce explicit operational
limitations and authorization restrictions on the HA (e.g., packet limitations and authorization restrictions on the HA (e.g., packet
filters, QoS parameters). Work in progress in the area, including filters, QoS parameters). Work in progress in the area, including
NAS-Filter-Rule, RADIUS quality of service support, prepaid NAS-Filter-Rule, RADIUS quality of service support, prepaid
extensions etc. is performed. The relevant attributes may be reused extensions etc. is performed. The relevant attributes may be reused
for providing required functionality over the AAAH-HA interface. for providing required functionality over the AAAH-HA interface.
skipping to change at page 36, line 9 skipping to change at page 38, line 9
reauthorize the user, the Termination-Action attribute can be reauthorize the user, the Termination-Action attribute can be
included, with value 1, meaning the NAS should send a new RADIUS- included, with value 1, meaning the NAS should send a new RADIUS-
Request packet. Additional AVPs for dealing with pre-paid sessions Request packet. Additional AVPs for dealing with pre-paid sessions
(e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are (e.g,. volume, resource used--VolumeQuota AVP, ResourceQuota AVP) are
specified in RADIUS prepaid extension. Exchanging of application specified in RADIUS prepaid extension. Exchanging of application
specific authorization request/answer messages provides extension of specific authorization request/answer messages provides extension of
the authorization session (e.g., Authorize Only Access-Request sent the authorization session (e.g., Authorize Only Access-Request sent
by the HA (NAS) to the RADIUS server). Initiation of the re- by the HA (NAS) to the RADIUS server). Initiation of the re-
authorization by both sides could be supported. Both sides could authorization by both sides could be supported. Both sides could
initiate session termination - the RADIUS server by sending initiate session termination - the RADIUS server by sending
Disconnect message [19]. Disconnect message [29].
8.3. Accounting 7.3. Accounting
G3.1 The AAA-HA interface must support the transfer of accounting G3.1 The AAA-HA interface must support the transfer of accounting
records needed for service control and charging. These include (but records needed for service control and charging. These include (but
may not be limited to): time of binding cache entry creation and may not be limited to): time of binding cache entry creation and
deletion, octets sent and received by the MN in bi-directional deletion, octets sent and received by the MN in bi-directional
tunneling, etc. tunneling, etc.
The requirements for accounting over the AAAH-HA interface does not The requirements for accounting over the AAAH-HA interface does not
require enhancements to the existing accounting functionality. require enhancements to the existing accounting functionality.
8.4. MN Authentication 7.4. MN Authentication
G4.1 The AAA-HA interface MUST support pass-through EAP G4.1 The AAA-HA interface MUST support pass-through EAP
authentication with the HA working as EAP authenticator operating in authentication with the HA working as EAP authenticator operating in
pass-through mode and the AAAH server working as back-end pass-through mode and the AAAH server working as back-end
authentication server. authentication server.
These issues require the functionality of AAAH server working as a These issues require the functionality of AAAH server working as a
back-end authentication server and HA working as NAS and EAP back-end authentication server and HA working as NAS and EAP
authenticator in pass-through mode for providing a MN authentication. authenticator in pass-through mode for providing a MN authentication.
This document suggests this mode of operation in the context of the This document suggests this mode of operation in the context of the
relevant scenarios. relevant scenarios.
8.5. Provisioning of Configuration Parameters 7.5. Provisioning of Configuration Parameters
G5.1 The HA should be able to communicate to the AAAH server the HOA G5.1 The HA should be able to communicate to the AAAH server the HOA
allocated to the MN (e.g. for allowing the AAAH server to perform DNS allocated to the MN (e.g. for allowing the AAAH server to perform DNS
update on behalf of the MN). update on behalf of the MN).
This document describes needed AVPs for this purpose, see section This document describes needed AVPs for this purpose, see section
"DNS Update Mobility Option Attribute" "DNS Update Mobility Option Attribute"
9. Table of Attributes 8. Table of Attributes
The following tables provides a guide to which attributes may be The following tables provides a guide to which attributes may be
found in RADIUS packet and in what number. found in RADIUS packet and in what number.
The following defines the meaning of the notation used in the following The following defines the meaning of the notation used in the following
tables: tables:
0 An instance of this attribute MUST NOT be present. 0 An instance of this attribute MUST NOT be present.
1 Exactly one instance of this attribute MUST be present 1 Exactly one instance of this attribute MUST be present
0-1 Zero or one instance of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present.
skipping to change at page 40, line 5 skipping to change at page 42, line 5
As used in accounting packets: As used in accounting packets:
Request Interim Stop Type Attribute Request Interim Stop Type Attribute
0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute 0-1 0-1 0-1 MIP6-HA-TYPE MIP6-HA Attribute
0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute 0-1 0-1 0-1 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN Attribute
0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute 0 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix Attribute
0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute 0-1 0-1 0-1 MIP6-HOA-TYPE MIP6-HOA Attribute
0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute 0 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute
10. Diameter Considerations 9. Diameter Considerations
When used in Diameter, the attributes defined in this specification When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the are therefore allocated. The data types and flag rules for the
attributes are as follows: attributes are as follows:
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|----+
skipping to change at page 40, line 29 skipping to change at page 42, line 29
MIP6-HA Address | M | P | | V | Y | MIP6-HA Address | M | P | | V | Y |
MIP6-HA-FQDN UTF8String | M | P | | V | Y | MIP6-HA-FQDN UTF8String | M | P | | V | Y |
MIP6-HL-Prefix OctetString| M | P | | V | Y | MIP6-HL-Prefix OctetString| M | P | | V | Y |
MIP6-HOA Address | M | P | | V | Y | MIP6-HOA Address | M | P | | V | Y |
MIP6-DNS-MO OctetString| M | P | | V | Y | MIP6-DNS-MO OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----| -------------------------------|----+-----+----+-----|----|
Other than MIP6-HA and HOA-IPv6, the attributes in this specification Other than MIP6-HA and HOA-IPv6, the attributes in this specification
have no special translation requirements for Diameter to RADIUS or have no special translation requirements for Diameter to RADIUS or
RADIUS to Diameter gateways; they are copied as is, except for RADIUS to Diameter gateways; they are copied as is, except for
changes relating to headers, alignment, and padding. See also [4] changes relating to headers, alignment, and padding. See also [12]
Section 4.1 and [20] Section 9. MIP6-HA and HOA-IPv6 must be Section 4.1 and [30] Section 9. MIP6-HA and HOA-IPv6 must be
translated between their RADIUS representation of String to a translated between their RADIUS representation of String to a
Diameter Address format which requires that the AddressType field be Diameter Address format which requires that the AddressType field be
set to 2 for IP6 (IP version 6) set to 2 for IP6 (IP version 6)
What this specification says about the applicability of the What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [20] or Diameter-EAP-Request [21]. What is said about AA-Request [30] or Diameter-EAP-Request [31]. What is said about
Access-Challenge applies in Diameter to AA-Answer [20] or Diameter- Access-Challenge applies in Diameter to AA-Answer [30] or Diameter-
EAP-Answer [21] with Result-Code AVP set to EAP-Answer [31] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH. DIAMETER_MULTI_ROUND_AUTH.
What is said about Access-Accept applies in Diameter to AA-Answer or What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA- is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure. Answer or Diameter-EAP-Answer messages that indicate failure.
What is said about Accounting-Request applies to Diameter Accounting- What is said about Accounting-Request applies to Diameter Accounting-
Request [20] as well. Request [30] as well.
11. Security Considerations 10. Security Considerations
Assignment of these values to a user should be based on successful Assignment of these values to a user should be based on successful
authentication of the user at the NAS and/or at the HA. The RADIUS authentication of the user at the NAS and/or at the HA. The RADIUS
server should only assign these values to a user who is authorized server should only assign these values to a user who is authorized
for Mobile IPv6 service (this check could be performed with the for Mobile IPv6 service (this check could be performed with the
user's subscription profile in the Home Network). user's subscription profile in the Home Network).
The NAS and the HA to the RADIUS server transactions must be The NAS and the HA to the RADIUS server transactions must be
adequately secured. Otherwise there is a possibility that the user adequately secured. Otherwise there is a possibility that the user
may receive fraudulent values from a rogue RADIUS server potentially may receive fraudulent values from a rogue RADIUS server potentially
hijacking the user's Mobile IPv6 session. hijacking the user's Mobile IPv6 session.
These new attributes do not introduce additional security These new attributes do not introduce additional security
considerations besides the ones identified in [9]. considerations besides the ones identified in [11].
12. IANA Considerations 11. IANA Considerations
12.1. Registration of new AVPs 11.1. Registration of new AVPs
This specification defines the following new RADIUS attributes: This specification defines the following new RADIUS attributes:
MIP6-Feature-Vector is set to MIP6-FV-TYPE MIP6-Feature-Vector is set to MIP6-FV-TYPE
MIP6-HA is set to MIP6-HA-TYPE MIP6-HA is set to MIP6-HA-TYPE
MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE
MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE
MIP6-HOA is set to MIP6-HOsA-TYPE MIP6-HOA is set to MIP6-HOsA-TYPE
MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE
12.2. New Registry: Mobility Capability 11.2. New Registry: Mobility Capability
For MIP6-FV-TYPE flag values must be generated: For MIP6-FV-TYPE flag values must be generated:
Token | Value | Description Token | Value | Description
----------------------------------+----------------------+------------ ----------------------------------+----------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD] MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD] LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD]
Available for Assignment via IANA | 2^x | Available for Assignment via IANA | 2^x |
Allocation rule: Only numeric values that are 2^x (power of two) are Allocation rule: Only numeric values that are 2^x (power of two) are
skipping to change at page 42, line 46 skipping to change at page 44, line 46
Following the policies outlined in [1] new values with a description Following the policies outlined in [1] new values with a description
of their semantic for usage with the MIP6-Feature-Vector AVP together of their semantic for usage with the MIP6-Feature-Vector AVP together
with a Token will be assigned after Expert Review initiated by the with a Token will be assigned after Expert Review initiated by the
O&M Area Directors in consultation with the DIME working group chairs O&M Area Directors in consultation with the DIME working group chairs
or the working group chairs of a designated successor working group. or the working group chairs of a designated successor working group.
Updates can be provided based on expert approval only. A designated Updates can be provided based on expert approval only. A designated
expert will be appointed by the O&M Area Directors. No mechanism to expert will be appointed by the O&M Area Directors. No mechanism to
mark entries as "deprecated" is envisioned. Based on expert approval mark entries as "deprecated" is envisioned. Based on expert approval
it is possible to delete entries from the registry. it is possible to delete entries from the registry.
12.3. Addition of existing values 11.3. Addition of existing values
A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61) A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61)
13. Acknowledgements 12. Acknowledgements
We would like to thank the following individuals for their review and We would like to thank the following individuals for their review and
constructive comments during the development of this document: constructive comments during the development of this document:
Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev,
Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen. Andreas Pashalidis, Rafa Marin Lopez and Pasi Eronen.
14. References 13. References
14.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the [2] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), July 2007. progress), April 2008.
[3] Patel, A., "Authentication Protocol for Mobile IPv6", [3] Patel, A., "Authentication Protocol for Mobile IPv6",
draft-patel-mip6-rfc4285bis-00 (work in progress), draft-patel-mip6-rfc4285bis-00 (work in progress),
October 2006. October 2006.
[4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [4] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
"Diameter Base Protocol", RFC 3588, September 2003.
[5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", [5] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999. RFC 2548, March 1999.
[6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [6] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication Protocol In User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-07 (work in progress), draft-ietf-mip6-bootstrapping-split-07 (work in progress),
July 2007. July 2007.
[8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[9] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [9] Zorn, G. and A. Lior, "User Session Tracking in RADIUS",
draft-zorn-radius-logoff-11 (work in progress), February 2008.
[10] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
RFC 2868, June 2000.
[11] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
14.2. Informative References [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [13] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
13.2. Informative References
[14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[11] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping [15] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006. Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[12] Tschofenig, H., "Mobile IPv6 Bootstrapping using Diameter", [16] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and
draft-tschofenig-mip6-aaa-ha-diameter-01 (work in progress), M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to
October 2005. Diameter Server Interaction", draft-ietf-dime-mip6-split-10
(work in progress), July 2008.
[13] Manner, J. and M. Kojo, "Mobility Related Terminology", [17] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and
K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access
Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-09 (work in progress),
May 2008.
[18] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[14] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with [19] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", IKEv2 and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-08 (work in progress), draft-ietf-mip6-ikev2-ipsec-08 (work in progress),
December 2006. December 2006.
[15] Mockapetris, P., "Domain names - implementation and [20] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
"Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
RFC 4283, November 2005.
[21] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[16] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [22] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[17] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [23] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[24] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[25] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[18] Giaretta, G., "AAA Goals for Mobile IPv6", [26] Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP Options
for Home Information Discovery in MIPv6",
draft-ietf-mip6-hiopt-17 (work in progress), May 2008.
[27] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[28] Giaretta, G., "AAA Goals for Mobile IPv6",
draft-ietf-mip6-aaa-ha-goals-03 (work in progress), draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
September 2006. September 2006.
[19] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, [29] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial "Dynamic Authorization Extensions to Remote Authentication Dial
In User Service (RADIUS)", RFC 3576, July 2003. In User Service (RADIUS)", RFC 5176, January 2008.
[20] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter [30] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005. Network Access Server Application", RFC 4005, August 2005.
[21] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [31] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[22] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [32] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
"DNS Security Introduction and Requirements", RFC 4033, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
March 2005. April 1997.
[23] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [33] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004. Agents", RFC 3776, June 2004.
[24] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic [34] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, "DNS Security Introduction and Requirements", RFC 4033,
April 1997. March 2005.
Authors' Addresses Authors' Addresses
Avi Lior Avi Lior
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive, Suite 100 303 Terry Fox Drive, Suite 100
Ottawa, Ontario Ottawa, Ontario
Canada K2K 3J1 Canada K2K 3J1
Phone: +1 613-591-6655 Phone: +1 613-591-6655
skipping to change at page 47, line 44 skipping to change at line 1948
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 167 change blocks. 
536 lines changed or deleted 671 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/