draft-ietf-mext-mip6-tls-01.txt   draft-ietf-mext-mip6-tls-02.txt 
Mobility Extensions (MEXT) J. Korhonen, Ed. Mobility Extensions (MEXT) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Updates: 6275 (if approved) B. Patil Intended status: Experimental B. Patil
Intended status: Experimental Nokia Expires: April 13, 2012 Nokia
Expires: March 16, 2012 H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
September 13, 2011 October 11, 2011
Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Transport Layer Security-based Mobile IPv6 Security Framework for Mobile
Node to Home Agent Communication Node to Home Agent Communication
draft-ietf-mext-mip6-tls-01.txt draft-ietf-mext-mip6-tls-02.txt
Abstract Abstract
RFC 6275 Mobile IPv6 signaling between the mobile node and home agent Mobile IPv6 signaling between a mobile node and its home agent is
is secured using IPsec. The security association between a mobile secured using IPsec. The security association between a mobile node
node and the home agent is established using IKEv1 or IKEv2. The and the home agent is established using IKEv1 or IKEv2. The security
security model specified for Mobile IPv6, which relies on IKE/IPsec, model specified for Mobile IPv6, which relies on IKE/IPsec, requires
requires interaction between the Mobile IPv6 protocol part of the IP interaction between the Mobile IPv6 protocol component and the IKE/
stack and the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based IPsec module of the IP stack. This document proposes an alternate
security architectures makes implementation and deployment of the security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which
protocol infeasible for numerous reasons. This document updates RFC relies on Transport Layer Security for establishing keying material
6275 and proposes an alternate security framework, which relies on and other bootstrapping parameters required to protect Mobile IPv6
Transport Layer Security for establishing keying material and other signaling and data traffic between the mobile node and home agent.
bootstrapping parameters required to protect Mobile IPv6 signaling
and data traffic between the mobile node and home agent.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 16, 2012. This Internet-Draft will expire on April 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 14 skipping to change at page 3, line 13
5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19
5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19
5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19
5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21
6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2. PType and Security Parameter Index . . . . . . . . . . . . 24 6.2. PType and Security Parameter Index . . . . . . . . . . . . 24
6.3. Binding Management Message Formats . . . . . . . . . . . . 25 6.3. Binding Management Message Formats . . . . . . . . . . . . 25
6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27
7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7.1. Replicating RFC6275 Route Optimization . . . . . . . . . . 29
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 7.2. Enhanced Route Optimization with Home Agent-less
8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 Operation . . . . . . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 30
8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 30
8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 31
9.2. Authentication and Key Exchange executed between the 9.2. Authentication and Key Exchange executed between the
MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30 MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 31
9.3. Protection of MN and HA Communication . . . . . . . . . . 33 9.3. Protection of MN and HA Communication . . . . . . . . . . 33
9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between Mobile IPv6 signaling as specified in RFC6275 [RFC6275], and
a mobile node (MN) and home agent (HA) are secured by IPsec optionally user traffic, between a mobile node (MN) and home agent
[RFC4301]. The current Mobile IPv6 security architecture is (HA) are secured by IPsec [RFC4301]. The current Mobile IPv6
specified in [RFC3776] and [RFC4877]. This security model requires a security architecture is specified in [RFC3776] and [RFC4877]. This
tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ security model requires a tight coupling between the Mobile IPv6
IPsec part of the IP stack. Implementation experience has shown that protocol part and the IKE(v2)/IPsec part of the IP stack.
the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The Implementation experience has shown that the use of IKE(v2)/IPsec
issues with the IKE(v2)/IPsec based security architecture are with Mobile IPv6 is fairly complex. The issues with the IKE(v2)/
documented in [I-D.patil-mext-mip6issueswithipsec]. IPsec based security architecture are documented in
[I-D.patil-mext-mip6issueswithipsec].
This document proposes an alternate security framework for Mobile This document proposes an alternate security framework for Mobile
IPv6. Transport Layer Security (TLS) [RFC5246] is widely implemented IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify
in almost all major operating systems and extensively used. Instead implementations as well as make it easy to deploy the protocol
of using IKEv2, the security framework proposed in this document is without compromising on security. Transport Layer Security (TLS)
based on TLS protected messages to exchange keys and bootstrapping [RFC5246] is widely implemented in almost all major operating systems
parameters between the Mobile Node and a new functional entity called and extensively used. Instead of using IKEv2, the security framework
as the Home Agent Controller (HAC). The Mobile IPv6 signaling proposed in this document is based on TLS protected messages to
between the mobile node and home agent is subsequently secured using exchange keys and bootstrapping parameters between the Mobile Node
the resulting keys and negotiated cipher suite. The HAC can be co- and a new functional entity called as the Home Agent Controller
located with the HA, or can be an independent entity. For the latter (HAC). The Mobile IPv6 signaling between the mobile node and home
case, communication between HAC and HA is not defined by this agent is subsequently secured using the resulting keys and negotiated
document. The Diameter protocol can be used between the HA and HAC cipher suite. The HAC can be co-located with the HA, or can be an
when the two entities are not collocated. independent entity. For the latter case, communication between HAC
and HA is not defined by this document. The Diameter protocol can be
used between the HA and HAC when the two entities are not collocated.
The primary advantage of using TLS based establishment of Mobile IP6 The primary advantage of using TLS based establishment of Mobile IP6
security associations compared to IKEv2 is the ease of implementation security associations compared to IKEv2 is the ease of implementation
while providing equivalent level of security. For the protection of while providing equivalent level of security. For the protection of
Mobile IPv6 signaling messages a solution is provided that decouples Mobile IPv6 signaling messages a solution is provided that decouples
Mobile IPv6 protection from regular IPsec operation to reduce Mobile IPv6 protection from regular IPsec operation to reduce
complexity in Mobile IP client implementations. complexity in Mobile IP client implementations.
The security framework proposed in this document is not intended to The security framework proposed in this document is not intended to
replace the currently specified architecture which relies on IPsec replace the currently specified architecture which relies on IPsec
skipping to change at page 5, line 10 skipping to change at page 5, line 10
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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 [RFC2119]. document are to be interpreted as described in [RFC2119].
Home Agent Controller (HAC): Home Agent Controller (HAC):
The home agent controller is a node responsible for bootstrapping The home agent controller is a node responsible for bootstrapping
Mobile IPv6 security associations between a mobile node and one or Mobile IPv6 security associations between a mobile node and one or
more home agents. The home agent controller also provides key more home agents. The home agent controller also provides key
distribution to both mobile nodes and home agents. Optionally, distribution to both mobile nodes and home agents. Mobile IPv6
Mobile IPv6 bootstrapping can be done in addition to the security bootstrapping is also performed by the HA in addition to the
association bootstrapping between the mobile node and home agent security association bootstrapping between the mobile node and
controller. home agent controller.
Binding Management Messages: Binding Management Messages:
Mobile IPv6 signaling messages between a mobile node and a home Mobile IPv6 signaling messages between a mobile node and a home
agent, correspondent node or mobility access point to manage the agent, correspondent node or mobility access point to manage the
bindings are referred to as binding management messages. Binding bindings are referred to as binding management messages. Binding
Updates and Binding Acknowledgement messages are examples of Updates and Binding Acknowledgement messages are examples of
binding management messages. binding management messages.
3. Background 3. Background
Work on the design and specification of Mobile IPv6 has been done Work on the design and specification of Mobile IPv6 has been done
since the late 90s. The security architecture of Mobile IPv6 was since the late 90s. The security architecture of Mobile IPv6 was
based on the understanding that IPsec is an inherent and integral based on the understanding that IPsec is an inherent and integral
part of the IPv6 stack and any protocol that needs security should part of the IPv6 stack and any protocol that needs security should
use IPsec unless there is a good reason not to. As a result of this use IPsec unless there is a good reason not to. As a result of this
mindset the Mobile IP6 protocol relied on the use of IPsec for mindset the Mobile IP6 protocol relied on the use of IPsec for
security between the MN and HA. It should be noted that Mobile IPv4 security between the MN and HA. While reuse of security components
[RFC5944] for example does not use IPsec for security and instead has that are part of the IP stack is a good objective, in the case of
specified its own security solution. Mobile IPv4 has been Mobile IPv6 implementation complexity increases quite dramatically.
implemented and deployed on a reasonably large scale and the security It should be noted that Mobile IPv4 [RFC5944] for example does not
model has proven itself to be sound. use IPsec for security and instead has specified its own security
solution. Mobile IPv4 has been implemented and deployed on a
reasonably large scale and the security model has proven itself to be
sound.
Mobile IPv6 standardization was completed in 2005 along with the Mobile IPv6 standardization was completed in 2005 along with the
security architecture using IKE/IPsec specified in RFC 3776 security architecture using IKE/IPsec specified in RFC 3776
[RFC3776]. With the transition to IKEv2 [RFC5996], Mobile IP6 [RFC3776]. With the transition to IKEv2 [RFC5996], Mobile IP6
security has also been updated to rely on the use of IKEv2 [RFC4877]. security has also been updated to rely on the use of IKEv2 [RFC4877].
Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile
IPv6 [RFC5555] have identified the complexity of using IPsec and IPv6 [RFC5555] have identified the complexity of using IPsec and
IKEv2 in conjunction with Mobile IPv6. At an abstract level it can IKEv2 in conjunction with Mobile IPv6. At an abstract level it can
be said that implementing Mobile IPv6 with IPsec and IKEv2 is be said that implementing Mobile IPv6 with IPsec and IKEv2 is
possible only with modifications to the IPsec and IKEv2 components. possible only with modifications to the IPsec and IKEv2 components.
skipping to change at page 6, line 14 skipping to change at page 6, line 17
establishment of Mobile IPv6 security associations with reduced establishment of Mobile IPv6 security associations with reduced
implementation complexity, while maintaining an equivalent (to IKEv2/ implementation complexity, while maintaining an equivalent (to IKEv2/
IPsec) level of security. IPsec) level of security.
4. TLS-based Security Establishment 4. TLS-based Security Establishment
4.1. Overview 4.1. Overview
The security architecture proposed in this document relies on a The security architecture proposed in this document relies on a
secure TLS session established between the MN and the HAC for secure TLS session established between the MN and the HAC for
authentication and security association establishment. authentication and MN-HA security association bootstrapping.
Authentication of the HAC is done via standard TLS operation where Authentication of the HAC is done via standard TLS operation where
the HAC uses a TLS server certificate as credentials. MN the HAC uses a TLS server certificate as credentials. MN
authentication is done by the HAC via signaling messages that are authentication is done by the HAC via signaling messages that are
secured by the TLS connection. This can either be MN-only secured by the TLS connection. This can either be MN-only
authentication within the server-authenticated TLS channel, or mutual authentication within the server-authenticated TLS channel, or mutual
authentication between the MN and HAC. Upon successful completion of authentication between the MN and HAC. Upon successful completion of
authentication, the HAC generates keys which are delivered to the MN authentication, the HAC generates keys which are delivered to the MN
through the secure TLS channel. The same keys are also provided to through the secure TLS channel. The same keys are also provided to
the assigned HA. The HAC also provides the MN with MIP6 the assigned HA. The HAC also provides the MN with MIP6
bootstrapping information such as the address of the HA, the Home bootstrapping information such as the address of the HA, the Home
skipping to change at page 10, line 20 skipping to change at page 10, line 20
A monotonically increasing unsigned sequence number used in all A monotonically increasing unsigned sequence number used in all
protected packets exchanged between the MN and the HA in the same protected packets exchanged between the MN and the HA in the same
direction. Sequence numbers are maintained per direction, so each direction. Sequence numbers are maintained per direction, so each
SA includes two independent sequence numbers (MN -> HA, HA -> MN). SA includes two independent sequence numbers (MN -> HA, HA -> MN).
The initial sequence number for each direction MUST always be set The initial sequence number for each direction MUST always be set
to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing
beyond their maximum defined value. beyond their maximum defined value.
4.4. Bootstrapping of Additional Mobile IPv6 Parameters 4.4. Bootstrapping of Additional Mobile IPv6 Parameters
When the MN contacts the HAC to distribute of the security related When the MN contacts the HAC to distribute the security related
information, the HAC may also provision the MN with various Mobile information, the HAC may also provision the MN with various Mobile
IPv6 related bootstrapping information. Bootstrapping of the IPv6 related bootstrapping information. Bootstrapping of the
following information SHOULD at least be possible: following information SHOULD at least be possible:
Home Agent IP Address: Home Agent IP Address:
Concerns both IPv6 and IPv4 home agent addresses. Concerns both IPv6 and IPv4 home agent addresses.
Mobile IPv6 Service Port Number: Mobile IPv6 Service Port Number:
skipping to change at page 28, line 50 skipping to change at page 28, line 50
contains a plaintext tunneled IPv4/IPv6 user data packet. Also the contains a plaintext tunneled IPv4/IPv6 user data packet. Also the
SPI and the Sequence Number fields MUST be set to 0 (zero). SPI and the Sequence Number fields MUST be set to 0 (zero).
The source and destination IP addresses of the outer IP header (i.e., The source and destination IP addresses of the outer IP header (i.e.,
the src-addr and the dst-addr in Figure 9) use the current care-of the src-addr and the dst-addr in Figure 9) use the current care-of
address of the MN and the HA address. The plain text inner IP header address of the MN and the HA address. The plain text inner IP header
uses the home address of the MN and the CN address. uses the home address of the MN and the CN address.
7. Route Optimization 7. Route Optimization
The MN-CN route optimization is to be defined in a future revision of The MN-CN route optimization protocol functionality, related messages
this specification. and mobility options are out of scope of this specification. A
future specification may add route optimization functionality to the
Transport Layer Security-based Mobile IPv6 protocol.
[Discussion: the route optimization can be done in two ways: 1) using We discuss few possible route optimization approaches in the
the return routability procedure described in [RFC6275] or 2) following sections. The route optimization could be done in two
directly between the MN and the CN. Obviously the first approach has ways: 1) using the return routability procedure described in
already been verified from the security considerations and procedures [RFC6275] or 2) directly between the MN and the CN i.e. enhancing the
point of view (both proving the Home Address ownership and verifying route optimization also for Home Agent-less operation.
the reachability). However, there are several gaps in scope of this
specification. For instance, the binding management message Both discussed solution approaches share the same tunneling
encapsulation between the MN and the CN must be specified and how to considerations between the MN and the CN. When the MN sends UDP
reach a CN using an IPv4 address (following the trend in this encapsulated packets to the CN, those are destined to CN's CoA. That
specification we would use UDP encapsulated IPv6 and mobility headers implies, the inner tunneled packets would also have the same
as in Section 6.3). Another gap is the lack of SA between the MN and destination address as the outer tunneling packets. There should not
the CN, if the communication were to be protected. In order to be issues regarding the decapsulation and encapsulation as long as
enable the protection the CN should actually implement a HAC the inner tunneled packet does not have UDP payload with the same
function, which would then allow the MN and the CN to negotiate destination port that the CN uses for its MN-CN UDP tunnel.
required ciphersuites. If the CN were to implement a HAC and the HAC
could also authenticate the MN (either using pre-shared secrets or 7.1. Replicating RFC6275 Route Optimization
using EAP+AAA against MN's home realm AAA server), then we could
actually allow the MN and the CN to setup secured communication Obviously [RFC6275] approach has already been verified from the
without doing the return routability test. These are the issues and security considerations and procedures point of view. The existing
choices to consider.] protocol proves both the Home Address ownership and verifies the
reachability. However, there are several gaps in scope of this
specification (TLS-based solution). For instance, the binding
management message encapsulation between the MN and the CN must be
specified and how to reach a CN using an IPv4 address. Following the
trend in this specification that would use UDP encapsulated IPv6 and
mobility headers as in Section 6.3. Another gap is the lack of SA
between the MN and the CN, if the communication were to be protected.
In order to enable the protection the CN should actually implement a
HAC function, which would then allow the MN and the CN to negotiate
required ciphersuites.
7.2. Enhanced Route Optimization with Home Agent-less Operation
If the CN were to implement a HAC, then the HAC could also
authenticate the MN. Possible authentication methods include pre-
shared secrets, certificates or using EAP+AAA against MN's home realm
AAA server (assuming the AAA infrastructure is in place). That
approach could actually allow the MN and the CN to setup secured
communication without doing the return routability test and support
Home Agent-less operation of MNs. However, the prerequisite is that
the MN has at some point of time bootstrapped with its HA e.g. to
acquire the HoA.
The "bootstrapping" between the MN and the "CN HAC" would concern a
subset of parameter needed between the MN and the "HA HAC". For
example, there is no need to negotiate Home Addresses and such. The
main use would be establishing the SA and authenticating at least the
MN to the CN.
8. IANA Considerations 8. IANA Considerations
8.1. New Registry: Packet Type 8.1. New Registry: Packet Type
IANA is requested to create a new registry for the Packet Type as IANA is requested to create a new registry for the Packet Type as
described in Section 6.1. described in Section 6.1.
Packet Type | Value Packet Type | Value
----------------------------------+---------------------------------- ----------------------------------+----------------------------------
skipping to change at page 36, line 17 skipping to change at page 36, line 44
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
11.2. Informative References 11.2. Informative References
[I-D.patil-mext-mip6issueswithipsec] [I-D.patil-mext-mip6issueswithipsec]
Patil, B., Premec, D., Perkins, C., and H. Tschofenig, Patil, B., Perkins, C., Tschofenig, H., and D. Premec,
"Problems with the use of IPsec as the security protocol "Problems with the use of IPsec as the security protocol
for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-03 for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-04
(work in progress), July 2010. (work in progress), October 2011.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004. Home Agents", RFC 3776, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
 End of changes. 20 change blocks. 
80 lines changed or deleted 119 lines changed or added

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