One document matched: draft-korhonen-mext-mip6-altsec-00.txt
Mobility Extensions (MEXT) J. Korhonen
Internet-Draft Nokia Siemens Networks
Updates: 3775, 3775bis B. Patil
(if approved) Nokia
Intended status: Standards Track July 6, 2009
Expires: January 7, 2010
TLS-based Mobile IPv6 Security Framework
draft-korhonen-mext-mip6-altsec-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Mobile IPv6 signaling between the mobile node and home agent is
Korhonen & Patil Expires January 7, 2010 [Page 1]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
secured using IPsec. The security association between a mobile node
and the home agent is established using IKEv1 or IKEv2. The security
model specified for Mobile IPv6 which relies on IKE/IPsec requires
interaction between the Mobile IPv6 protocol part of the IP stack and
the IKE/IPsec part of the IP stack. Implementation and deployment
concerns exist with such a security architecture. This document
proposes an alternate security framework which relies on the reuse of
Transport Layer Security for securing Mobile IPv6 signaling and IP
traffic between the mobile node and home agent.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TLS-based Security Framework . . . . . . . . . . . . . . . . . 4
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Security Association Management . . . . . . . . . . . . . 5
4.3. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 6
4.4. Protecting Traffic Between the Mobile Node and the
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Solution Description . . . . . . . . . . . . . . . . . . . . . 7
5.1. HTTPS-based Mobile IPv6 Bootstrapping . . . . . . . . . . 7
5.2. Configuring Security Association Parameters . . . . . . . 8
5.2.1. Security Parameter Index . . . . . . . . . . . . . . . 9
5.2.2. MN-HA Shared Key . . . . . . . . . . . . . . . . . . . 9
5.2.3. Security Association Validity Time . . . . . . . . . . 9
5.2.4. CipherSuite . . . . . . . . . . . . . . . . . . . . . 9
5.3. Configuring Mobile IPv6 Parameters . . . . . . . . . . . . 9
5.3.1. Home Agent Address . . . . . . . . . . . . . . . . . . 10
5.3.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 10
5.3.3. Home Addresses and Home Network Prefix . . . . . . . . 10
5.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 10
5.4.1. Binding Management Messages . . . . . . . . . . . . . 11
5.4.2. Reverse Tunneled User Data Packets . . . . . . . . . . 12
5.5. Protecting Traffic Between the Mobile Node and the
Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Dual Stack Mobile IPv6 Considerations . . . . . . . . . . 15
5.7. Route Optimization . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 16
6.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Korhonen & Patil Expires January 7, 2010 [Page 2]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
1. Introduction
Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between
a mobile node (MN) and home agent (HA) is secured by IPsec [RFC4301].
The current Mobile IPv6 security architecture is specified in
[RFC3776] and [RFC4877]. This security model requires a tight
coupling between the Mobile IPv6 protocol part of the IP stack and
the IKE/IPsec part of the IP stack. Implementation experience has
indicated that the use of IKE/IPsec with Mobile IPv6 is fairly
complex. The issues with the IKE/IPsec based security architecture
are documented in [I-D.patil-mext-mip6issueswithipsec].
This document proposes an alternate security framework for Mobile
IPv6. Transport Layer Security (TLS) [RFC5246] is widely
implemented, used and available in most operating systems. The
security framework is based on reusing TLS to secure Mobile IPv6
signaling and reverse tunneled traffic between the MN and the HA.
The primary advantage of using TLS for Mobile IP6 security is the
ease of implementation while providing the equivalent security
measures as compared to IPsec. The TLS-based security framework for
Mobile IP6 does not deprecate the use of IKE/IPsec for Mobile IP6
security. Rather it provides an alternative security solution to
Mobile IPv6 implementations and deployment.
2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Home Agent Controller (HAC):
The home agent Controller is a node responsible for bootstrapping
the security association between a mobile node and one or more
home agents. The home agent Controller also provides required key
distribution to both mobile nodes and home agents. A generic
Mobile IPv6 bootstrapping can be done as part of the security
association bootstrapping.
Binding Management Message:
A message used by mobile nodes, Correspondent Nodes, and home
agents in all messaging related to the creation and management of
bindings. Binding Updates and Binding Acknowledgement messages
are examples of binding management messages.
Korhonen & Patil Expires January 7, 2010 [Page 3]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
3. Background
Work on the design and specification of Mobile IPv6 has been done
since the late 90s. The security architecture of Mobile IPv6 was
based on the understanding that IPsec is an inherent and integral
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
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
[RFC3344] for example does not use IPsec for security and instead has
specified its own security solution.
Mobile IPv6 has been standardized in 2005 along with the security
architecture using IKE/IPsec specified in RFC3776. With the
transition to IKEv2 [RFC4306], Mobile IP6 security has also been
updated to rely on the use of IKEv2 and specified in [RFC4877].
Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile
IPv6 [RFC5555] have identified the complexity of using IPsec and
IKEv2 in conjunction with Mobile IP6. At an abstract level it can be
said that implementing Mobile IP6 with IPsec and IKEv2 is possible
only with modifications to the IPsec and IKEv2 components. The
original design intent was to reuse IPsec without having to modify
it. There is also a view that IPsec is not necessarily the most well
suited security protocol for Mobile IPv6.
To alleviate the implementation complexity concerns and to create a
security architecture that would be easier to implement, deploy and
use, this document proposes a security framework based on TLS.
4. TLS-based Security Framework
This specification defines an alternative security and bootstrapping
solution for Mobile IPv6. The solution is inherently based on the
reuse of TLS provided security functionality, and aims to provide an
alternative to the IKE/IPsec based Mobile IPv6 security architecture
[RFC3776][RFC4877] and IKEv2 based Mobile IPv6 bootstrapping
[RFC5026]. The TLS-based solution is supposedly much easier to
implement in MNs and HAs than the IKE/IPsec-based alternative.
4.1. Architecture
The generic TLS-based security architecture is shown in Figure 1.
The connection between a MN and a Home Agent Controller (HAC) is
always secured by a TLS tunnel. It should be noted that a HAC, an
AAA server and a HA are logically separate entities and can be
collocated in all possible combinations. There MUST be a strong
trust relationship between the HA and the HAC, and the communication
Korhonen & Patil Expires January 7, 2010 [Page 4]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
between them MUST be both integrity and confidentially protected.
+------+ +------+ +------+
|Mobile| TLS |Home | AAA | AAA |
| Node |<----------->|Agent |<---------->|Server|
| | |Contrl| | |
+------+ +------+ +------+
^ ^ ^
| | |
| BU/BA/../ | e.g. AAA | AAA
| (Data) | |
| v |
| +---------+ |
| | MIPv6 | |
+--------------->| Home |<-------------+
| Agent(s)|
+---------+
Figure 1: TLS-based Security Architecture Overview
4.2. Security Association Management
Once the MN has contacted the HAC and a mutual authentication has
taken place between the MN and the HAC using TLS provided mechanisms,
the HAC provisions the MN with all security related information
inside the TLS protected tunnel. This security related information
constitutes a Security Association (SA) between the MN and the HA.
The created SA MUST NOT be tied to the Care-of Address (CoA) of the
MN.
The HAC may proactively distribute the SA information to HAs under
its management, or the HA may query the SA information from the HAC
once the MN contacts the HA. The HA MUST be able to index the SA
information based on the combination of a MN Identity (typically
represented in a Network Access Identifier (NAI) [RFC4282] format)
and a Security Parameter Index (SPI).
In certain situations, the HA may want the MN to re-establish the SA
even if the existing SA is still valid. The HA can indicate this to
the MN using a dedicated return code in a BA. As a result, the MN
would contact the HAC prior the SA times out, and the HAC would
provision the MN and HAs with a new SA information.
The SA contains at least the following information:
Korhonen & Patil Expires January 7, 2010 [Page 5]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Mobility SPI:
A SPI used by the MN and the HA to index the SA between the MN and
the HA. The HAC is responsible for assigning SPIs to MNs. There
is only one SPI for both binding management messaging and possible
user data protection. The same SPI is used for both directions
between the MN and the HA.
MN-HA shared key:
A key used for ciphering Mobile IPv6 traffic between the MN and
the HA. The HAC is responsible for generating this key. The key
generation algorithm is specific to the HAC implementation.
Security association validity time:
The validity time for the Security Association. The HAC is
responsible for defining the lifetime value based on its policies.
The lifetime may be in order of hours or up to weeks. The MN MUST
re-contact the HAC before the SA validity time ends.
Selected ciphersuite:
The ciphersuite used to protect the traffic between the MN and the
HA. The selected algorithms are one of the mutually supported
ciphersuites of the negotiated TLS version between the MN and the
HAC. The HAC is responsible for assigning the used ciphersuite.
Obviously, the HAs under HAC's management MUST implement the same
ciphersuites as the HAC. The selected ciphersuite MUST provide
integrity and confidentially protection.
Sequence number:
A monotonically increasing unsigned sequence number used in all
protected packets exchanged between the MN and the HA. The
initial sequence number MUST always be set to 0 (zero). The
sequence number may cycle to 0 (zero) when it increases beyond its
maximum defined value.
** Editor's note: the SA contents is subject to more details **
4.3. Bootstrapping of Additional Mobile IPv6 Parameters
When the MN contacts the HAC and does the bootstrapping of the
security related information, the HAC may also provision the MN with
various Mobile IPv6 related bootstrapping information. Bootstrapping
of the following information SHOULD at least be possible:
Korhonen & Patil Expires January 7, 2010 [Page 6]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
Home Agent IP Address:
Concerns both IPv6 and IPv4 home agent addresses.
Mobile IPv6 Service Port Number:
The port number where the HA and the MN are listening to UDP
[RFC0768] packets. There is no fixed or IANA allocated port
number defined in this specification for Mobile IPv6. Rather,
deployments are free to choose any valid and available port number
for their HAs and MNs.
Home Address:
Concerns both IPv6 and IPv4 Home Addresses.
The Mobile IPv6 related bootstrapping information is delivered from
the HAC to the MN over the same TLS protected tunnel as the security
related information.
4.4. Protecting Traffic Between the Mobile Node and the Home Agent
The same integrity and confidentiality algorithms MUST be used to
protect both binding management messages and reverse tunneled user
data traffic between the MN and the HA. Generally, all binding
management messages (BUs, BAs and so on) MUST be both integrity and
confidentially protected. The reverse tunneled user data traffic
SHOULD be equivalently protected. Generally, the rules stated in
[RFC3775] concerning the protection of the traffic between the MN and
the HA apply also in this specification.
5. Solution Description
5.1. HTTPS-based Mobile IPv6 Bootstrapping
The alternative Mobile IPv6 security solution described in this
specification relies on the reuse of certain existing technologies
standardized in the IETF. Namely, we utilize HTTP over TLS (HTTPS)
[RFC2818] for the communication between the MN and the HAC, for
bootstrapping Mobile IPv6 specific security associations and possible
additional configuration data. Figure 2 shows the architecture and
the scope of the solution defined in this specification.
Korhonen & Patil Expires January 7, 2010 [Page 7]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
+------+ +------+
|Mobile| HTTPS |Home |
| Node |<----------->|Agent |
| | |Contrl|
+------+ +------+
^
| UDP encapsulated
| BU/BA/../Data
| packets +---------+
| | MIPv6 |
+--------------->| Home |
| Agent |
+---------+
Figure 2: HTTPS-based Security Architecture
The MN can be authenticated towards the HAC in two ways. First, the
MN can be authenticated at the TLS layer, assuming the MN and the HAC
can mutually authenticate each other. Second, the MN can be
authenticated separately using some authentication framework running
on top of HTTP. However, it is entirely a deployment specific
decision which way to choose.
All bootstrapping information, whether that is for setting up the SA
or configuring Mobile IPv6 specific information, is exchanged between
the MN and the HAC in HTTP request and response headers. The MN MUST
have an Universal Resource Identifier (URI) [RFC3986] of some HAC.
The URI could be statically configured, provisioned or derived by
some deployment specific method. For example
https://www.example.com/mip6-login.html
could be a valid URI configured in the MN. At minimum the MN does a
"GET" to the HAC URI, and receives a successful HTTP response with
headers and an empty "page".
The encoding of the HTTP headers complies to the augmented Backus-
Naur Form (BNF) defined in Section 2.1 of [RFC2616]. All presented
hexadecimal numbers are in network byte order.
5.2. Configuring Security Association Parameters
During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a
single ciphersuite for protecting the traffic between the MN and the
HA. The available ciphersuites for this specification are the same
as those in TLS v1.2 (see Annex A.5. of [RFC5246]). The selected
ciphersuite MUST provide integrity and confidentially protection.
Korhonen & Patil Expires January 7, 2010 [Page 8]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
All the parameters described in the following sections apply only to
a HTTPS response the MN. The MN has no way affecting to the
provisioning decision of the HAC.
5.2.1. Security Parameter Index
The 28-bit unsigned SPI number identifies the SA used between the MN
and the HA. The value 0 (zero) is reserved and MUST NOT be used.
Therefore, values ranging from 1 to 268435455 are valid.
The HTTP header corresponding to the SPI number is:
mip6-spi = "mip6-spi" ":" 1*DIGIT
5.2.2. MN-HA Shared Key
Key used to protect traffic between the MN and the HA. The key
length depends on the selected ciphersuite.
The HTTP header corresponding to the MN-HA Shared Key is:
mip6-mnha-key = "mip6-mnha-key" ":" 1*(HEX HEX)
5.2.3. Security Association Validity Time
The validity time of the created SA. The end of the SA validity
period is represented in "rfc1123-date" format as defined in Section
3.3.1 of [RFC2616].
The HTTP header corresponding to the SA validity time value is:
mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date
5.2.4. CipherSuite
The ciphersuites follow the TLS 1.2 numeric representation defined in
Annex A.5 of [RFC5246]. The HTTP header corresponding to the
selected ciphersuite is:
mip6-ciphersuite = "mip6-ciphersuite" ":" 2HEX "," 2HEX
5.3. Configuring Mobile IPv6 Parameters
In parallel with the SA information bootstrapping, the HAC SHOULD
provision the MN with relevant Mobile IPv6 related bootstrapping
information.
The following generic BNFs are used to form IP addresses and
Korhonen & Patil Expires January 7, 2010 [Page 9]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
prefixes. They are used in the following sections.
ip6-addr = 7( word ":" ) word
word = 1*4HEX
ip6-prefix = ip6-addr "/" 1*2DIGIT
ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
5.3.1. Home Agent Address
The HAC MAY provision the MN with an IPv4 or IPv6 address of a HA, or
both.
mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr
mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr
5.3.2. Mobile IPv6 Service Port Number
The HAC SHOULD provision the MN with an UDP port number. The port
number is used by the MNs and the HAs as the UDP destination port
number when they initiate messages towards each other.
mip6-port = "mip6-port" ":" 1*5DIGIT
5.3.3. Home Addresses and Home Network Prefix
The HAC MAY provision the MN with an IPv4 or IPv6 Home Addresses, or
both. The HAC MAY also provision the MN with its Home Network
Prefix.
mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr
mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr
mip6-hnp-ip6 = "mip6-ip6-hnp" ":" ip6-prefix
5.4. Packet Formats
The following sections describe the packet formats used for the
traffic between the MN and the HA. This traffic includes binding
management messages (e.g., BU/BA/HoTi/.. etc messages), reverse
tunneled and encrypted user data, and reverse tunneled plain text
user data. This specification defines a generic packet format, where
everything is encapsulated inside an UDP. See Section 5.4.1 and
Section 5.4.2 for detailed illustrations of the corresponding packet
formats. The Mobile IPv6 Service port number, where the HA or the MN
expect to receive UDP packets, is negotiated during the SA
bootstrapping or statically configured. The same port number is used
for both binding management messages and user data packets. The
Mobile IPv6 Service MAY use any ephemeral port number as the UDP
source port, and MUST use the Mobile IPv6 Service port number as the
Korhonen & Patil Expires January 7, 2010 [Page 10]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
UDP destination port.
The encapsulating UDP header is immediately followed by a 4-bit
Packet Type (PType) field that defines whether the packet contains an
encrypted mobility management message, an encrypted user data packet,
or a plain text user data packet.
The Packet Type field is followed by a 28-bit SPI value, which
identifies the correct SA concerning the encrypted packet. In a case
encryption is not used, the SPI MUST be set to 0 (zero). There is
always only one SPI per mobility session and the same SPI is used for
all types of encrypted packets independent of the direction.
The SPI value is followed by a 32-bit Sequence Number value that is
used to identify retransmissions of encrypted messages. Each
endpoint in the security association maintains two "current" Sequence
Numbers: the next one to be used for a packet it initiates and the
next one it expects to see in a packet from the other end. If the MN
and the HA ends initiate very different numbers of messages, the
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
(zero).
Finally, the Sequence Number field is followed by the data portion,
whose content is identified by the Packet Type. When the data
portion is protected, it is again encapsulated inside an
Encapsulating Security Payload (ESP) [RFC4303] excluding the SPI and
Sequence Number fields that were already introduced earlier.
Actually, when data protection is used, the construction of the
packet on the wire is the same as an UDP encapsulated ESP packet in a
tunnel mode as defined in [RFC3948]. More detailed discussion of the
handling of the ESP is in Section 5.5.
** Editor's note: the handling of protected traffic (i.e. the "ESP"
at the moment) is subject to more detais/changes in the future **
5.4.1. Binding Management Messages
The binding management messages MUST always be protected. All
packets that are specific to Mobile IPv6 protocol and contain a
Mobility Header (as defined in Section 6.1.1. of RFC 3775) SHOULD use
the packet format shown in Figure 3. All binding management messages
that are exchanged between the MN and the HA MUST use the packet
format shown in Figure 3.
Korhonen & Patil Expires January 7, 2010 [Page 11]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=8| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Encapsulating Security Payload (ESP) after the Sequence :
: Number field as defined in Section 2. of [RFC4303] :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UDP Encapsulated Binding Management Message Format
The PType value 8 (eight) identifies that the UDP encapsulated packet
contains an encrypted RFC 3775 defined Mobility Header and other
relevant IPv6 extension headers (note, there is no IP header). The
Next Header field in the ESP header MUST be set to value of the first
encapsulated header. The encapsulated headers follow the natural
IPv6 and Mobile IPv6 extension header alignment and formatting rules.
The source and destination IP addresses of the outer IP header (i.e.
the src-addr and the dst-addr in Figure 3) use the current care-of
address of the MN and the HA address.
5.4.2. Reverse Tunneled User Data Packets
There are two types of reverse tunneled user data packets between the
MN and the HA. Those that are encrypted and those that are plain
text. The MN or the HA MAY switch between the encryption and plain
text at any time based on local policies. By default all user data
SHOULD be encrypted. The reverse tunneled IPv4 or IPv6 user data
packets are encapsulated as-is inside the ESP.
Korhonen & Patil Expires January 7, 2010 [Page 12]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=1| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Encapsulating Security Payload (ESP) after the Sequence :
: Number field as defined in Section 2. of [RFC4303] :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: UDP Encapsulated Protected User Data Packet Format
The PType value 1 (one) identifies that the UDP encapsulated packet
contains an encrypted tunneled IPv4/IPv6 user data packet. The Next
Header field in the ESP header MUST be set to value corresponding the
tunneled IP packet (e.g. 41 for IPv6).
The source and destination IP addresses of the outer IP header (i.e.
the src-addr and the dst-addr in Figure 4) use the current care-of
address of the MN and the HA address. The ESP protected inner IP
header uses the home address of the MN and the correspondent node
(CN) address.
Korhonen & Patil Expires January 7, 2010 [Page 13]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: UDP header (src-port=Xp,dst-port=Yp) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PType=0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: IPv4 or IPv6 Packet (plain) :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: UDP Encapsulated Non-Protected User Data Packet Format
The PType value 0 (zero) identifies that the UDP encapsulated packet
contains a plain text tunneled IPv4/IPv6 user data packet. Also the
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 src-addr and the dst-addr in Figure 5) use the current care-of
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.
5.5. Protecting Traffic Between the Mobile Node and the Home Agent
As briefly described in Section 5.4, all traffic between the MN and
the HA can be protected by ESP-over-UDP type encapsulation. The
Figure 6 shows a detailed structure of the ESP packet, which is
slightly modified from the ESP packet layout found in Section 2. of
RFC4303. The only notable difference is that the SPI is prefixed
with 4-bit PType field leaving 28-bit SPI value, although from the
ESP processing point of view, the 4-bit PType and 28-bit SPI are
handled as one "32-bit SPI". Furthermore, only 32-bit Sequence
Numbers are supported.
Korhonen & Patil Expires January 7, 2010 [Page 14]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| PType | Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| IV (optional) | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Rest of Payload Data (variable) | | |
: : | |
| | |Conf.
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | TFC Padding * (optional, variable) | |ered
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Padding (0-255 bytes) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -----
| Integrity Check Value-ICV (variable) |
: :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Substructure of ESP Protected Payload Data with a 28-bit
SPI and 4-bit PType Modifications
* An implementation can add Traffic Flow Confidentiality (TFC)
padding (see Section 2.7 of RFC4303) after the Payload Data and
before the Padding (0-255 bytes) field.
The general processing and construction of the ESP is described in
RFC4303. The used integrity and confidentially protection algorithms
are defined by the ciphersuite that was provided by the HAC during
the TLS-based bootstrapping of the SA.
** Editor's note: this section is subject to more detais/changes in
the future regarding how to apply integrity and confidentiality
protection algorithms to the "ESP" **
5.6. Dual Stack Mobile IPv6 Considerations
TBD.
5.7. Route Optimization
This specification does not address route optimization. However, if
the correspondent node (CN) implement HAC functionality locally, the
Korhonen & Patil Expires January 7, 2010 [Page 15]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
HTTPS-based bootstrapping of the SA between the MN and the CN can be
done.
6. IANA Considerations
6.1. New Registry: Packet Type
IANA is requested to create a new registry for the Packet Type as
described in Section 5.4.
Packet Type | Value
----------------------------------+----------------------------------
non-encrypted IP packet | 0
encrypted IP packet | 1
mobility header | 8
Following the example policies described in [RFC5226] new values for
the Packet Type AVP MUST be assigned based on the "RFC Required"
policy.
6.2. HTTP Headers
A number of HTTP headers with their respective parameters are
reserved. See Section 5.2 and Section 5.3 for a list of header names
and their parameters.
7. Security Considerations
TBD.
8. References
8.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Korhonen & Patil Expires January 7, 2010 [Page 16]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
8.2. Informative References
[I-D.patil-mext-mip6issueswithipsec]
Patil, B., Perkins, C., and H. Tschofenig, "Issues related
to the design choice of IPsec for Mobile IPv6 security",
draft-patil-mext-mip6issueswithipsec-00 (work in
progress), October 2008.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
Korhonen & Patil Expires January 7, 2010 [Page 17]
Internet-Draft TLS-based MIPv6 Security Framework July 2009
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
Authors' Addresses
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
Espoo FIN-02600
Finland
Email: jouni.nospam@gmail.com
Basavaraj Patil
Nokia
6021 Connection Drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Korhonen & Patil Expires January 7, 2010 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 07:41:09 |