draft-ietf-mext-mip6-tls-00.txt   draft-ietf-mext-mip6-tls-01.txt 
Mobility Extensions (MEXT) J. Korhonen, Ed. Mobility Extensions (MEXT) J. Korhonen, Ed.
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Updates: 3775 (if approved) B. Patil Updates: 6275 (if approved) B. Patil
Intended status: Experimental Nokia Intended status: Experimental Nokia
Expires: September 13, 2011 H. Tschofenig Expires: March 16, 2012 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
D. Kroeselberg D. Kroeselberg
Siemens Siemens
March 12, 2011 September 13, 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-00.txt draft-ietf-mext-mip6-tls-01.txt
Abstract Abstract
RFC 3775 Mobile IPv6 signaling between the mobile node and home agent RFC 6275 Mobile IPv6 signaling between the mobile node and home agent
is secured using IPsec. The security association between a mobile is secured using IPsec. The security association between a mobile
node and the home agent is established using IKEv1 or IKEv2. The node and the home agent is established using IKEv1 or IKEv2. The
security model specified for Mobile IPv6, which relies on IKE/IPsec, security model specified for Mobile IPv6, which relies on IKE/IPsec,
requires interaction between the Mobile IPv6 protocol part of the IP requires interaction between the Mobile IPv6 protocol part of the IP
stack and the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based stack and the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based
security architectures makes implementation and deployment of the security architectures makes implementation and deployment of the
protocol infeasible for numerous reasons. This document updates RFC protocol infeasible for numerous reasons. This document updates RFC
3775 and proposes an alternate security framework, which relies on 6275 and proposes an alternate security framework, which relies on
Transport Layer Security for establishing keying material and other Transport Layer Security for establishing keying material and other
bootstrapping parameters required to protect Mobile IPv6 signaling bootstrapping parameters required to protect Mobile IPv6 signaling
and data traffic between the mobile node and home agent. 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 September 13, 2011. This Internet-Draft will expire on March 16, 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17
5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18
5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18
5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18
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. 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 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29
8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29
8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . . . 30
9.3. Protection of MN and HA Communication . . . . . . . . . . 32 9.3. Protection of MN and HA Communication . . . . . . . . . . 33
9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 34 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . . 35 11.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between
a mobile node (MN) and home agent (HA) are secured by IPsec a mobile node (MN) and home agent (HA) are secured by IPsec
[RFC4301]. The current Mobile IPv6 security architecture is [RFC4301]. The current Mobile IPv6 security architecture is
specified in [RFC3776] and [RFC4877]. This security model requires a specified in [RFC3776] and [RFC4877]. This security model requires a
tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/
IPsec part of the IP stack. Implementation experience has shown that IPsec part of the IP stack. Implementation experience has shown that
the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The
issues with the IKE(v2)/IPsec based security architecture are issues with the IKE(v2)/IPsec based security architecture are
documented in [I-D.patil-mext-mip6issueswithipsec]. 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
skipping to change at page 11, line 14 skipping to change at page 11, line 14
related information. related information.
4.5. Protecting Traffic Between Mobile Node and Home Agent 4.5. Protecting Traffic Between Mobile Node and Home Agent
The same integrity and confidentiality algorithms MUST be used to The same integrity and confidentiality algorithms MUST be used to
protect both binding management messages and reverse tunneled user protect both binding management messages and reverse tunneled user
data traffic between the MN and the HA. Generally, all binding data traffic between the MN and the HA. Generally, all binding
management messages (BUs, BAs and so on) MUST be integrity protected management messages (BUs, BAs and so on) MUST be integrity protected
and SHOULD be confidentially protected. The reverse tunneled user and SHOULD be confidentially protected. The reverse tunneled user
data traffic SHOULD be equivalently protected. Generally, the data traffic SHOULD be equivalently protected. Generally, the
requirements stated in [RFC3775] concerning the protection of the requirements stated in [RFC6275] concerning the protection of the
traffic between the MN and the HA also apply to the mechanisms traffic between the MN and the HA also apply to the mechanisms
defined by this specification. defined by this specification.
5. Mobile Node to Home Agent Controller Communication 5. Mobile Node to Home Agent Controller Communication
5.1. Request-response Message Framing over TLS-tunnel 5.1. Request-response Message Framing over TLS-tunnel
The MN and the HAC communicate with each other using a simple lock- The MN and the HAC communicate with each other using a simple lock-
step request-response protocol that is run inside the protected TLS- step request-response protocol that is run inside the protected TLS-
tunnel. A generic message container framing for the request messages tunnel. A generic message container framing for the request messages
skipping to change at page 24, line 40 skipping to change at page 24, line 40
and the HA ends initiate very different numbers of messages, the and the HA ends initiate very different numbers of messages, the
Sequence Numbers in the two directions can be very different. In a Sequence Numbers in the two directions can be very different. In a
case encryption is not used, the Sequence Number MUST be set to 0 case encryption is not used, the Sequence Number MUST be set to 0
(zero). Note that the HA SHOULD initiate a re-establishement of the (zero). Note that the HA SHOULD initiate a re-establishement of the
SA before any of the Sequence Number cycle. SA before any of the Sequence Number cycle.
Finally, the Sequence Number field is followed by the data portion, Finally, the Sequence Number field is followed by the data portion,
whose content is identified by the Packet Type. The data portion may whose content is identified by the Packet Type. The data portion may
be protected. be protected.
6.2. Security Parameter Index 6.2. PType and Security Parameter Index
The SPI is a 32-bit field, where the first 4 bits indicate the Packet The PType is a 4-bit field that indicates the Packet Type (PType) of
Type (PType) of the UDP encapsulated packet. The SPI value itself the UDP encapsulated packet. The PType is followed by a a 28-bit SPI
consists of the remaining 28-bit of the SPI field. The SPI field is value. The PType and the SPI fields are treated as one 32-bit field
treated as one 32-bit field during the integrity protection during the integrity protection calculation.
calculation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PType | SPI | | PType | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Security Parameter Index with Packet Type Figure 6: Security Parameter Index with Packet Type
A SPI value of 0 (zero) indicates a plaintext packet. If the packet A SPI value of 0 (zero) indicates a plaintext packet. If the packet
is integrity protected or both integrity protected and encrypted, the is integrity protected or both integrity protected and encrypted, the
SPI value MUST be different from 0. SPI value MUST be different from 0. When the SPI value is set to 0,
then the PType MUST also be 0.
6.3. Binding Management Message Formats 6.3. Binding Management Message Formats
The binding management messages that are only meant to be exchanged The binding management messages that are only meant to be exchanged
between the MN and the HA MUST be integrity protected and MAY be between the MN and the HA MUST be integrity protected and MAY be
encrypted. They MUST use the packet format shown in Figure 7. All encrypted. They MUST use the packet format shown in Figure 7. All
packets that are specific to the Mobile IPv6 protocol and contain a packets that are specific to the Mobile IPv6 protocol and contain a
Mobility Header (as defined in Section 6.1.1. of RFC 3775) SHOULD use Mobility Header (as defined in Section 6.1.1. of RFC 6275) SHOULD use
the packet format shown in Figure 7. (This means that some Mobile the packet format shown in Figure 7. (This means that some Mobile
IPv6 mobility management messages, such as the HoTI message, as IPv6 mobility management messages, such as the HoTI message, as
treated as data packets and using encapsulation described in treated as data packets and using encapsulation described in
Section 6.4). Section 6.4).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
skipping to change at page 26, line 36 skipping to change at page 26, line 36
| | Pad Length | Next Header | v v | | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) | | Integrity Check Value-ICV (variable) |
: : : :
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: UDP Encapsulated Binding Management Message Format Figure 7: UDP Encapsulated Binding Management Message Format
The PType value 8 (eight) identifies that the UDP encapsulated packet The PType value 8 (eight) identifies that the UDP encapsulated packet
contains a RFC 3775 defined Mobility Header and other relevant IPv6 contains a RFC 6275 defined Mobility Header and other relevant IPv6
extension headers. Note, there is no additional IP header inside the extension headers. Note, there is no additional IP header inside the
encapsulated part. The Next Header field MUST be set to value of the encapsulated part. The Next Header field MUST be set to value of the
first encapsulated header. The encapsulated headers follow the first encapsulated header. The encapsulated headers follow the
natural IPv6 and Mobile IPv6 extension header alignment and natural IPv6 and Mobile IPv6 extension header alignment and
formatting rules. formatting rules.
The Padding, Pad Length, Next Header and ICV fields follow the rules The Padding, Pad Length, Next Header and ICV fields follow the rules
of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this
document. For a SPI value of 0 (zero) that indicates an unprotected document. For a SPI value of 0 (zero) that indicates an unprotected
packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT
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 treatment of MN-CN route optimization is outside the scope of The MN-CN route optimization is to be defined in a future revision of
this document. this specification.
[Discussion: the route optimization can be done in two ways: 1) using
the return routability procedure described in [RFC6275] or 2)
directly between the MN and the CN. Obviously the first approach has
already been verified from the security considerations and procedures
point of view (both proving the Home Address ownership and verifying
the reachability). However, there are several gaps in scope of this
specification. 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 we 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. If the CN were to implement a HAC and the HAC
could also authenticate the MN (either using pre-shared secrets or
using EAP+AAA against MN's home realm AAA server), then we could
actually allow the MN and the CN to setup secured communication
without doing the return routability test. These are the issues and
choices to consider.]
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 33, line 31 skipping to change at page 34, line 6
Key Control: The keying material established during the MN-HAC Key Control: The keying material established during the MN-HAC
protocol exchange for subsequent protection of the MN-HA protocol exchange for subsequent protection of the MN-HA
communication is created by the HA and therefore no joint key communication is created by the HA and therefore no joint key
control is provided for it. control is provided for it.
Key Naming: For the MN-HA communication the security associations Key Naming: For the MN-HA communication the security associations
are indexed with the help of the SPI and additionally based on the are indexed with the help of the SPI and additionally based on the
direction (in-bound communication or out-bound communication). direction (in-bound communication or out-bound communication).
Lifetime: The lifetime of the MN-HA security associations is based Lifetime: The lifetime of the MN-HA security associations is based
on the value in the mip6-sa-validity-end HTTP header field on the value in the mip6-sa-validity-end header field exchanged
exchanged during the MN-HAC exchange. The HAC controls the SA during the MN-HAC exchange. The HAC controls the SA lifetime.
lifetime.
Denial of Service Resistance: For the communication between the MN Denial of Service Resistance: For the communication between the MN
and the HA there are no heavy cryptographic operations (such as and the HA there are no heavy cryptographic operations (such as
public key computations). As such, there are no DoS concerns. public key computations). As such, there are no DoS concerns.
Session Independence: Sessions are independent from each other when Session Independence: Sessions are independent from each other when
new keys are created by via the MN-HAC protocol. A new MN-HAC new keys are created by via the MN-HAC protocol. A new MN-HAC
protocol run produces fresh and unique keying material for protocol run produces fresh and unique keying material for
protection of the MN-HA communication. protection of the MN-HA communication.
skipping to change at page 34, line 39 skipping to change at page 35, line 12
are exchanged between the MN and the HA (in both directions as two are exchanged between the MN and the HA (in both directions as two
different keys are used). different keys are used).
9.4. AAA Interworking 9.4. AAA Interworking
The AAA backend infrastructure interworking is not defined in this The AAA backend infrastructure interworking is not defined in this
document and therefore out-of-scope. document and therefore out-of-scope.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Pasi Eronen, Domagoj Premec, and The authors would like to thank Pasi Eronen, Domagoj Premec, Julien
Christian Bauer for their comments. Laganier and Christian Bauer for their comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
skipping to change at page 35, line 22 skipping to change at page 35, line 42
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
and Its Use With IPsec", RFC 3566, September 2003. and Its Use With IPsec", RFC 3566, September 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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
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., Premec, D., Perkins, C., and H. Tschofenig,
"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-03
(work in progress), July 2010. (work in progress), July 2010.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
skipping to change at page 37, line 31 skipping to change at page 38, line 4
Email: basavaraj.patil@nokia.com Email: basavaraj.patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Dirk Kroeselberg Dirk Kroeselberg
Siemens Siemens
Email: dirk.kroeselberg@siemens.com Email: dirk.kroeselberg@siemens.com
 End of changes. 23 change blocks. 
40 lines changed or deleted 58 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/