Internet DRAFT - draft-mccann-dmm-flatarch
draft-mccann-dmm-flatarch
Internet Engineering Task Force P. McCann, Ed.
Internet-Draft Huawei
Intended status: Informational March 2, 2012
Expires: September 3, 2012
Authentication and Mobility Management in a Flat Architecture
draft-mccann-dmm-flatarch-00
Abstract
Today's mobility management schemes make use of a hierarchy of
tunnels from a relatively fixed anchor point, through one or more
intermediate nodes, to reach the MN's current point of attachment.
These schemes suffer from poor performance, scalability, and failure
modes due to the centralization and statefulness of the anchor
point(s). The dmm (Distributed Mobility Management) working group is
currently chartered to investigate alternative solutions that will
provide greater performance, scalability, and robustness through the
distribution of mobility anchors. This document is an input to the
dmm discussion. It outlines a problem statement for the existing
mobility management techniques and goes on to propose (high-level)
solutions to two of the most vexing problems: MN authentication and
mobility management in a fully distributed, flat (non-hierarchical)
access network. These two aspects are often treated separately in a
layered architecture, but we argue there are important advantages to
considering how these two functions can work in tandem to provide a
simple and robust framework for the design of a wireless Internet
Service Provider network.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 3, 2012.
Copyright Notice
McCann Expires September 3, 2012 [Page 1]
Internet-Draft FlatArch March 2012
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Mobility Management . . . . . . . . . . . . . . . . . . . . . 5
2.1. Addressing Plan . . . . . . . . . . . . . . . . . . . . . 6
2.2. Handoff . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Address Management . . . . . . . . . . . . . . . . . . . . 8
2.4. Macro-Mobility . . . . . . . . . . . . . . . . . . . . . . 9
3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Mobility Management and Authentication Working Together . . . 14
5. Workplan for IETF . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
McCann Expires September 3, 2012 [Page 2]
Internet-Draft FlatArch March 2012
1. Introduction
Figure 1 depicts the hierarchical mobility management architecture
that is being deployed by 3GPP LTE networks.
------
| P-GW | <--------- Fixed centralized
------ anchor point
// \\
// \\ <--------- Tunnels
// \\
------ ------ -----
| S-GW | | S-GW | | MME | <---- Responsible for
------ ------ ----- Authentication
// \\ \\ /
// \\ \\ /
// \\ \\ /
----- ----- -----
| eNB | | eNB | | eNB |
----- ----- -----
Figure 1: A typical hierarchical mobility management architecture.
This architecture is an evolution of the General Packet Radio System
(GPRS) that was originally adopted for GSM systems. It is motivated
in large part by two fundamental requirements:
o Keep the IP address (and therefore the anchor point) of the packet
data session fixed for the life of the session; and,
o Re-use the existing legacy AKA authentication algorithm that was
used for circuit voice.
These requirements were demanded by operators due to their desire to
maintain control over services in the home network and to maintain
their existing system of distributing user credentials in secure
Subscriber Identity Modules (SIMs).
While these two requirements made sense for the operators that
controlled standards decisions at the time, meeting them comes at
somewhat of a cost. The use of a fixed P-GW without route
optimization means that all packets have to traverse the chain of
tunnels from anchor to MN, which could be very suboptimal if the MN
is far away from the P-GW. The centralization of state in the P-GW
(and to a lesser extent in the S-GWs) means that these nodes are
scalability bottlenecks and that if one of them fails, all packet
data sessions going through that node also fail. The re-use of a
legacy symmetric secret key authentication protocol means that there
McCann Expires September 3, 2012 [Page 3]
Internet-Draft FlatArch March 2012
must be a round-trip to the home network to retrieve keying material
upon initial attachment and every time the MN encounters a new MME.
In addition to the performance impact, transport of secret keying
material across inter-provider interfaces always carries some risk
that the material will be compromised somewhere along the way. Note
that keying material also needs to be transported from the MME to
each eNB that the MN encounters.
This document examines the architectural implications of relaxing the
above two requirements. In particular, we note that many MNs will
not require a fixed IP address for the entire duration of their
packet data session, as they will most likely be acting as clients
and initiating short-lived connections to servers. It may be more
important that such communication take the shortest path possible to
reduce latency and load on the network. By making use of a routing
protocol instead of a tunnel setup protocol for most mobility events,
we can maximize the fault tolerance and compute the most optimal
route for any packet from any vantage point in the network.
Second, we note that the hardware limitations that mandated the use
of symmetric key algorithms for authentication are fading away. On a
modern CPU, an elliptic curve public key cryptographic operation can
be completed in well under 1 millisecond [1]. With the addition of
low-cost cryptographic acceleration hardware [2], the battery impact
of such an operation can be reduced even further. As CPU power is
only increasing, we argue that it will be more important to reduce
the number of messages and round-trips to the home network than to
absolutely minimize the CPU consumption in the MN. Only a public key
cryptosystem offers the ability to do this. With the creation of a
new breed of authentication algorithms that can operate in one round-
trip over the air, we can afford to perform a full re-authentication
of the MN upon encountering each Access Router (AR), completely
eliminating the need to transport secret keying material between
infrastructure nodes.
The remainder of this document is structured as follows: Section 2
discusses the possibility of using a routing protocol for localized,
network-based mobility management in a wireless access network.
Section 3 introduces a possible public-key based authentication
scheme that could be used for access authentication at each AR.
Section 4 explores the synergy between authentication and mobility
management, and explains how the new authentication algorithm could
be embedded into Mobile IP for macro-mobility across domains.
Section 5 is a list of work items for the IETF that will make this
vision a reality. Finally, Section 6 and Section 7 give IANA and
Security Considerations, respectively.
McCann Expires September 3, 2012 [Page 4]
Internet-Draft FlatArch March 2012
1.1. Requirements Language
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 RFC 2119 [3].
2. Mobility Management
Figure 2 gives a picture of a flat wireless Internet service provider
network. Although ISP networks are usually structured in a hierarchy
of layers such as Core, Aggregation, and Access routers, the
connectivity between the routers is more mesh-like in nature and less
rigidly hierarchical than the tunneling boxes shown in Figure 1.
__O-----------O__
( )
( Internet )
(_ _)
/O-------------O
/ \
/ \
----- -----
( rtr )-------------__( rtr ) <--- Core Layer
----- _/ ----- Routers
/ \ ______/ / \
/ \ / / \
----- ----- ----- -----
( rtr ) ( rtr ) ( rtr ) ( rtr ) <--- Aggregation
----- ----- ----- ----- Layer Routers
/ \ / \ / \ /
---- ---- ---- ----
| AR | | AR | | AR | | AR | <--- Access Layer
---- ---- ---- ---- Routers
Figure 2: A flat wireless Internet service provider architecture.
The Access Routers (ARs) would be integrated with the radio link
layer at the base stations. The ARs act as the first-hop routers for
the MNs, and tunnels do not appear in the architecture until they are
needed. Note also that each router can be connected to more than one
router in the layer above, and can even be connected directly to some
of its peer routers in the same layer. Except for the access layer,
all of the routers in the network are standard off-the-shelf wireline
routers running IBGP.
We assume that each AR has its own pool of addresses from which it
can assign to mobile nodes and that these addresses are advertised
McCann Expires September 3, 2012 [Page 5]
Internet-Draft FlatArch March 2012
using IBGP to the upstream routers in the aggregation layer. We
assume that all mobile nodes are authenticated upon attachment or re-
attachment to a base station, and that the outcome of authentication
is an exchange of hostnames (the base station learns the mobile
node's hostname and vice-versa) bound to a master session key (MSK)
shared between the mobile node and base station. Upon initial
arrival in a given autonomous system, the mobile node is allocated an
address (or a prefix) from the base station to which it is attached
using ordinary mechanisms, e.g., DHCP. Then the mobile node updates
its home DNS server to point from its hostname to the new address.
The base station updates the reverse pointer in the in-addr.arpa or
ip6.arpa space to point to the hostname it obtained when it
authenticated the mobile node. Then, upon handoff, the target base
station looks up the hostname received during authentication to
determine whether the mobile node already has an address assigned
from elsewhere in the autonomous system. If so, and if the hostname
looked up in the reverse pointer is the same, it sends a BGP UPDATE
message to all of its BGP peers containing the address (or the
prefix) that was allocated to the mobile node. Packets are then
routed appropriately to the new point of attachment in an optimal
way. In the remainder of this section we describe the possible
mechanisms in more detail.
2.1. Addressing Plan
The operator must define an addressing plan for the whole autonomous
system. As a maximally-flat network, we assume that each base
station will have its own designated pool of addresses from which it
will assign to mobile nodes. To save space in the routing tables
throughout the autonomous system, each pool should be a contiguous
chunk of address space with a common prefix. Each base station acts
as a BGP [4] router, originating UPDATE messages for the prefix(es)
that it owns. The routers in the aggregation layer are configured as
route reflectors [5] for the base stations they subtend (the base
stations are route reflector clients). These routers are configured
to aggregate the assigned address prefixes advertised by the base
stations for the core routers above them, but will faithfully reflect
all sub-prefixes advertised by any route reflector client to all
other route reflector clients. Also, any sub-prefixes advertised by
a client that are outside that client's pre-assigned range (known by
configuration in the aggregation router) will also be reflected to
the other clients and, if the prefix is outside the scope of the
route reflector itself, propagated upward toward the core routers.
On one popular BGP router platform, this would be accomplished
with a combination of the "aggregate-address" command (without
the "summary-only" option) and the "neighbor distribute-list
out" command specifying that more-specific prefixes of the
McCann Expires September 3, 2012 [Page 6]
Internet-Draft FlatArch March 2012
known aggregate are to be suppressed to the non-client routers.
2.2. Handoff
Upon handoff within the same autonomous system, the mobile node is
authenticated by the new base station. Given the mobile node's
authenticated DNS name, the new base station takes several actions.
First, it looks up the set of IP addresses associated with the
hostname. It then makes a policy check on each IP address to see
whether it is within the range of addresses managed by BGP in its
local autonomous system. If so, it does a reverse lookup in the in-
addr.arpa or ip6.arpa space (this space is controlled by the wireless
ISP, unlike the forward mapping which is controlled by the mobile
node) for each such IP address to ensure that some peer base station
in its network did actually assign the IP address to the given name.
If so, it originates a new BGP UPDATE message to its peers containing
NLRI of the specific prefix (perhaps just a single address) that was
assigned to the mobile node, with itself as the NEXT_HOP. It sets
the LOCAL_PREF attribute to a 32-bit timestamp taken from its local
clock (we assume that all base stations in an autonomous system have
clocks synchronized to within 1 second). This will guarantee that
the route is preferred over the same route that may have been
advertised by a previously visited base station. The UPDATE will be
sent to the parent routers in the aggregation layer, and will be
reflected down to all other base stations in the same cluster. If
the prefix was originally assigned by a peer base station in the same
cluster, that is the extent of the update. Otherwise, the
aggregation router propagates the update to the core layer which
reflects it down to all other aggregation routers and from there it
goes into all the base stations in the access layer.
Thus, when the mobile node moves within the same cluster, the
messaging is confined to that cluster; however, when the mobile node
crosses a cluster boundary, the update propagates through the larger
cluster bounded by the route reflector above. If this is the core
layer, then the update would be propagated throughout the autonomous
system. This is necessary to ensure that optimal routes are created
everywhere in the system. In general, there may be additional peer-
to-peer links in the autonomous system; for example, directly between
two neighboring base stations. Such a link would appear in the
Interior Gateway Protocol (IGP, such as OSPF, EIGRP, or IS-IS) but
would not be a BGP peering because the route reflectors take care of
propagating BGP prefixes. Our scheme allows packets to make use of
this route when appropriate; for example, a packet originated on one
base station, destined for an IP address that is normally homed on
the same base station but is being temporarily borrowed by a
neighbor, would match the more-specific route to the neighbor listed
as the NEXT_HOP in BGP and the recursive routing would forward the
McCann Expires September 3, 2012 [Page 7]
Internet-Draft FlatArch March 2012
packet over the direct link.
2.3. Address Management
The mobile node can therefore keep its address throughout the
autonomous system if it wishes. When the address is nearing its
lease expiration, the mobile node would send a unicast DHCPREQUEST to
the DHCP server associated with the original base station to renew
the lease. All base stations in the network must filter packets
bound to IP addresses internal to the autonomous system to prevent
abuse. In the case of DHCPREQUEST going to a remote base station,
the current base station must add the DHCP Relay Agent Information
Option [6] containing the mobile node's DNS hostname in the Agent
Remote ID sub-option.
Keeping an address for a long period of mobility is sub-optimal due
to the large amount of routing state that would be introduced. Our
scheme is optimized for the case where the mobile node can
periodically change its IP address to one that is more locally-
appropriate. The BGP routing updates can provide a micro-mobility
solution that hides the mobile node's movement from nodes outside the
autonomous system and avoids frequent updates of its home DNS server.
However, mobile nodes should keep track of which connections are
using which addresses, and should periodically get new IP addresses
from whatever base station to which they happen to be attached. Each
IP address currently assigned to the mobile node should be registered
to its home DNS server, with the most recently allocated listed
first. Clients will therefore prefer the most recently allocated
address for new connections.
Publishing the IP address assigned to a mobile node has security
implications. Anyone who does a lookup can track the mobile node to
the base station to which it was attached when it reserved the
address. In general the use of an optimal route seems to be at odds
with location privacy; if the mobile node needs location privacy, it
should hide itself behind a proxy and only publish the proxy's IP
address to the public DNS. Our scheme could function with pseudonyms
assigned to mobile nodes by the visited network operator, but
constructing such pseudonyms and allocating credentials to them is
outside the scope of this document.
When a mobile node wants to release an address it should remove it
from its home DNS server and send a DHCPRELEASE to the original
assigning DHCP server. A DHCP server may have a policy that limits
the number of times an IP address assignment may be renewed from a
remote base station. This will force the mobile node to eventually
release the address and optimize the routing tables.
McCann Expires September 3, 2012 [Page 8]
Internet-Draft FlatArch March 2012
The prefixes that we inject into the IBGP would most likely be full-
length IPv4 addresses, although for IPv6 assignment of true prefixes
would be more appropriate. All base stations in an autonomous system
would need to agree on the prefix lengths they are assigning, and
these prefixes would need to be on byte boundaries (for in-addr.arpa
reverse lookups) or nybble boundaries (for ip6.arpa reverse lookups).
The target base station would look up the mobile node's hostname and
get back single IP addresses that are drawn from the prefixes and
then do the reverse lookup on the containing prefix.
2.4. Macro-Mobility
The ability for any router in the access network to attract the
packets destined for the MN can be used advantageously for macro-
mobility as well as micro-mobility. Let's consider again the diagram
from Figure 2, redrawn in Figure 3.
__O-----------O__
( )
( Internet )
(_ _)
/O-------------O
/ \
/ \
----- ----- ----
( rtr )-------------__( rtr )---( HA )
----- _/ ----- ----
/ \ ______/ / \
/ \ / / \
----- ----- ----- -----
( rtr ) ( rtr ) ( rtr ) ( rtr )
----- ----- ----- -----
/ \ / \ / \ /
---- ---- ---- ----
| AR | | AR | | AR | | AR |
---- ---- ---- ----
Figure 3: Home Agent support in a wireless Internet service provider
architecture.
When the MN leaves the autonomous system completely, it may desire to
keep sessions that were ongoing before it left. The Home Agent in
the figure can be used for this purpose. Instead of using Gratuitous
ARP or ND to attract the MN's packets, the HA can instead send a BGP
UPDATE into the network to effect the routing of packets towards
itself. This is a more powerful mechanism than ARP or ND because it
can reach across multiple IP routing hops to install forwarding state
that will route the packets in its direction.
McCann Expires September 3, 2012 [Page 9]
Internet-Draft FlatArch March 2012
The sending of a BGP UPDATE by the HA is triggered by an
authenticated Registrationn Request or Binding Update. In this
respect, the role of the HA can be compared to the role of any of the
ARs that also must authenticate the MN before sending UPDATEs. We
advocate a unification of the authentication protocol used for access
and mobility signaling. The same set of credentials and secret keys
can be used for both purposes, simplifying the network architecture
and the node provisioning process. In the next section, we give a
high level design for an authentication scheme that can be used.
3. Authentication
Recall in Section 2 we alluded to an authentication protocol that
must run every time the MN encounters a new base station. To
minimize the number of round-trips to the home network, we choose to
base the authentication step on public key cryptography, namely an
Elliptic Curve Diffie-Hellman exchange between the MN and the base
station.
We note that the existing key exchange protocols such as IKE [7] and
TLS [8] implement Perfect Forward Secrecy (PFS) by completing an
ephemeral Diffie-Hellman exchange during the first round of messages
between the communicating parties. Credentials are exchanged in a
second round of messages. These multiple round-trips would introduce
unacceptable overhead and latency in the mobile wireless environment.
A key insight is that we don't necessarily need PFS if we are merely
doing key exchange for purposes of authentication and integrity
protection. A simpler protocol with one round-trip static Diffie-
Hellman will suffice.
Perhaps the most difficult part of deploying a public key
infrastructure is providing assurance that the public key obtained
for the other party with which one wants to communicate does actually
correspond to a private key known only to that other party. Key
assurance can be provided through the use of certificates such as
those defined by X.509 [9]. Usually, such certificates are exchanged
in-band during the second round of a key exchange protocol. They
must then be validated using e.g., the Online Certificate Status
Protocol (OCSP) [10] or sometimes with an OCSP response attached
("stapled") to the same message that delivered the certificate. The
exchange of certificates and OCSP information introduces additional
overhead and possible round-trips to the authentication protocol.
In contrast, a new method of obtaining key assurance is currently
being worked on in the DNS-based Assurance of Named Entities (DANE)
working group [11]. While intended initially to support TLS, the
protocol could be used for other purposes as well (e.g., S/MIME
McCann Expires September 3, 2012 [Page 10]
Internet-Draft FlatArch March 2012
[12]). Interestingly, some have proposed putting raw, bare public
keys into the DNS records so that TLS can be run without the use of
any certificates whatsoever [13]. It is this latter method of key
assurance that we build on here.
Here we use the terminology of "peer" and "authenticator" as they are
used in the Extensible Authentication Protocol (EAP) [14]. In our
case the peer is the MN and the authenticator is the base station or
Home Agent. We assume that the peer and authenticator are both named
entities with DNS records containing the public portion of their
keys. All such DNS records are protected with DNSSEC.
The peer and authenticator must discover each others' names and
obtain the public keys corresponding to those names. There are
several methods for how the peer might learn the authenticator's name
and public key:
o The authenticator broadcasts its name and public key in system
overhead messages.
o The authenticator unicasts its name and public key to the peer in
an LTE Non-Access Stratum (NAS) message.
o The authenticator inserts its name and public key in the readable
string portion of an EAP Identity Request and/or after the null
terminating character.
o The peer somehow learns the DNS name of the authenticator and
looks up the authenticator's key in the DNS using DNSSEC over an
existing connection to the Internet prior to attaching to the
authenticator.
In the first three methods, the peer may obtain assurance that the
key belongs to the given name by making a DNS query as its very first
action upon obtaining Internet access through the authenticator.
We assume that the authenticator has access to the Internet and can
retrieve the key of the peer when it is given only the peer's DNS
name during the authentication process. Distributing keys out-of-
band helps to reduce the size of the authentication messages.
The actual authentication process consists of a single message sent
from the peer to the authenticator. The message could be embedded in
a NAS message or an EAP Identity Response message destined to the
authenticator. Upon receiving and validating this message, the
authenticator is able to derive a Master Session Key (MSK) which will
be securely bound to the pair of DNS names given by both sides. The
message from peer to authenticator would be protected with an HMAC
McCann Expires September 3, 2012 [Page 11]
Internet-Draft FlatArch March 2012
using the MSK derived by the peer. Upon validating the
authentication message, and if requested by the peer, the
authenticator may immediately begin the mobility management process
outlined in Section 2. The authenticator may in parallel send a NAS
message or an EAP Success message indicating successful
authentication. The NAS message may be a Security Mode Command
message that initializes the over-the-air integrity protection and
encryption. The EAP Success message could trigger a lower layer key
handshake as specified by IEEE 802.11i [15].
The derivation of the MSK is depicted below in Figure 4.
peer __ ___authenticator
private key \ / private key
\ /
authenticator \ / peer
public key--+ | | +---public key
v v v v
ECDH ECDH
\ /
\ /
V V
Long-Term Shared Secret
(LTSS)
peer DNS __ | __authenticator DNS
name & length \_ | _/ name & length
\_ | _/
peer session \_ | _/ authenticator
nonce \ \ | / / session nonce
\ vvv /
\------> KDF <-----/
|
|
v
MSK
Figure 4: The key derivation hierarchy for authentication and key
agreement in one round-trip.
In the figure, we depict the two sides independently performing
Elliptic Curve Cofactor Diffie-Hellman (as specified in Section
5.7.1.2 of NIST SP 800-56A [16]). Each uses its own private key and
the public key of the other entity. Both sides should arrive at the
same value which they use as a Long-Term Shared Secret (LTSS). The
LTSS may be cached so that the expensive ECDH operation does not have
to be repeated when the same peer accesses the same authenticator in
the future.
McCann Expires September 3, 2012 [Page 12]
Internet-Draft FlatArch March 2012
Next, we derive the MSK using a Key Derivation Function (KDF), taking
as input the LTSS, the identities of the two parties (the DNS names
and their lengths) as well as a session nonce from each party. The
KDF should also include a counter value (set to 1) and a unique
string indicating which function is calling the KDF. This will make
the key derivation compliant to Section 5.8.1 of NIST SP 800-56A
[16].
The authenticator may send a session nonce along with its public key
in any of the four ways outlined earlier; note that in the case of
publication in the DNS, the authenticator's session nonce would
actually be re-used by incoming sessions for a period of time.
Session MSKs would still be independent due to the entropy added by
the peer in its own session nonce and by the different LTSSs derived
for different peers.
If it turns out that it is unacceptable to re-use the
authenticator's nonce for more than one session, we will need
to put an authenticator session nonce into the response to the
peer's single authentication message. This response would
trigger both sides to recompute MSK and to use it going
forward. This response message should be authenticated with an
HMAC using a key derived from either the first or second MSK to
avoid denial-of-service attacks.
Actually, it might be good to have such a "re-MSK" message
available to either side during the life of the session to
enable re-fresh of the MSK.
The derivation of the LTSS and the execution of the KDF to generate
the MSK should be carried out in a secure environment, and both
private keys and the LTSS should be stored in the secure environment
so that they cannot be accessed except by the authentication method.
The MSK may also be kept in the secure environment and an interface
provided to derive further keys from it; alternatively, the MSK may
be distributed to the outside environment for subsequent use.
Historically, the secure environment has been implemented inside
tamper-proof hardware that is resistant to duplication ("cloning");
such hardware usually runs at a much lower clock speed than the
general purpose CPU that is used for other computing tasks. Because
the ECDH operation will require the support of the main CPU, we
envision that hardware virtualization support on the main CPU can be
used to create a secure environment for the generation, storage, and
use of private keys and the LTSS.
McCann Expires September 3, 2012 [Page 13]
Internet-Draft FlatArch March 2012
4. Mobility Management and Authentication Working Together
As described in Section 2, it is the completion of the authentication
step that indicates to the AR that the MN is authentic and that its
traffic should be redirected to the new point of attachment. Upon
initial attachment, the MN doesn't have any assigned IP address and
must obtain one using DHCP. At the same time, the DHCP server should
assign the name of a Home Agent that can be used by the MN when it
leaves the area inside which a BGP UPDATE accomplishes the traffic
re-routing for the given address. The HA can be strategically placed
at the boundary of this region, introducing the least amount of
latency once the MN puts it on the forwarding path. The MN can
perform a DNS lookup on the HA name to retrieve the HA's public key
and perform the derivation of an LTSS long in advance of needing the
HA's services. Messages could be provided so that the MN and HA can
develop an MSK without the HA sending a BGP UPDATE; this would avoid
the need to derive an MSK later when the Registration Request /
Binding Update is actually sent.
We need some way of indicating to the MN whether or not its old
address(es) have been successfully re-routed or whether it needs to
perform a Mobile IP Registration Request / Binding Update to receive
its traffic. One way is to wait for the AR to send a Router
Advertisement (RA). The RA should contain all of those prefixes that
were successfully re-routed by the AR sending a BGP UPDATE. If any
prefix is missing from this list, the MN should initiate the Mobile
IP Registration/Binding Update for those that are missing. However,
this may be too much overhead so it may be desirable to build in some
indication at the link layer (e.g., NAS signaling) when some prefixes
were not able to be re-routed.
Existing LTE networks enable the MNs to remain in the idle state for
many mobility events. This is accomplished through the use of
Tracking Area Lists, and the MN does not need to update its location
as long as it is within a Tracking Area that is on the list it was
last sent. We can also support this concept; however, packets
destined to the mobile node would always be routed to the AR on which
it was last authenticated. That AR would need to page the MN
throughout the Tracking Area List that it previously sent to the MN,
and the MN would need to attach to the currently serving AR and carry
out authentication to obtain these packets. The BGP UPDATE would
reach the old AR which would then forward the packets as normal. The
Tracking Area Lists should be chosen to make a proper tradeoff
between the frequency of re-authentication and the size of the paging
areas, keeping in mind that the MN will need to re-authenticate
itself to receive packets at the current location.
Caching of the LTSSs will play an important role in improving the
McCann Expires September 3, 2012 [Page 14]
Internet-Draft FlatArch March 2012
performance of our scheme. Each MN could retain the LTSS for many if
not all of the ARs it has previously visited, and the ARs could
retain the LTSS for many of the recently seen MNs. This makes the
derivation of the MSK a very simple matter of exchanging nonces and
running the KDF.
5. Workplan for IETF
The IETF should undertake the following:
1. In the DANE working group, add authenticator nonces to the DNS
record format for bare public keys.
2. Define a way to run the authentication protocol in this document
over EAP.
3. In the DMM working group, define a way to run the authentication
protocol in this document over Mobile IP. This may or may not
involve running EAP over Mobile IP.
4. When defining the authentication protocol either over EAP or MIP,
define a flag that allows the MN to control whether mobility
management is immediately invoked or not (i.e., allow for
derivation of the MSK by both sides without necessarily invoking
mobility management).
5. Define a new DHCP option that carries a Home Agent DNS name.
6. Write an applicability statement and implementation guide for the
use of BGP to create host routes for host mobility.
6. IANA Considerations
This memo includes no request to IANA as of yet.
7. Security Considerations
TBD
8. Acknowledgements
McCann Expires September 3, 2012 [Page 15]
Internet-Draft FlatArch March 2012
9. Informative References
[1] Bernstein, D., "Speed reports for elliptic-curve cryptography".
[2] Gaubatz, G., Kaps, J., Ozturk, E., and B. Sunar, "State of the
Art in Ultra-Low Power Public Key Cryptography for Wireless
Sensor Networks", 2nd IEEE International Workshop on Pervasive
Computing and Communication Security (PerSec 2005) , 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4
(BGP-4)", RFC 4271, January 2006.
[5] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An
Alternative to Full Mesh IBGP", RFC 2796, April 2000.
[6] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[7] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[8] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008.
[9] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[10] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999.
[11] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate
Certificates with Domain Names For TLS",
draft-ietf-dane-protocol-16 (work in progress), February 2012.
[12] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate
Certificates with Domain Names For S/MIME",
draft-hoffman-dane-smime-01 (work in progress), August 2011.
[13] Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
Tschofenig, "TLS out-of-band public key validation",
draft-wouters-tls-oob-pubkey-02 (work in progress),
November 2011.
McCann Expires September 3, 2012 [Page 16]
Internet-Draft FlatArch March 2012
[14] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[15] "Draft Standard for Information Technology - Telecommunications
and information exchange between systems - Local and
metropolitan area networks Specific requirements - Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) specifications", IEEE 802.11-REVma, 2006.
[16] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-
Wise Key Establishment Schemes Using Discrete Logarithm
Cryptography (Revised)", NIST Special Publication 800-56A,
March 2007, <http://csrc.nist.gov/publications/nistpubs/
800-56A/SP800-56A_Revision1_Mar08-2007.pdf>.
Author's Address
Peter J. McCann (editor)
Huawei
400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807
USA
Phone: +1 908 541 3563
Email: peter.mccann@huawei.com
McCann Expires September 3, 2012 [Page 17]
