One document matched: draft-ietf-mip6-radius-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1035 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'>
<!ENTITY rfc2104 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2136 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml'>
<!ENTITY rfc2548 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2548.xml'>
<!ENTITY rfc2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc2866 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2866.xml'>
<!ENTITY rfc2868 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2868.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc3736 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml'>
<!ENTITY rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc3753 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3753.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc3776 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3776.xml'>
<!ENTITY rfc3344 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3344.xml'>
<!ENTITY rfc3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY rfc4005 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml'>
<!ENTITY rfc4033 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY rfc4283 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4283.xml'>
<!ENTITY rfc4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY rfc4640 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4640.xml'>
<!ENTITY rfc4877 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4877.xml'>
<!ENTITY rfc5176 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5176.xml'>
<!ENTITY I-D.ietf-mip6-aaa-ha-goals PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-aaa-ha-goals.xml'>
<!ENTITY I-D.ietf-mip6-ikev2-ipsec PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-ikev2-ipsec.xml'>
<!ENTITY I-D.ietf-mip6-bootstrapping-split PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-bootstrapping-split.xml'>
<!ENTITY I-D.ietf-mip6-bootstrapping-integrated-dhc PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-bootstrapping-integrated-dhc.xml'>
<!ENTITY I-D.ietf-dime-mip6-split PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-mip6-split.xml'>
<!ENTITY I-D.ietf-dime-mip6-integrated PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-mip6-integrated.xml'>
<!ENTITY I-D.ietf-mip6-hiopt PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-hiopt.xml'>
<!ENTITY I-D.patel-mip6-rfc4285bis PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.patel-mip6-rfc4285bis.xml'>
<!ENTITY I-D.zorn-radius-logoff PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zorn-radius-logoff.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="full3978" docName="draft-ietf-mip6-radius-05.txt">
<front>
<title abbrev="RADIUS Mobile IPv6 Support">RADIUS Mobile IPv6 Support </title>
<author initials="A" surname="Lior" fullname="Avi Lior">
<organization>Bridgewater Systems</organization>
<address>
<postal>
<street>303 Terry Fox Drive, Suite 100</street>
<city>Ottawa</city>
<region>Ontario</region>
<code/>
<country>Canada K2K 3J1</country>
</postal>
<phone>+1 613-591-6655</phone>
<email>avi@bridgewatersystems.com</email>
</address>
</author>
<author initials="K" surname="Chowdhury" fullname="Kuntal Chowdhury">
<organization>Starent Networks</organization>
<address>
<postal>
<street>30 International Place</street>
<city>Tewksbury</city>
<region>MA</region>
<code>01876</code>
<country>US</country>
</postal>
<phone>+1 214-550-1416</phone>
<email>kchowdhury@starentnetworks.com</email>
</address>
</author>
<author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Siemens</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@siemens.com</email>
</address>
</author>
<date month="July" year="2008"/>
<area>Internet</area>
<keyword>RADIUS</keyword>
<keyword>IPv6 Mobility</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document defines new attributes to facilitate Mobile IPv6
operations using RADIUS infrastructure. The operations include
bootstrapping of information required by the Mobile Node and the
interface between the Network Access Server, Home Agent and the
RADIUS server used to assist MIP6 operations. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This document covers two aspects of MIP6 operations: bootstrapping of
information required by a Mobile IPv6 Mobile using the AAA infrastructure
and the interaction between the Network Access Server(NAS), MIPv6 Home
Agent (HA) and the Authentication Authorization and Accounting (AAA)
infrastructure.</t>
<t> Mobile IPv6 specification <xref target="RFC3775"/> requires
a Mobile Node (MN) to perform registration with an HA with
information about its current point of attachment (Care-of
Address). The HA creates and maintains binding between the MN's
Home Address (HOA) and the MN's Care-of Address. </t>
<t> 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 prefix Length and security related
information in order to secure the Binding Update. </t>
<t> The aforementioned set of information may be statically
provisioned in the MN. However, static provisioning of this
information has its drawbacks. It increases provisioning and
network maintenance burden for the operator. Moreover, static
provisioning does not allow load balancing, failover,
opportunistic home link assignment etc. For example, the user
may be accessing the network from a location that may be
geographically far away from the preconfigured home link; the
administrative burden to configure the MN's with the respective
addresses is large and the ability to react on environmental
changes is minimal. In these situations static provisioning may
not be desirable. </t>
<t> Dynamic assignment of Mobile IPv6 home registration
information is a desirable feature for ease of deployment and
network maintenance. For this purpose, the RADIUS
infrastructure, which is used for access authentication, can be
leveraged to assign some or all of the necessary parameters. The
RADIUS server in the Access Service Provider (ASP) or in the
Mobility Service Provider's (MSP) network 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 case of
the split scenario. The terms integrated and split are described
in the terminology section and are introduced in <xref
target="RFC4640"/>. </t>
<t> The second aspect of MIP6 and RADIUS interworking is the
interaction between the HA and the AAA using the RADIUS AAA
protocols. From a mobility service provider (MSP) perspective,
it is important to verify that the MN is authenticated and
authorized to utilize Mobile IPv6 service and that such services
are accounted for. Thus, prior to processing the Mobile IPv6
registrations, the HA, participates in the authentication of the
MN to verify the MN's identity. The HA also participates in the
Mobile IPv6 authorization process involving the RADIUS
infrastructure. The HA, due to its role in traffic forwarding,
may also perform accounting for the Mobile IPv6 service provided
to the MN. This document specifies the interaction between the
NAS, HA and the RADIUS server and aligns with the work done in with
the Diameter specifications described in <xref
target="I-D.ietf-dime-mip6-split"/> and <xref target="I-D.ietf-dime-mip6-integrated"/>.</t>
</section>
<section title="Terminology">
<t> The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>. </t>
<t> General mobility terminology can be found in <xref
target="RFC3753"/>. The following additional terms, as defined
in <xref target="RFC4640"/>, are used in this document: </t>
<t>
<list style="hanging">
<t hangText="Access Service Authorizer (ASA):">
<vspace blankLines="1"/> A network operator that authenticates
a mobile node and establishes the mobile node's authorization
to receive Internet service. </t>
<t hangText="Access Service Provider (ASP):">
<vspace blankLines="1"/> A network operator that provides
direct IP packet forwarding to and from the end host. </t>
<t hangText="Mobility Service Authorizer (MSA):">
<vspace blankLines="1"/> A service provider that authorizes Mobile IPv6
service. </t>
<t hangText="Mobility Service Provider (MSP):">
<vspace blankLines="1"/>A service provider that provides Mobile IPv6
service. In order to obtain such service, the MN must be
authenticated and authorized to obtain the Mobile IPv6 service. </t>
<t hangText="Split Scenario:">
<vspace blankLines="1"/>A scenario where the mobility service and the
network access service are authorized by different entities. </t>
<t hangText="Integrated Scenario:">
<vspace blankLines="1"/>A scenario where the mobility service and the
network access service are authorized by the same entity. </t>
</list>
</t>
</section>
<section title="Solution Overview">
<t> This document addresses the authentication, authorization and
accounting functionality required by MIPv6 bootstrapping and
Authentication as outlined in the MIPv6 bootstrapping problem statement
document (see <xref target="RFC4640"/>). As such, the AAA functionality
for the integrated and the split scenario needs to be defined. This
requires the ability to offer support for the HA to AAA server and the
network access server(NAS) to AAA server communication.</t>
<t> To highlight the main use cases, we briefly describe the integrated
and the split scenarios in <xref target="integrated"/> and <xref
target="split"/>, respectively. </t>
<section anchor="integrated" title="RADIUS Transaction in Integrated Scenario">
<t> In the integrated scenario MIPv6 bootstrapping is provided as part
of the network access authentication procedure. <xref
target="figure1"/> shows the participating entities. </t>
<figure anchor="figure1" title="Mobile IPv6 Service Access in the Integrated Scenario">
<artwork><![CDATA[
+---------------------------+ +-----------------+
|Access Service Provider | |ASA/MSA/(/MSP) |
|(Mobility Service Provider)| | |
| | | +-------+ |
| +-------+ | | |Remote | |
| |Local | RADIUS | | |RADIUS | |
| |RADIUS |-------------------------|Server | |
| |Proxy | | | +-------+ |
| +-------+ | | ^ |
| ^ ^ | | |RADIUS |
| | | | | | |
| | | | | v |
| RADIUS| | | +-------+ |
| | | +-------+ | | |Local | |
| | | RADIUS |Home | | | |Home | |
| | +------->|Agent | | | |Agent | |
| | |in ASP | | | +-------+ |
| v +-------+ | +-----------------+
+-------+ IEEE | +-----------+ +-------+ |
|Mobile | 802.1X | |NAS / Relay| |DHCPv6 | |
|Node |----------+-|RADIUS |---|Server | |
| | PANA,... | |Client | | | |
+-------+ DHCP | +-----------+ +-------+ |
+---------------------------+
]]></artwork>
</figure>
<t> In the typical Mobile IPv6 access scenario as shown above, the MN
attaches in the ASP's network. During this network attachment
procedure, the NAS/RADIUS client interacts with the MN. As shown in
<xref target="figure1"/>, the authentication and authorization happens
via a RADIUS infrastructure. </t>
<t> 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
access. Based on the MSA's policy, the RADIUS server may allocate
several parameters to the MN for use during the subsequent Mobile IPv6
protocol interaction with the HA. </t>
<t> Depending on the details of the solution, interaction with the
DHCPv6 server may be required, as described in <xref
target="I-D.ietf-mip6-bootstrapping-integrated-dhc"/>. </t>
</section>
<section anchor="split" title="RADIUS Transactions in Split Scenario">
<t> In the split scenario, Mobile IPv6 bootstrapping is not performed
as part of the network access authentication procedure. Other RADIUS
transactions such as authentication and authorization, accounting and
parameter configuration for MIP6 service is provided by the HA to
RADIUS transactions.</t>
<t> The Mobile IPv6 RADIUS transaction are executed with the Mobility
Service Provider when desired by the MN. Two scenarios can be
considered:
<list style="numbers">
<t>The MSA and the MSP are the same entity. </t>
<t>The MSA and the MSP are different entities. </t>
</list></t>
<t> Since scenario (2) is the more generic scenario we show it in
<xref target="figure2"/>. </t>
<figure anchor="figure2" title="Mobile IPv6 service access in the split scenario (MSA != MSP)">
<artwork><![CDATA[
+----------------------+
| |
|Mobility +-------+ |
|Service |Remote | |
|Authorizer |RADIUS | |
|(MSA) |Server | |
| +-------+ |
+---------------^------+
|
|RADIUS
|
|
+---------------------------------|------+
|Mobility Service Provider (MSP) v |
+-------+ | +-----------+ +-------+ |
|Mobile | MIPv6 / | |HA/ | RADIUS |Local | |
|Node |-------------|RADIUS |-------------- |RADIUS | |
| | IKEv2 | |Client | |Proxy | |
+-------+ | +-----------+ +-------+ |
+----------------------------------------+
]]></artwork>
</figure>
<t> As shown in <xref target="figure2"/> the interaction between the
RADIUS client and the RADIUS server is triggered by the protocol
interaction between the MN and the HA/RADIUS client using IKEv2 <xref
target="I-D.ietf-mip6-ikev2-ipsec"/> or MIPv6 Authentication Protocol
<xref target="I-D.patel-mip6-rfc4285bis"/>. The important aspect is,
however, that for these two approaches, several different
authentication and key exchange solutions are available. To establish
IPsec security associations for the protection of Mobile IPv6
signaling messages, IKEv2 is used <xref
target="I-D.ietf-mip6-ikev2-ipsec"/>. IKEv2 supports EAP-based
authentication, certificates and pre-shared secrets. For protection
of MObile IPv6 signaling messages using the MIPv6 Authentication
Protocol <xref target="I-D.patel-mip6-rfc4285bis"/> a mechanism has
been designed that is very similar to the one used by Mobile
IPv4.</t>
<t> The ability to use different credentials has an impact on the
interaction between the HA (acting as a RADIUS client) and the RADIUS
Server. For that reason this document illustrates the usage of these
authentication mechanisms with different subsections for:
<list style="symbols">
<t> IKEv2 usage with EAP</t>
<t> IKEv2 usage with certificates and pre-shared secrets</t>
<t> MIPv6 Authentication Protocol</t>
</list>
</t>
<t> For accounting of Mobile IPv6 services provided to the MN, this
specification uses the RADIUS based accounting defined in <xref
target="RFC2866"/>.</t>
<t> Additionally, the MN might instruct the RADIUS server (via the
HA) to perform a dynamic DNS update. </t>
</section>
</section>
<section title="Use of existing RADIUS Attributes">
<!-- Need to also discuss attribs like Proxy etc... -->
<section title="User-Name">
<t>If authentication via IKEv2 is used then the User-Name attribute
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 <xref target="RFC4283"/>.</t>
</section>
<section title="Service-Type">
<t>The HA uses Service-Type(6) to indicate whether the
Access-Request operation is for Authentication and Authorization or
just Authorization.</t>
</section>
<section title="NAS-Port-Type">
<t> In order for the AAA to distinguish the source of the
Access-Request NAS-Port-Type(61) is used as follows:</t>
<t> When the Access-Request originates from an MIP6 HA, NAS-Port-Type
MUST be included and its value set to HA6(IANA-TBD1).</t>
</section>
<section title="Calling-Station-Id">
<t>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 Calling-Station-Id(31)
should be set to the 128-bit MN IPv6 COA.</t>
</section>
<section title="Use of MS-MPPE-Recv-Key and MS-MPPE-Send-Key">
<!-- MIP-Session-Key in Split -->
<t>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 <xref target="RFC2548"/>.
The 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. The encryption of
these attributes is described in <xref
target="RFC2548"/>.</t>
</section>
<section title="Session-Timeout">
<!-- MIP-MSA-Lifetime from Split mapping this to
session-timeout. Note that Split has authentication
lifetime and MSA Lifetime. Why? I dont know. -->
<t>The use of Session-Timeout attribute during bootstrapping operations
is covered by various RFC's.</t>
<t>The use of Session-Timeout attribute during the EAP exchanges
between the HA and the RADIUS server are as per <xref
target="RFC3579"/>.</t>
<t>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
Registration Lifetime.</t>
</section>
<section title="Message Authenticator">
<t>The use of Message Authenticator is mandated during EAP AAA
procedures by <xref target="RFC3579"/>. In the case of the HA sending
an Access-Request where EAP is not used, then the HA MUST also include
the Message Authenticator attribute in the Access-Request packet.</t>
</section>
</section>
<section title="RADIUS attributes">
<t> This section defines format and syntax for the attribute that carries
the Mobile IPv6 parameters that are described in the previous section.</t>
<t> The attributes MAY be present in Access-Request, Access-Accept,
and Accounting-Request packets. </t>
<section title="MIP6-Feature-Vector Attribute">
<t> Exactly one of this attribute MUST be sent by the NAS or HA in an
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.</t>
<t> 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
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.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MIP6 Features Vectors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIP6 Features Vectors cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIP6 Features Vectors cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type:
<list style="empty">
<t>MIP6-FV-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length:
<list style="empty">
<t> = 10 octets </t>
</list>
</t>
<t> Feature Flags:
<list style="empty">
<t> This field is of type String. Supporting the following values:
<list style="empty">
<t>MIP6_INTEGRATED (0x0000000000000001)</t>
<t>When this flag is set by the NAS then it means that the
Mobile IPv6 integrated scenario bootstrapping functionality
is supported by the NAS. When this flag is set by the
RADIUS server then the Mobile IPv6 integrated scenario
bootstrapping is supported by the RADIUS server.</t>
<t>LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002)</t>
<t>When this flag is set by the NAS then a local home agent
can be assigned to the MN. When this flag is set by the
Diameter server then the assignment of location HAs is
authorized by the Diameter server.</t>
<t>RO_SUPPORTED (0x0000000800000000)</t>
<t>Route optimization is supported. When the Home Agent
sets this bit, it indicates support for the route
optimization. If this bit is unset in the returned
Mobility-Capability AVP, the HAAA does not authorize route
optimization for the MN.</t>
<t>In a case the Home Agent or the HAAA cannot authorize
the use of route optimization then the Home Agent will send
a Binding Acknowledgement with a Status Code set to
ACCEPTED_BUT_NO_ROUTE_OPTIMIZATION (status code TBD). This
Status Code indicates that the binding registration
succeeded but the Home Agent will fail all possible
subsequent route optimization attempts because of
subscription or operator policy.</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-HA Attribute">
<!-- In split this is MIP-Home-Agent-Address -->
<t> 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. </t>
<t>In the case of bootstrapping, one or more of this attribute MAY be
sent by the NAS to the RADIUS server in an Access-Request packet as a
proposal by the NAS to allocate a local HA to the MN.</t>
<t>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.</t>
<t>[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
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
suggestion.</t>
<t> 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 the serving HA for this session.</t>
<t>In the case of split, the MIP6-HA attribute contains the IPv6 address
of the Home Agent as received in the BU message. One and only one of
this attribute SHALL be sent by the HA to the RADIUS server.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address of assigned HA cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> MIP6-HA-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> = 28 octets </t>
</list>
</t>
<t> Reserved: <list style="empty">
<t> Reserved for future use. The bits MUST be set to zero by
the sender, and MUST be ignored by the receiver.</t>
</list>
</t>
<t> Prefix-Length: <list style="empty">
<t> This field indicates the prefix length of the Home Link. </t>
</list>
</t>
<t> IPv6 address of assigned HA: <list style="empty">
<t> 128-bit IPv6 address of the assigned HA. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-HA-FQDN Attribute">
<t> In the case of bootstrapping, one or more instance of this
attribute MAY be 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 MN. The RADIUS server MAY use this value or may
ignore this suggestion.</t>
<t>In the case of bootstrapping, one or more of this attribute is
sent by the RADIUS server to the NAS in an Access-Accept packet. The
attribute carries the FQDN of the assigned HA. The mobile node can
perform DNS query with the FQDN to derive the HA address. </t>
<t> If available at the NAS, at least MIP6-HA-FQDN attribute
and/or MIP6-HA SHOULD appear in accounting packets to indicate
the identity of the serving HA for this session.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | FQDN of the assigned HA .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-HA-FQDN-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> Variable length. </t>
</list>
</t>
<t> FQDN of the assigned HA: <list style="empty">
<t> The data field MUST contain a FQDN as described in <xref
target="RFC1035"/>. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-HL-Prefix Attribute">
<t> In the case of bootstrapping, 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 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.</t>
<t>In the case of bootstrapping, this attribute is sent by the
RADIUS server to the NAS in an Access-Accept packet and carries the
assigned Home Link prefix that is in close proximity to the point of
attachment (NAS-ID). The MN can perform <xref target="RFC3775"/>
specific procedures to discover other information for Mobile IPv6
registration.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Home Link Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-HL-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length:
<list style="empty">
<t> >= 4 octets + the minimum length of a
prefix. </t>
</list>
</t>
<t> Reserved:
<list style="empty">
<t> Reserved for future use. The bits MUST be
set to zero by the sender, and MUST be ignored
by the receiver.</t>
</list>
</t>
<t> Prefix-Length:
<list style="empty">
<t> This field indicates the prefix length of the
Home Link. </t>
</list>
</t>
<t> Home Link Prefix:
<list style="empty">
<t> Home Link prefix (upper order bits) of the
assigned Home Link where the MN should send
binding update. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-HOA Attribute">
<!-- In split MIP-Mobile-Node-Address -->
<t> In the bootstrapping case, this attribute is sent by the RADIUS
server to the NAS in an Access-Accept packet. The attribute carries
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.</t>
<t> 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
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
NAS's HA suggestion.</t>
<t> 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.</t>
<t> If available at the NAS, this attribute SHOULD appear in the
accounting packets so that the IPv6 addressed used for this session
is known in the accounting stream.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Assigned IPv6 HOA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-HOA-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> = 20 octets. </t>
</list>
</t>
<t> Reserved: <list style="empty">
<t> Reserved for future use. The bits MUST be set to zero by the sender, and MUST be ignored by the receiver.</t>
</list>
</t>
<t> Prefix-Length: <list style="empty">
<t> This field indicates the prefix length of the Home Link. </t>
</list>
</t>
<t> Assigned IPv6 HOA: <list style="empty">
<t> IPv6 HOA that is assigned to the MN. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-DNS-MO Attribute">
<t>In the case of bootstrapping, the MIP6-DNS-MO attribute is
included by the NAS in an Access-Request packet and MUST set its
value to the MN's FQDN to indicate to the RADIUS server to perform a
dynamic DNS 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.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved-1 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved-2 | FQDN ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> DNS-UPDATE-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> Variable length. </t>
</list>
</t>
<t> Reserved-1: <list style="empty">
<t> Reserved for future use. The bits MUST be set to zero by the sender,
and MUST be ignored by the receiver.</t>
</list>
</t>
<t> Status: <list style="empty">
<t> This 8 bit unsigned integer field indicates the result of the
dynamic DNS update procedure as defined in <xref
target="I-D.ietf-mip6-bootstrapping-split"/>. This field MUST be set
to 0 and ignored by the RADIUS server when the MIP6-DNS-MO is sent
from the RADIUS client to the RADIUS server. When the MIP6-DNS-MO is
provided in the response, values of the Status field less than 128
indicate that the dynamic DNS update was performed successfully by
the RADIUS server. Values greater than or equal to 128 indicate that
the dynamic DNS update was not successfully completed. The following
values for the Status field are currently defined: </t>
<t> 0 DNS update performed </t>
<t> 128 Reason unspecified </t>
<t> 129 Administratively prohibited </t>
<t> 130 DNS Update Failed </t>
</list>
</t>
<t> R flag: <list style="empty">
<t> If this bit for the R flag is set then the RADIUS client
requests the RADIUS server to remove the DNS entry identified by
the FQDN included in this attribute. If not set, the RADIUS
client is requesting the RADIUS server to create or update a DNS
entry with the FQDN specified in this attribute and the Home
Address carried in another attribute specified in this document. </t>
</list>
</t>
<t> Reserved-2:
<list style="empty">
<t> Reserved for future use. The bits
MUST be set to zero by the sender, and
MUST be ignored by the receiver.</t>
</list>
</t>
<t> FQDN of the MN: <list style="empty">
<t> In an Access-Request packet the data field MUST contain a FQDN.
In an Access-Accept packet the data field MAY contain an FQDN.
FQDN is described in <xref target="RFC1035"/>. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-Careof-Address">
<t>In the case of split, this attribute is sent from the HA to the
RADIUS Server and contains the IPv6 addresss
of the Care-of Address of the MN extracted from the BU
message.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Assigned IPv6 COA |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-CAREOF-ADDRESS-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> = 20 octets. </t>
</list>
</t>
<t> Reserved: <list style="empty">
<t> Reserved for future use. The bits MUST be set to zero by the sender, and MUST be ignored by the receiver.</t>
</list>
</t>
<t> Prefix-Length: <list style="empty">
<t> This field indicates the prefix length of the COA Link. </t>
</list>
</t>
<t> Assigned IPv6 COA: <list style="empty">
<t> IPv6 COA that is assigned to the MN. </t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-MN-AAA-SPI">
<t>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. The MIP6-MN-AAA-SPI attribute contains an SPI
code extracted from the Mobility Message Authentication Option included
in the received BU message.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-MN-AAA-SPI-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> 6 octets </t>
</list>
</t>
<t> Integer representing a Security Parameter Index.</t>
</list>
</t>
</section>
<section title="MIP6-Authenticator">
<t>In the case of split, this attribute is sent from the HA to the
RADIUS server and contains the Authenticator data from the BU message.
The HA extract the data form the MN-AAA Mobility Message Authentication
Option if included in the received BU message.</t>
<t>Upon receiving this attribute from the HA, 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.</t>
<t>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.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authenticator Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator Data cont ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-AUTHENTICATOR-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> Variable length </t>
</list>
</t>
<t> String. An OctetString representing authenticator data.</t>
</list>
</t>
</section>
<section title="MIP6-MAC-Mobility-Data">
<t>In the case of split, the MIP6-MAC-Mobility-Data attribute is sent
from the HA to the RADIUS Server. The attribute contains the calculated
MAC_Mobility_Data as defined in <xref
target="I-D.patel-mip6-rfc4285bis"/>.</t>
<t>This attribute MUST be present in an Access-Request sent from the HA
to the RADIUS Server when using MIPv6 Authentication Protocol.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MAC Mobility Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Mobility Data cont ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-MAC-MOBILITY-DATA-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> Variable length </t>
</list>
</t>
<t> String. An OctetString representing authenticator data.</t>
</list>
</t>
</section>
<section title="MIP6-Timestamp">
<t>The MIP6-Timestamp contains the timestamp value from the Mobility
message replay protection option, defined in <xref
target="I-D.patel-mip6-rfc4285bis"/>. The Home Agent extracts this
value from the received BU message, if available.</t>
<t>The support for replay protection is an optional feature in <xref
target="I-D.patel-mip6-rfc4285bis"/>. 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.</t>
<t>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.</t>
<t>[EDITOR'S NOTE] there is an issue here. In the diameter protocol, if
there is a time mismatch we return a result code that states that there
was a time mismatch and we return this value. In RADIUS land we return
an Access-Reject but we cant really return any other attributes.</t>
</section>
<section title="MIP6-MN-HA-SPI">
<t>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.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-MN-HA-SPI-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> 6 octets </t>
</list>
</t>
<t> Integer representing a Security Parameter Index.</t>
</list>
</t>
</section>
<section title="MIP6-Algorithm-Type">
<t>In the case of split, the MIP6-Algorithm-Type is available to be
sent in an Access-Accept packet from the RADIUS server to the HA. It is
part of a group of attributes used with the MIPv6 Authentication
protocol and contains the algorithm type. </t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | enumeration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enumeration cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-ALGORITHM-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> 6 octets </t>
</list>
</t>
<t> Integer representing an enumeration as supported by <xref target="RFC3344"/>:
<list style="empty">
<t>2: HMAC-SHA-1 <xref target="RFC2104"/></t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-Replay-Mode">
<t>In the case of split, the MIP6-Replay-Mode is available to be sent
in an Access-Accept packet from the RADIUS server to the HA. It is part
of a group of attribute used with the MIPv6 Authentication protocol and
contains the replay mode as defined in RFC4004 to be used by the
HA.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | enumeration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enumeration cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-REPLAY-MODE-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> 6 octets </t>
</list>
</t>
<t> Integer representing an enumeration as supported by <xref target="RFC3344"/>:
<list style="empty">
<t>1: None.</t>
<t>2: Timestamps.</t>
<t>3: Nonces.</t>
</list>
</t>
</list>
</t>
</section>
<section title="MIP6-Nonce">
<t>In the case of split, the MIP6-Nonce is available to be sent in an
Access-Accept packet from the RADIUS Server to the HA. It is part of a
group of attributes used with the MIPv6 Authentication protocol and
contains the nonce to send to the MN.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="empty">
<t> Type: <list style="empty">
<t> ASSIGNED-MIP6-NONCE-TYPE to be defined by IANA. </t>
</list>
</t>
<t> Length: <list style="empty">
<t> Variable length </t>
</list>
</t>
<t> String. A binary string representing a nonce.</t>
</list>
</t>
</section>
</section> <!-- end of RADIUS Attributes section -->
<section title="Message Flows">
<section title="Use of RADIUS in Integrated Scenario (MSA=ASA)">
<t>This section is based on <xref
target="I-D.ietf-mip6-bootstrapping-integrated-dhc"/> and uses
the RADIUS attributes that are defined in this document. </t>
<section title="HA allocation in the MSP">
<t>RADIUS is used to authenticate the MN, to authorize it for the
mobility service and to send information about the assigned HA to the
NAS. </t>
<t><figure anchor="figure3" title="HA allocation in the MSP">
<artwork><![CDATA[
|
--------------ASP------>|<--ASA+MSA--
|
+----+ +------+ +-------+ +-------+
| | |RADIUS| | | | |
| | |Client| | | | |
| MN | |NAS/ | | DHCP | |Home |
| | |DHCP | | Server| |RADIUS |
| | |Relay | | | |Server |
+----+ +------+ +-------+ +-------+
| | | |
| 1 | 1 | |
|<------------->|----------------------->|
| | | |
| | 2 | |
| |<-----------------------|
| | | |
| 3 | | |
|-------------->| | |
| | | |
| | 4 | |
| |------------>| |
| | | |
| | 5 | |
| |<------------| |
| | | |
| 6 | | |
|<--------------| | |
| | | |
]]></artwork>
</figure>
</t>
<t> In step (1), the MN executes the network access
authentication 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 of the authentication dialogue is the MN's home RADIUS
server. This is the typical scenario in case the messages involved in
the authentication protocol are transported in EAP.</t>
<t> As per <xref target="RFC3579"/>, the NAS
encapsulates/de-capsulates EAP packets into/from RADIUS
packets until an Access-Response (either an Access-Accept or
an Access/Reject packet is received by the NAS). This
concludes the network access authentication phase.</t>
<t> If the NAS has the ability to support MIP6 Bootstrapping
it includes the MIP6-Feature-Vector in the first
Access-Request message and indicates whether it supports
MIP6 bootstrapping and/or local home agent assignment by
setting the appropriate flags therein.</t>
<t> 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
attribute(s) as a proposal to the RADIUS server to indicate that the
HA is to be assigned in the ASP.</t>
<t> 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 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 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 more HA addresses thus
indicating that the NAS can either allocate a local HA or
one specified by the RADIUS server.</t>
<!--
> $Rafa: two things. could not it be used that Zorn's draft
> about key wrapper in RADIUS for the AVPs?.
> About the key, I don't understand. I assumed MN needs to run EAP over
> IKEv2 HA also in the integrated scenario so...
> I would say MSK(AAA-key) generated during this EAP over IKEv2
> authentication is enough no?
>
> [hannes] Zorn's draft cannot be used. The EAP over IKEv2 is,
> however, an interesting issue. I suggest to delete the note
> from the draft.
<t>
[Editor's Note: The description about the key derivation for usage between the MN and the HA needs to be described. New AVPs might be needed.]
</t>
-->
<t>In step (3) the MN performs home information discovery procedures
as specified in [DHCPv6 for Home Info Discovery in MIPv6][hiopt]. The
MN sends a DHCPv6 Information-request message including the Home
Network Information option according to the stateless DHCPv6
procedures <xref target="RFC3736"/> and <xref target="RFC3315"/>. The
MN MUST also include the Option code for the Home Network Information
option in the Option Request option in the request. The id-type of
the Home Network Identifier Option is 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.</t>
<t> In step (4) the DHCP relay agent forwards this request to the
DHCP server. The OPTION_MIP6-RELAY-Option is included in this
forwarded message. This option carries the RADIUS MIP6-HA attribute
received in the Access-Accept packet.</t>
<t> 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
Network Identifier Option = 1). The DHCP server extracts the HA
address from OPTION_MIP6-RELAY-Option and places it into Home Network
Information Option in the Reply message.</t>
<t> 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 available at the MN.</t>
</section>
<section title="HA allocation in the ASP (visited network)">
<t> 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
Network Identifier Option is set to zero, indicating that a HA is
requested in the ASP instead of in the MSP. Thus, the information
received by the home RADIUS server, via the DHCP relay, in the
OPTION_MIP6-RELAY-Option (Information Request) is ignored. The DHCP
server allocates a HA from its list of possible HAs and returns it in
the Reply message (Home Network Information Option). </t>
<!--
> %Rafa: Under my point of view, Home AAA server should signal
> to NAS through some flag or attribute. In this way, NAS/Relay
> would not accept Home Network Identifier Option to zero. does
> it make sense?
>
> [hannes] makes sense. no modifications are done with this
> draft version.
<t>
[Editor's Note: What if the user profile, which is kept at the home AAA server, does not allow the HA to be allocated in the ASP? How is this signaled? ]
</t>
-->
</section>
</section>
<section title="Use of RADIUS In Split Scenario">
<t>In this section we present the call flows used in the Split scenario.
In the Split scenario the MN can be authenticated and authorized for
Mobile IPv6 by using IKEv2 or the Mobile IPv6 Authentication Protocol
<xref target="I-D.patel-mip6-rfc4285bis"/>. The authentication and or
authorization takes place between the HA and the RADIUS server.</t>
<section title="Split using IKEv2">
<t>This section describes IKEv2 based authentication and authorization
for the SPLIT scenario using IKEv2 and EAP and IKEv2 with Certificates
and Preshared Keys.</t>
<section title="IKEv2 and EAP" >
<t>The use of IKEv2 with EAP between the MN and the HA allows the
AAA to authenticate the MN. When EAP is used with IKEv2, the
RADIUS EAP procedures, as defined in <xref target="RFC3579" />,
are used. EAP methods that do not 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 <xref
target="RFC4306"/>. Attributes specific to Mobile IPv6
bootstrapping are added to the AAA packets.</t>
<t><xref target="figure4"/> shows the message flow involved during the
authentication phase when EAP is used.</t>
<t><figure anchor="figure4" title="Split Scenario Exchange Using IKEv2 and EAP">
<artwork><| |
|<--------------------------------| |
| | |
| 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} | |
|<--------------------------------| |
| | |
]]></artwork>
</figure></t>
<t>Before this scenario started the MN has to know the IP address
of the 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 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 HA to use. Alternatively, MN could have received
the information by performing a DHCP request as per <xref
target="I-D.ietf-mip6-hiopt"/></t>
<t>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.</t>
<t>Exchange (3) starts the IKE_AUTH phase. This second phase of
IKEv2 authenticates the previous messages, exchanges identities
and certificates and establishes the first CHILD_SA. It is used
to mutually authenticate the MN (acting as an IKEv2 Initiator)
and the 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 <xref
target="RFC4306"/>).</t>
<t>As part of the authentication process, the MN MAY request a
Home- Address, a Home Prefix or suggests one, see <xref
target="RFC4877"/>, using a CFG_REQUEST payload in the
exchange(3).</t>
<t>The HA extracts the IDi field from exchange (3) and sends a
RADIUS Access-Request packet(4) towards the authenticating RADIUS
server. The User-Name(1) attribute is set to the value received
in the IDi field and the EAP-Payload attribute contains a
EAP-Response/ Identity with the identity extracted from the IDi
field. The Access-Request packet is integrity protected by the
Message-Authenticator(89) attribute.</t>
<t>This message is routed to the MN's home RADIUS server/EAP
server. 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.</t>
<t>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.</t>
<t>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.</t>
<t>Eventually, when the HA receives a Binding Update (BU), the HA
authenticates and authorizes the MN. It is RECOMMENDED that the
HA sends a RADIUS accounting request message every time it
receives a BU. Alternatively, if the HA does not support RADIUS
Accounting, it SHOULD send a User-Session-Notification packet as defined
in <xref target="I-D.zorn-radius-logoff"/> to inform the AAA
server that the mobile ip session has termianted.</t>
</section>
<section title="IKEv2 and Certificates">
<t>When IKEv2 is used with certificate-based authentication, the
HA performs the authentication of the MN based on the received
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.</t>
<t>EDITOR's note: we have to differentiate the CERT case from the
PSK case to the AAA.</t>
</section>
<section title="IKEv2 and Preshared Keys">
<t>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.</t>
<t>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 <xref target="RFC2548"/>. This
attribute must be encrypted using the procedures defined in
section 3.5 of <xref target="RFC2868"/>. The Access-Accept MUST
be integrity protected using Message-Authenticator(89) attribute.
The Access-Accept packet may contain other MIP6 authorization
attributes.</t>
<t>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.</t>
</section>
</section>
<section title="Split and Mobile IPv6 Authentication Protocol">
<t> <xref target="figure5"/> 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.</t>
<t>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.</t>
<t>According to <xref target="I-D.patel-mip6-rfc4285bis"/> the MN
uses the Mobile Node Identifier Option, specifically the MN-NAI
mobility option (as defined in <xref target="RFC4283"/>) to identify
itself. The HA MUST copy the MN-NAI mobility option value to the
User-Name(1) attribute in the Access-Request packet.</t>
<t>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 <xref
target="I-D.zorn-radius-logoff"/> 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.</t>
<t>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 <xref target="I-D.patel-mip6-rfc4285bis"/>), 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 <xref
target="I-D.patel-mip6-rfc4285bis"/> 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 <xref
target="I-D.patel-mip6-rfc4285bis"/> 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.</t>
<t>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.</t>
<t>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 <xref target="RFC2868"/>. The
RADIUS Access-Accept packet MUST be integrity protected using
Message-Authenticator(89) attribute.</t>
<t>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.</t>
<t>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 <xref
target="RFC2868"/>. The RADIUS Access-Accept packet MUST be
integrity protected using Message-Authenticator(89) attribute.</t>
<t><figure anchor="figure5" title="Mobile IPv6 Bootstrapping using the Mobile IPv6 Authentication Protocol">
<artwork><![CDATA[
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) |
| |-------------------->|
]]></artwork>
</figure></t>
Figure 4:
</section>
</section>
</section>
<section title="Goals for the HA-AAA Interface">
<t>Here, we follow the classification and labels listed in the MIPv6-AAA-Goals document
<xref target="I-D.ietf-mip6-aaa-ha-goals"/>.</t>
<section title="General Goals">
<t> G1.1-G1.4 Security</t>
<t> These are standard requirements for a AAA protocol –
mutual authentication, integrity, replay protection,
confidentiality. IPsec can be used to achieve the goals. Goal
G1.5 regarding inactive peer detection needs further
investigations since heartbeat messages do not exist (like in
the Diameter case, Watch-Dog-Request/Answer).</t>
</section>
<section title="Service Authorization">
<t> 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 used for the purpose to carry the NAI. </t>
<t> 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 functionality<xref target="RFC2865"/> can possibly initiate a
request message. In combination with the ability of the RADIUS
protocol to carry EAP messages <xref target="RFC3579"/> , our
solution will enable an HA to query a RADIUS server and verify MIPv6
authorization for the MN. </t>
<t> G2.3 The AAAH server should be able to enforce explicit
operational limitations and authorization restrictions on the HA
(e.g., packet filters, QoS parameters). Work in progress in the area,
including NAS-Filter-Rule, RADIUS quality of service support, prepaid
extensions etc. is performed. The relevant attributes may be reused
for providing required functionality over the AAAH-HA interface.</t>
<t> G2.4 - G2.6. Issues addressing the maintenance of a Mobile
IPv6 session by the AAAH server, e.g., authorization lifetime,
extension of the authorization lifetime and explicit session
termination by the AAAH server side.</t>
<t>The attribute Session-Timeout may be sent in Access-Challenge
or Access-Accept packet by the RADIUS server, thus limiting the
authorization session duration. In order to
reauthenticate/reauthorize the user, the Termination-Action
attribute can be included, with value 1, meaning the NAS should
send a new RADIUS-Request packet. Additional AVPs for dealing
with pre-paid sessions (e.g,. volume, resource
used—VolumeQuota AVP, ResourceQuota AVP) are specified in
RADIUS prepaid extension. Exchanging of application specific
authorization request/answer messages provides extension of the
authorization session (e.g., Authorize Only Access-Request sent
by the HA (NAS) to the RADIUS server). Initiation of the
re-authorization by both sides could be supported. Both sides
could initiate session termination – the RADIUS server by
sending Disconnect message <xref target="RFC5176"/>.</t>
<!-- omiited in last AAA-Goals document
<t>
G2.7 The AAAH server should be able to retrieve the Mobile IPv6
state associated to a specific MN from the correspondent HA.
This may be useful to periodically verify the Mobile IPv6
service status.
</t>
<t>
As discussed in <xref target="I-D.ietf-dime-mip6-split"/>, there are two aspects to be solved:
The AAAH server needs to know which HA to contact in order to retrieve the current status of the MN's Mobile IPv6 service in case of a stateless MSP architecture and several servicing AAA servers.
Once having the HA information, the AAAH should contact the HA to verify the
status of MN's Mobile IPv6 service.
</t>
-->
</section>
<section title="Accounting">
<t>G3.1 The AAA-HA interface must support the transfer of
accounting records needed for service control and charging.
These include (but may not be limited to): time of binding cache
entry creation and deletion, octets sent and received by the MN
in bi-directional tunneling, etc. </t>
<t>The requirements for accounting over the AAAH-HA interface
does not require enhancements to the existing accounting
functionality. </t>
</section>
<section title="MN Authentication">
<!--
<t>
G4.1 The AAA-HA interface should support MN authentication (and re-
authentication) with the HA working as NAS and the AAAH server
working as back-end authentication server.
</t>
<t>
G4.2 The AAA-HA interface should support at least pass-through EAP
authentication with the HA working as EAP authenticator
operating in pass-through mode and the AAAH server working as
back-end authentication server.
</t>
-->
<t>G4.1 The AAA-HA interface MUST support pass-through EAP
authentication with the HA working as EAP authenticator
operating in pass-through mode and the AAAH server working as
back-end authentication server.</t>
<t> These issues require the functionality of AAAH server
working as a back-end authentication server and HA working as
NAS and EAP authenticator in pass-through mode for providing a
MN authentication. This document suggests this mode of operation
in the context of the relevant scenarios. </t>
</section>
<section title="Provisioning of Configuration Parameters">
<t> 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 update on behalf of the MN).</t>
<t> This document describes needed AVPs for this purpose, see
section "DNS Update Mobility Option Attribute"</t>
<!-- changed in latest AAA-Goals document
<t>
G5.1 The AAAH server should be able to poll the designated HA for
the allocation of a HOA to the MN. Optionally, the
AAAH server can provide a set of hints for the construction of
the HOA (e.g., a preferred HOA or a preferred
Interface Identifier).
</t>
<t>
G5.2 The HA should be able to communicate to the AAAH server the
HOA allocated to the MN.
</t>
<t>
G5.3 The AAAH server should be able to send to the HA the security
data needed to setup the IPsec SA between the MN and the HA.
Possible security data are the authentication method and the
cryptographic material to be used for IKE bootstrapping.
</t>
-->
</section>
</section>
<section title="Table of Attributes">
<t> The following tables provides a guide to which attributes may be found in RADIUS
packet and in what number. </t>
<t>
<figure>
<artwork><![CDATA[
The following defines the meaning of the notation used in the following
tables:
0 An instance of this attribute MUST NOT 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+ Zero or more instance of this attriubte MAY be present
The table below describes the RADIUS messages used for bootstrapping and are
exchanged between the NAS and the RADIUS Server.
Request Accept Reject Challenge Type Attribute
1 1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector
0+[ac] 0+[a] 0 0 MIP6-HA-TYPE MIP6-HA
0+[ac] 0+[a] 0 0 MIP6-HA-FQDN-TYPE MIP6-HA-FQDN
0-1[b] 0-1 0 0 MIP6-HL-PREFIX-TYPE MIP6-HL-Prefix
0-1[b] 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA
0-1 0-1 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO
Notes:
[a] Either MIP6-HA or MIP6-HA-FQDN MAY appear in a RADIUS packet.
[b] If MIP6-HA or MIP6-HA-FQDN are present in the Access-Request
then these attributes MUST also be present in the Access-Request.
If the RADIUS server accepts the NAS suggestion for the HA, then
the RADIUS server MUST also include the values received for these
attributes in the Access-Accept.
[c] If these attributes are present in an Access-Request, then
LOCAL_HOME_AGENT_ASSIGNMENT flag of the MIP6-Feature-Vector MUST be set.
Otherwise these attributes are ignored.
The following tables lists the commands and attributes used in the interaction
between the HA and RADIUS server. Each table corresponds to the different
authentication modes supported. These attributes are in addition to the any
other attributes specified by an other specification (for example, RADIUS EAP)
Table of attributes for IKEv2 and certificate or PSK-based Authentication:
Request Accept Reject Challenge Type Attribute
1 0 0 0 61 NAS-Port-Type
0-1 0 0 0 80 Message-Authenticator
0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector
1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA
0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address
0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI
0-1 0 0 0 MIP6-HA-TYPE MIP6-HA
0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator
0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data
0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp
0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI
0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type
0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode
0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce
Table of attributes for IKEv2 and EAP-based Authentication:
Request Accept Reject Challenge Type Attribute
1 0 0 0 61 NAS-Port-Type
1 0 0 0 80 Message-Authenticator
0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector
1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA
0 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address
0 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI
0-1 0 0 0 MIP6-HA-TYPE MIP6-HA
0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator
0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data
0 0 0 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp
0 0 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI
0 0 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type
0 0 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode
0 0 0 0 MIP6-NONCE-TYPE MIP6-Nonce
Table of attribute for MIPv6 Authentication Protocol:
Request Accept Reject Challenge Type Attribute
1 0 0 0 61 NAS-Port-Type
0-1 0 0 0 80 Message-Authenticator
0-1 0-1 0 0 MIP6-FV-TYPE MIP6-Feature-Vector
1 0-1 0 0 MIP6-HOA-TYPE MIP6-HOA
1 0 0 0 MIP6-CAREOF-ADDRESS-TYPE MIP6-Careof-Address
0-1 0 0 0 MIP6-MN-AAA-SPI-TYPE MIP6-MN-AAA-SPI
1 0 0 0 MIP6-HA-TYPE MIP6-HA
0-1 0 0 0 MIP6-AUTHENTICATOR-TYPE MIP6-Authenticator
0-1 0 0 0 MIP6-MAC-MOBILITY-DATA-TYPE MIP6-MAC-Mobility-Data
0-1 0 0-1[x] 0 MIP6-TIMESTAMP-TYPE MIP6-Timestamp
0 1 0 0 MIP6-MN-HA-SPI-TYPE MIP6-MN-HA-SPI
0 1 0 0 MIP6-ALGORITH-TYPE MIP6-Algorithm-Type
0 1 0 0 MIP6-REPLY-MODE MIP6-Replay-Mode
0 1 0 0 MIP6-NONCE-TYPE MIP6-Nonce
[x] THIS IS A PROBLEM. CANT HAVE ATTRIBS IN REJECT.
As used in accounting packets:
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-FQDN-TYPE MIP6-HA-FQDN 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 0 0 MIP6-DNS-MO-TYPE MIP6-DNS-MO Attribute
]]></artwork>
</figure>
</t>
</section>
<section title="Diameter Considerations">
<t>When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the
attributes are as follows:</t>
<t>
<figure>
<artwork><![CDATA[
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
MIP6-HA Address | M | P | | V | Y |
MIP6-HA-FQDN UTF8String | M | P | | V | Y |
MIP6-HL-Prefix OctetString| M | P | | V | Y |
MIP6-HOA Address | M | P | | V | Y |
MIP6-DNS-MO OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
]]></artwork>
</figure>
</t>
<t>Other than MIP6-HA and HOA-IPv6, the attributes in this specification
have no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
they are copied as is, except for changes relating to headers,
alignment, and padding. See also <xref target="RFC3588"/> Section 4.1 and <xref target="RFC4005"/>
Section 9. MIP6-HA and HOA-IPv6 must be translated between
their RADIUS representation of String to a Diameter Address format
which requires that the AddressType field be set to 2 for IP6 (IP version 6)
</t>
<t>What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request <xref target="RFC4005"/> or Diameter-EAP-Request <xref target="RFC4072"/>.
What is said about Access-Challenge applies in Diameter to AA-Answer <xref target="RFC4005"/>
or Diameter-EAP-Answer <xref target="RFC4072"/> with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.</t>
<t>What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure.</t>
<t>What is said about Accounting-Request applies to Diameter Accounting-
Request <xref target="RFC4005"/> as well.</t>
</section>
<section title="Security Considerations">
<t> 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 server should only assign these values to a user who is
authorized for Mobile IPv6 service (this check could be performed
with the user's subscription profile in the Home Network). </t>
<t> The NAS and the HA to the RADIUS server transactions must be
adequately secured. Otherwise there is a possibility that the user
may receive fraudulent values from a rogue RADIUS server potentially
hijacking the user's Mobile IPv6 session. </t>
<t> These new attributes do not introduce additional security
considerations besides the ones identified in <xref
target="RFC2865"/>. </t>
</section>
<section title="IANA Considerations">
<section title="Registration of new AVPs">
<t> This specification defines the following new RADIUS attributes:
<list style="hanging">
<t> MIP6-Feature-Vector is set to MIP6-FV-TYPE </t>
<t> MIP6-HA is set to MIP6-HA-TYPE </t>
<t> MIP6-HA-FQDN is set to MIP6-HA-FQDN-TYPE</t>
<t> MIP6-HL-Prefix is set to MIP6-HL-PREFIX-TYPE </t>
<t> MIP6-HOA is set to MIP6-HOsA-TYPE </t>
<t> MIP6-DNS-MO is set to MIP6-DNS-MO-TYPE </t>
</list></t>
</section>
<section title="New Registry: Mobility Capability">
<t> For MIP6-FV-TYPE flag values must be generated:</t>
<t>
<figure>
<artwork><![CDATA[
Token | Value | Description
----------------------------------+----------------------+------------
MIP6_INTEGRATED | 0x0000000000000001 | [RFC TBD]
LOCAL_HOME_AGENT_ASSIGNMENT | 0x0000000000000002 | [RFC TBD]
Available for Assignment via IANA | 2^x |
]]></artwork> </figure> </t>
<t>Allocation rule: Only numeric values that are 2^x (power of
two) are allowed based on the allocation policy described
below.</t>
<t>Following the policies outlined in [1] new values with a
description of their semantic for usage with the
MIP6-Feature-Vector AVP together with a Token will be assigned
after Expert Review initiated by the O&M Area Directors in
consultation with the DIME working group chairs or the working
group chairs of a designated successor working group. Updates
can be provided based on expert approval only. A designated
expert will be appointed by the O&M Area Directors. No mechanism
to mark entries as "deprecated" is envisioned. Based on expert
approval it is possible to delete entries from the registry.</t>
</section>
<section title="Addition of existing values">
<t> A new value HA6(IANA-TBD1) MUST be assigned to NAS-Port-Type(61)</t>
</section>
</section>
<section title="Acknowledgements">
<t> We would like to thank the following individuals for their review and constructive
comments during the development of this document: </t>
<t> Florian Kohlmayer, Mark Watson, Jayshree Bharatia, Dimiter Milushev, Andreas
Pashalidis, Rafa Marin Lopez and Pasi Eronen. </t>
</section>
</middle>
<back>
<references title="Normative References"> &rfc2104; &rfc2119; &rfc2548; &rfc2865; &rfc2866; &rfc2868; &rfc3579; &rfc3588; &rfc3748;
&I-D.ietf-mip6-bootstrapping-split; &I-D.ietf-mip6-bootstrapping-integrated-dhc; &I-D.patel-mip6-rfc4285bis;
&I-D.zorn-radius-logoff;
</references>
<references title="Informative References">
&rfc1035;
&rfc2136;
&rfc3315; &rfc3344; &rfc3736; &rfc3753; &rfc3775; &rfc3776;
&rfc4005; &rfc4033; &rfc4283; &rfc4072; &rfc4306; &rfc4877;
&rfc5176;
&I-D.ietf-mip6-aaa-ha-goals;
&I-D.ietf-mip6-ikev2-ipsec; &rfc4640;
&I-D.ietf-dime-mip6-split;
&I-D.ietf-dime-mip6-integrated;
&I-D.ietf-mip6-hiopt;
</references>
</back>
<!--
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Pasi.Eronen@nokia.com
Sent: Wednesday, August 23, 2006 9:38 AM
To: radiusext@ops.ietf.org
Cc: kchowdhury@starentnetworks.com
Subject: Issue: Review of draft-chowdhury-mip6-radius-02
1) The document should give all new attributes short names that don't contain spaces (e.g. "MIP6-Home-Link-Prefix" or just "Home-Link-Prefix").
[Avi] Sounds like a good idea. Consistant with RADIUS. Also there seems to be inconsistant use of RADIUS attributes.
ASSIGNED-HA-ADDR-TYPE -> MIP6-HA (do we need Assigned?)
ASSIGNED-HA-FQDN-TYPE -> MIP6-HA-FQDN (like NAS-ID)
ASSIGNED-HL-TYPE -> MIP6-HL-Prefix
ASSIGNED-HOA-TYPE -> MIP6-HOA
DNS-UPDATE-TYPE -> DNS-Update-MO
2) Section 5: "The attributes MAY be present in the Access-Accept and the Accounting-Request." The accounting part is too ambiguous;
does e.g. requesting DNS update really make sense for accounting messages?
At the very least, the document should explicitly say what is included in accounting messages and what it means.
[avi] The following attributes MAY be included in RADIUS Accounting Packets:
MIP6-HA so that backoffice may know which is the serving HA for this session.
MIP6-HA-FQDN same reason as above (one or the other or both maybe used)
MIP6-HOA so that the backoffice may know the IP address of the MN.
I don’t think link prefix or DNS-Update would ever be required.
3) Section 5.2: This attribute should use the same data type as other attributes containing FQDNs (i.e., just the FQDN, without the zeroes in the beginning).
[avi] I agree.
4) Section 5.3: This attribute should use the same data type as other attributes containing IPv6 prefixes (e.g. Framed-IPv6-Prefix in RFC 3162).
[avi] The difference is Prefix-Length. Here is 3162:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
97 for Framed-IPv6-Prefix
Length
At least 4 and no larger than 20.
Reserved
This field, which is reserved and MUST be present, is always set
to zero.
Prefix-Length
The length of the prefix, in bits. At least 0 and no larger than
128.
Prefix
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.
5) Section 5.5: This section should describe that the status code field uses values defined in "draft-ietf-mip6-bootstrapping-split-02";
now it gives the impression that totally number space is created (but doesn't give any IANA considerations on how to manage it).
[avi] Seems reasonable. But the comment should be against the draft-ietf-mip6-bootstrapping-split-02 because this is where it is defined.
6) Section 5.5 first says "response to the request MAY not carry a FQDN value" but then changes its mind "The data field MUST contain a FQDN".
If we don’t use two attributes as suggested by comment 7 then reword:
FQDN of the MN:
The data field MUST contain a FQDN as described in [9].
TO:
In an Access-Request the data field MUST contain a FQDN. In an Access-Accept the FQDN MAY contain a FQDN. FQDN is as specified in [9].
7) Section 5.5: This attribute should probably be split to 2..3 separate attributes (e.g. DNS-Update-FQDN and DNS-Update-Result); this would
be better in line with other recent RADIUS documents.
[avi] Okay. BTW CUI didnt do this. If we try to econmomize radius attributes then lets not do this. Otherwize why not.
8) Section 5: Suggest rephrasing "All bits set to 0" to "The bits MUST be initialized to zero by the sender, and MUST be ignored by the receiver."
[Avi] Seems okay.
9) Section 8: According to Section 5, the first four attributes are sent by the RADIUS server to the NAS, so the first column should be "0" instead of "0-1" (alternatively, Section 5 needs to specify what these attributes mean in Access-Requests).
Here is the table:
Request Accept Reject Challenge Attribute
0-1 0-1 0 0 HA Address Attribute
0-1 0-1 0 0 MIP6-HA-FQDN Attribute
0-1 0-1 0 0 MIP6-HL-Prefix Attribute
0-1 0-1 0 0 MIP6-HOA Attribute
0-1 0-1 0 0 MIP6-DNS-MO
Attribute
So either we make Request column to 0 instead of 0-1 for the first attributes.
But there is a purpose for having these attributes sent to the RADIUS server.
They can act as a hint to the RADIUS server that a) the NAS supports dynamic HA assignment and b)
they can be a suggestion as to what values should be used when the RADIUS server does assing the
HA in the visited network. The RADIUS server may use these values or may use other values.
10) Section 8: The table should probably include accounting messages and CoA-Request as well.
[avi] Accounting table
Request Interim Stop Type Attribute
0-1 0-1 0-1 TBD HA Address Attribute
0-1 0-1 0-1 TBD MIP6-HA-FQDN Attribute
0 0 0 TBD MIP6-HL-Prefix Attribute
0-1 0-1 0-1 TBD MIP6-HOA Attribute
0 0 0 TBD MIP6-DNS-MO
Attribute
11) For the split scenario, the document should define what to put in Service-Type and NAS-Port-Type attributes
(and maybe also Calling-Station-Id and Called-Station-Id).
[avi]
Service Type we should not touch
NAS-Port-Type should be HA-MIPv6
Not sure about calling Station-ID or Called Station id, I don’t think we should specify anything for those. SDOs or specific deployements may use those attributes.
12) The document talks about doing EAP authentication over RADIUS, but never mentions RFC 3579?
[avi] Add an informational reference to RFC 3579.
13) The document should either point to RFC 2548, or explicitly say that this document does not contain an interoperable solution for the split scenario,
since it does not specify (either here or by referencing some other document) how to send the MSK from the RADIUS server to the HA.
[Avi] What do you mean by that? In the split scenario this document does not send an MSK to the HA.
[Avi] I don’t think we should specify how the MSK is carried. The specific EAP methods do that see EAP-AKA EAP-TLSbis etc...
We could say in the absence of a method to transport MSK, the method specified by RFC 2548 SHOULD be used.
Note that that is not enough, since we have to specify what goes in the SEND KEY and RECEIVE KEY.
14) The document should probably have at least informative reference to RFC 4306.
[avi] Sure.
15) And last (but not least, as everyone who has followed RADEXT knows :-): the document does not have a Diameter considerations section.
From vlan06.txt Modified for our purposes.
Diameter Considerations
When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the
attributes are as follows:
+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
| | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
-------------------------------|----+-----+----+-----|----|
HA-IPv6 Address | M | P | | V | Y |
HA-FQDN UTF8String | M | P | | V | Y |
Home-Link-Prefix OctetString| M | P | | V | Y |
HOA-IPv6 Address | M | P | | V | Y |
DNS-UPDATE-TYPE OctetString| M | P | | V | Y |
-------------------------------|----+-----+----+-----|----|
Other than HA-IPv6 and HOA-IPv6, the attributes in this specification
have no special translation
requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
they are copied as is, except for changes relating to headers,
alignment, and padding. See also [RFC 3588] Section 4.1 and [RFC
4005] Section 9. HA-IPv6 and HOA-IPv6 must be translated between
their RADIUS representation of String to a Diameter Address format
which requires that the AddressType field be set to 2 for IP6 (IP version 6)
What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [RFC 4005] or Diameter-EAP-Request [RFC 4072]. What is
said about Access-Challenge applies in Diameter to AA-Answer [RFC
4005] or Diameter-EAP-Answer [RFC 4072] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH.
What is said about Access-Accept applies in Diameter to AA-Answer or
Diameter-EAP-Answer messages that indicate success. Similarly, what
is said about RADIUS Access-Reject packets applies in Diameter to AA-
Answer or Diameter-EAP-Answer messages that indicate failure.
What is said about COA-Request applies in Diameter to Re-Auth-Request
[RFC 4005].
What is said about Accounting-Request applies to Diameter Accounting-
Request [RFC 4005] as well.
Best regards,
Pasi
Pasi follow on
Julians review:
ulien,
Thanx for the review.
Regarding your question:
> I have one general question:
>
> In the split scenario, how does the RADIUS server know that it is
> performing AAA for mip6 service and not for network access ?
>
> (FYI, we encounter this problem in the DiME WG and we'll solve this by
> using a different Application ID.)
In RADIUS we don't have an application id therefore the AAA server determines the context of the packet it receives by examining the attributes.
For example:
The presence of an attribute in an Access-Request packet that only an HA or even more specifically a MIPv6 HA would provide in this case: MIP6-HA Attribute. But this attribute is not a required attribute.
NAS-Port-Type: can be set to a value such as HA-IPv6. This is the most reliable attribute but we need IANA to assign the attribute.
The AAA may also know the context by using the NAS-IP and/or the NAS-Ids, that is, it will know that a particular NAS-IP is an HA vs a NAS. This obivously doesn't scale to large deployments.
I think we need to update the draft to cover this discussion and request IANA for a NAS-Port-Type.
---------------------------------
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@gmail.com]
> Sent: Monday, February 19, 2007 4:46 AM
> To: mip6@ietf.org
> Subject: [Mip6] draft-ietf-mip6-radius-01.txt
>
> Hi,
>
> I quickly read the document called: draft-ietf-mip6-radius-01.txt
>
> I have one general question:
>
> In the split scenario, how does the RADIUS server know that it is
> performing AAA for mip6 service and not for network access ?
>
> (FYI, we encounter this problem in the DiME WG and we'll solve this
> by using a different Application ID.)
>
> Some editorials comments:
>
> section 3.2:
>
> "Since scenario (1) is the more generic..."
>
> I think you wanted to say "scenario (2)
>
> section 4.2
>
> s/HOA/HA
>
> section 5
>
> I think you can add Access-Request message since the MIP6-DNS-MO may
be
> sent in this message (if I understood well).
>
> My 2 cents,
>
> Julien
>
> _______________________________________________
> Mip6 mailing list
> Mip6@ietf.org
> https://www1.ietf.org/mailman/listinfo/mip6
-->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:12 |