INTERNET-DRAFT Erik Nordmark, Sun Microsystems
Nov 12, 2001
Securing MIPv6 BUs using return routability (BU3WAY)
<draft-nordmark-mobileip-bu3way-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 expires May 12, 2002.
Abstract
This document is intended to serve as input to the discussion in the
Mobile IP Working Group regarding securing MIPv6 Binding Updates.
This document tries to capture a possible extreme point in the design
space for a solution to that problem, for the purposes of exploring
the design space. The author does not claim that this protocol is
better than any other proposed solutions - merely that it is
different and the differences can help in understanding design
tradeoffs in this space.
This proposal relies on using only return routability to verify the
authority to perform a binding update. It uses return routability
for every Binding Update message i.e., every binding update implies a
draft-nordmark-mobileip-bu3way-00.txt [Page 1]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
3-way handshake between the correspondent node and the mobile node.
The document also tries to look at how the security properties of the
proposed protocol would change when trying to optimize the protocol
so that, past the first BU between a MN and a CN, subsequent BUs can
be done without a 3-way handshake.
Contents
1. INTRODUCTION............................................. 3
1.1. Assumptions......................................... 3
2. TERMINOLOGY.............................................. 5
2.1. General............................................. 5
2.2. Requirements........................................ 6
3. PROTOCOL OVERVIEW........................................ 6
3.1. Goals and Requirements.............................. 6
3.2. Message flow........................................ 7
4. MESSAGE FORMATS.......................................... 9
4.1. Binding Update Request Message Format............... 9
4.2. Binding Update Challenge Message Format............. 10
4.3. Binding Update Message Format....................... 12
4.4. Binding Acknowledgement Message Format.............. 14
5. CONCEPTUAL MODEL OF A NODE............................... 16
5.1. Conceptual Data Structures.......................... 16
5.2. Forming Cookies..................................... 18
5.3. Garbage Collection and Timeout Requirements......... 20
6. BEHAVIORAL SPECIFICATION................................. 20
6.1. Sending Binding Update Request Messages............. 20
6.2. Retransmission of Binding Update Request Messages... 21
6.3. Validation of Binding Update Request Messages....... 22
6.4. Processing Valid Binding Update Request Messages.... 22
6.5. Sending Binding Update Challenge Messages........... 23
6.6. Validation of Binding Update Challenge Messages..... 23
6.7. Processing Valid Binding Update Challenge Messages.. 24
6.8. Sending Binding Update Messages..................... 24
6.9. Retransmission of Binding Update Messages........... 25
6.10. Validation of Binding Update Messages.............. 26
6.11. Processing Valid Binding Update Messages........... 26
6.12. Sending Binding Acknowledgement Messages........... 27
6.13. Validation of Binding Acknowledgement Messages..... 28
6.14. Processing Valid Binding Acknowledgement Messages.. 29
draft-nordmark-mobileip-bu3way-00.txt [Page 2]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
7. SECURITY PROPERTIES...................................... 29
7.1. Residual Threats.................................... 30
7.2. HA to MN Security Association....................... 32
7.3. MN to MN Binding Updates............................ 33
8. ORTHOGONAL SECURITY ISSUES............................... 34
9. WHAT IFS - ALTERNATE APPROACHES.......................... 35
9.1. Establish a Key for Authenticating BUs.............. 36
9.2. Diffie-Hellman Exchange............................. 37
10. PROTOCOL CONSTANTS...................................... 38
11. CONCLUSIONS............................................. 38
12. SECURITY CONSIDERATIONS................................. 40
13. ACKNOWLEDGEMENTS........................................ 40
REFERENCES................................................... 40
AUTHORS' ADDRESSES........................................... 41
1. INTRODUCTION
This document outlines a method for authenticating and authorizing
Mobile IPv6 [MIPv6] Binding Updates between a correspondent node and
a mobile node where there exists no pre-established direct or
indirect security relationship between those two entities. If a
pre-established relationship, like both the CN and MN being part of
the same Key Infrastructure (public or private) stronger security can
be applied for authenticating the Binding Update. There are also
proposals that associate a public/private key pair with the actual
IPv6 address which have different properties. However, such stronger
methods are outside of scope of the document. The purpose is to
explore parts of the solution space for weaker mechanisms.
1.1. Assumptions
The basis for the authentication and authorization is the assumption
that unicast IP routing is reasonably secure and that as long as
draft-nordmark-mobileip-bu3way-00.txt [Page 3]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
binding updates does not create significant additional security
issues than already present in today's routing system, the solution
at least does not do any (additional) harm.
In particular, this assumption about the IP routing working manifests
itself in the assumption that if a given Correspondent Node CN sends
a packet to the Home Address (HoA) of a Mobile Node MN, that the
routing system will deliver those packets to the Home Link of the
mobile node where the Home Agent (HA) will receive it.
At some level the authentication and authorization is intertwined in
this case. Authentication is often viewed as providing both sender
identity authentication as well as message integrity. If the
identity aspect of this in fact is capable of stating that the entity
sending a binding update is the mobile node i.e. the entity which has
been assigned the home address, then the authorization issue becomes
trivial - it is obvious that the MN is authorized to redirect its own
traffic. But this is largely a terminology issue.
The proposal also assumes that the communication between a MN and its
HA is secured using some form of pre-established security
association. For instance, such a security association might be
create at "subscription" time i.e., when the MN is assigned its HA.
It is assumed that this security association is used to secure the
Binding Update and Binding Acknowledgement messages between the MN
and its HA, and also that the association can be used to secure other
traffic between those two nodes.
This assumption includes traffic in both directions; from the HA to
the MN as well as the reverse direction. Thus either the pre-
established security association is bidirectional or there exists two
separate unidirectional pre-established security associations between
the HA and MN.
The techniques discussed can operate with the traffic between the HA
and MN providing at least integrity, but the security is improved
significantly when this channel provides confidentiality.
There is no assumption that the security mechanisms on that channel
provide replay protection since the binding update exchanges provide
their own protection against replays.
draft-nordmark-mobileip-bu3way-00.txt [Page 4]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
2. TERMINOLOGY
2.1. General
IP - Internet Protocol Version 6.
ICMP - Internet Message Control Protocol for the Internet
Protocol Version 6.
node - a device that implements IP.
router - a node that forwards IP packets not explicitly
addressed to itself.
host - any node that is not a router.
mobile node (MN)
a node which has a pre-established security
association with one or more home agents on its home
link and is capable of detecting when it moves
between different points of attachment in the
network, acquire a temporary care of address in each
visited location, and signal its current care of
address to the home agent using the security
association.
correspondent node (CN)
a node with which a mobile node communicates. The
correspondent node may itself be a mobile node.
home address (HoA)
the address of the mobile node which does not change
as the mobile node moves
home link - the link towards which regular IP routing forwards
packets destined to the home address
home agent - a router on the home link which tracks the mobile
nodes current location and relays packets to (and in
some cases) from the mobile node.
care of address (CoA)
an IP address assigned to the mobile node is its
current location
packet - an IP header plus payload.
draft-nordmark-mobileip-bu3way-00.txt [Page 5]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
2.2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS].
This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an
implementation must allow system administrators to change. The
specific variable names, how their values change, and how their
settings influence protocol behavior are provided to demonstrate
protocol behavior. An implementation is not required to have them in
the exact form described here, so long as its external behavior is
consistent with that described in this document.
3. PROTOCOL OVERVIEW
3.1. Goals and Requirements
Note that this protocol, as well as other protocols that do not rely
on some pre-existing security relationship (including security
properties tied to the IPv6 addresses), are inherently subject to
Man-in-the-Middle attacks for attackers that are in the path of the
messages that are exchanged.
The goals and requirements for this protocol are:
o Minimize the complexity of the protocol even if it is at the
expense of more messages being exchanged.
o Minimize the use of cryptographic algorithms.
o Ensure that a correspondent node does not retain state due to
receiving the first message in a binding update exchange, in order
to reduce the exposure to denial of service attacks.
o Prevent replays of binding updates after the MN has moved away to
a different link.
o Make replays of binding updates before the MN has moved away to a
different link as idempotent with the original binding update.
o Make it cryptographically hard for attackers that are not on any
of the paths between CN-HA or CN-MN to inject spoofed binding
updates.
draft-nordmark-mobileip-bu3way-00.txt [Page 6]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
o Use the pre-established security association between the MN and HA
to thwart Man-in-the-middle attacks for attackers on the path
between the MN and HA.
o When the correspondent is also a mobile node, use the secured path
between it and its home agent to reduce the threats from attackers
that are on the same link as the correspondent.
o Make it hard for attackers there are not on any of the paths to
inject spoofed Binding Acknowledgement messages.
The protocol uses the messages in [MIPv6] with some extensions and,
in addition, two new messages:
Binding Update Request (BUR): First message in 3-way handshake.
Sent from the MN to the CN.
Binding Update Challenge (BUC): Second message in 3-way
handshake. Sent by the CN when receiving a BUR. This
message includes information that the CN can use to
verify that the third message in the 3-way handshake
without requiring that the CN create state when
sending the BUC.
Binding Update (BU): Third message in the 3-way handshake. Echos
the information from the BUC. When the MN requests an
acknowledgement of the BU it includes a random number
that will be echoed in the Binding Acknowledgement
message.
Binding Acknowledgement (BA): Used as specified in [MIPv6] but
with the added ability to return the random number
included in a Binding Update message as a means to
weakly authenticate the BA.
Binding Request (BR): Used as specified in [MIPv6].
3.2. Message flow
When a MN determines that it wants a given CN to use route
optimization when sending packets to the MN, the MN initiates the
binding update 3-way handshake by sending a Binding Update Request
message to the CN. This message just includes the Care of Address
and Home Address of the MN.
draft-nordmark-mobileip-bu3way-00.txt [Page 7]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
The CN responds to this by sending a Binding Update Challenge message
to the Home Address of the MN, which serves to verify that IP routing
plus the home agent indeed forward packets to the node that sent the
BUR. The CN can get some assurance of this, without needing to
retain state for each BUR it receives, by including a cookie in the
BUC and verifying that the BU includes the same cookie. The purpose
of this check is to prevent nodes that are not on the path between
the CN, HA, MN, and CN to inject spoofed binding updates. The cookie
will be different for different MNs and even the same MN using
different Care of Addresses over time.
This document specifies how such a cookie can be created by the CN by
using a local timestamp mechanism (i.e., the time does not need to be
synchronized with other nodes; only the CN will inspect the timestamp
in the cookie) and a secret (random) number maintained by the CN
which the CN does not share with any other node. This allows the CN
to compute a keyed hash using its secret and the home address, care
of address, and timestamp. The recommended cookie consists of the
local timestamp followed by the result of the keyed hash.
The timestamp in the cookie allows the CN to immediately reject
replayed binding updates that are very old, as in older than e.g. 30
seconds (a maximum of the round-trip time of any Internet path).
This aids in rejecting old binding updates that are replayed after
the CN has lost its binding cache information, e.g. due to crashing
and rebooting or due to garbage collecting unused binding cache
entries. The protocol allows the CN to use different such lifetimes
for the cookies so that e.g. a CN that suspects a DoS attack to fill
up its Binding Cache can use shorter cookie lifetimes than 30
seconds.
The timestamp also allows the CN to use different secrets over time.
When the CN switches from using one secret to another it just needs
to remember what the timestamp value was at the time the switch was
made. With this information the CN can use the correct secret when
verifying the cookie in a received BU, even when the BU was sent when
the old secret was being used.
Each sent Binding Update Challenge message will use a new timestamp
value thus, as long as the CN maintains a binding cache entry for the
MN, the timestamp will prevent replays of old BUs.
The proposal also addresses the possibility of spoofed Binding
Acknowledgement messages. This case is simpler than the Binding
Update case since the MN creates some state when sending the BUR thus
this state can be augmented with a random cookie value without the
type of Denial-of-service concerns that are present in a CN handling
a BUR. This cookie is then sent in the Binding Update message and
draft-nordmark-mobileip-bu3way-00.txt [Page 8]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
the MN verifies that the Binding Acknowledgement message contains the
same cookie value. This prevents off-path attackers from spoofing a
Binding Acknowledgement message.
MN <=====================================
\ ||
\ ||
\ (1) BUR (HoA,CoA) ||
\ (4) BU (N1, timestamp) || (3) BUC
v ||
CN ------------------------------> HA
(2) BUC (N1=hash(secret, HoA, CoA, CN, timestamp,
cookie lifetime), timestamp)
The proposal specifies that the BUR, BUC, BU and BA messages should
be sent bypassing any binding cache entry on the sender in order to
prevent old, and potentially stale, binding cache information from
interfering.
Also, in order to avoid issues with ingress filtering and use the
MN-HA pre-established security association to reduce threats "close
to" mobile nodes, the BUC, BU, and BA messages, when the sender is a
mobile node, are reverse-tunneled through the sender's home agent.
This ensures that when two mobile nodes are communicating, i.e., the
correspondent is also a mobile node, the pre-established security
association between the mobile CN and its home agent is used to
prevent attackers close to the CN from injecting spoofed binding
updates or binding acknowledgements.
4. MESSAGE FORMATS
4.1. Binding Update Request Message Format
A Mobile node sends a Binding Update Request to a Correspondent Node
in order to start the 3-way binding update process.
draft-nordmark-mobileip-bu3way-00.txt [Page 9]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
The Care of Address assigned to the MN.
Destination Address
The CN's IP address.
ICMP Fields:
Type TBD
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Home Address The MN's Home Address.
4.2. Binding Update Challenge Message Format
A Binding Update Challenge message is sent by a node in response to a
Binding Update Request. The BUC is sent to the Home Address in the
BUR in order to verify that the MN is indeed reachable by using that
home address.
draft-nordmark-mobileip-bu3way-00.txt [Page 10]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie Life | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The destination address in the triggering BUR. If
the sender of the BUC is a mobile node itself then
this source address is likely to be its home
address. In this case the BUC MUST be reverse
tunneled through the sender's home agent to avoid
issues with ingress filtering.
Destination Address
The Home Address in the triggering BUR.
ICMP Fields:
Type TBD
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Cookie Life 8-bit field with an unsigned integer. The cookie
lifetime in units of seconds.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Care of Address
The Source IP address of the triggering BUR.
draft-nordmark-mobileip-bu3way-00.txt [Page 11]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
Cookie The information included by the CN in the BUC which
it expects to see returned in the Binding Update.
The length of the Cookie field is indicated by the
length of the ICMP packet.
4.3. Binding Update Message Format
Once an MN has received a BUC in response to its BUR it will send a
Binding Update to the CN.
NOTE: The description of the BU in this document is intentionally
incomplete. It only includes the information deemed necessary to
understand and discuss the security properties of the ideas presented
in this document. See [MIPv6] for the other information needed in a
Binding Update. The use of the Acknowledgement Cookie removes the
need for the Sequence number field specified in [MIPv6].
NOTE: For no reason, other than ease of cutting and pasting between
sections in this document, the binding update is described as an ICMP
packet. The ideas proposed in this document can be applied
independently of how the BU information is carried; destination
option, UDP packet, or whatever.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D| Reserved | Cookie Life |Prefix Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Acknowledgement Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-nordmark-mobileip-bu3way-00.txt [Page 12]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
| Cookie ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
The MN's Home Address copied from the Destination
Address field in the triggering BUC message. This
copying ensures that it is the same as the Home
Address field in the BUR. The BU MUST be reverse
tunneled through the sender's home agent to avoid
issues with ingress filtering.
Destination Address
The CN's address. MUST be the same as the
destination address in the BUR.
ICMP Fields:
Type TBD
Code 0
Checksum The ICMP checksum. See [ICMPv6].
A-bit Binding Acknowledgement as specified in [MIPv6].
Other bit flags, the Prefix Length, and Lifetime as
specified in [MIPv6]. Note that there is no
sequence number field necessary in this proposal.
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Cookie Life 8-bit field with an unsigned integer. The cookie
lifetime in units of seconds. Copied from the BUC
message.
Acknowledgment Cookie
Only used when the A-bit is set. A 64-bit random
number set by the MN used to match the Binding
Acknowledgement with the Binding Update.
Care of Address
The same as the Care of Address field in the
received BUC, that is, the same as the Source
Address field in the BUR.
draft-nordmark-mobileip-bu3way-00.txt [Page 13]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
Cookie Copied from the Cookie field in the BUC. The
length of the Cookie field is indicated by the
length of the ICMP packet.
4.4. Binding Acknowledgement Message Format
A node sends a Binding Acknowledgement in response to a Binding
Request when the A-bit is set in the request.
NOTE: The description of the BA in this document is intentionally
incomplete. It only includes the information deemed necessary to
understand and discuss the security properties of the ideas presented
in this document. See [MIPv6] for the other information needed in a
Binding Acknowledgement. The use of the Acknowledgement Cookie
removes the need for the Sequence number field specified in [MIPv6].
NOTE: For no reason, other than ease of cutting and pasting between
sections in this document, the binding ack is described as an ICMP
packet. The ideas proposed in this document can be applied
independently of how the BA information is carried; destination
option, UDP packet, or whatever.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Acknowledgement Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-nordmark-mobileip-bu3way-00.txt [Page 14]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
IP Fields:
Source Address
The Destination Address in the triggering Binding
Update message. If the sender of the BA is a
mobile node itself then this source address is
likely to be its home address. In this case the BA
MUST be reverse tunneled through the sender's home
agent to avoid issues with ingress filtering.
Destination Address
The Source Address in the triggering BU message.
This is the Home Address of the MN sending the BU.
ICMP Fields:
Type TBD
Code 0
Checksum The ICMP checksum. See [ICMPv6].
Status See [MIPv6].
Reserved Unused field. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Lifetime See [MIPv6].
Refresh See [MIPv6].
Acknowledgement Cookie
64-bit field. Copied from the Acknowledgement
Cookie field in the triggering Binding Update
Message.
Care of Address
The Care of Address of the mobile node. Copied
from the Care of Address field in the triggering BU
message.
TBD: Does this field serve any purpose? It is
currently verified when the BA is received, but it
should be possible to omit it since the
Acknowledgement Cookie ensures that the BA is in
response to the last transmitted BU etc.
draft-nordmark-mobileip-bu3way-00.txt [Page 15]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
5. CONCEPTUAL MODEL OF A NODE
This section describes a conceptual model of one possible data
structure organization that nodes need to maintain in order to
implement [MIPv6] with the extensions and modifications specified in
this document. The described organization is provided to facilitate
the explanation of how the protocol should behave. This document
does not mandate that implementations adhere to this model as long as
their external behavior is consistent with that described in this
document.
5.1. Conceptual Data Structures
This section specifies the conceptual data structures with focus on
the parts that are different than in [MIPv6].
Each IPv6 node will need to maintain the following pieces of
information:
Binding Cache
- A cache capturing information for mobile nodes from which the
node has received and accepted a Binding Update message.
The cache is indexed by the Home Address of the MN. Each
entry contains:
o Home Address. See [MIPv6].
o Care of Address. See [MIPv6].
o The state of the binding. This can be either "valid" or
"invalid". Binding Cache entries only effect packet
transmission when they are in the "valid" state. In order
to prevent certain replay attacks, e.g., after a binding
has been removed by a BU with a zero lifetime, binding
cache entries might need to be retained to suppress
duplicates for up to CookieLifetime seconds. Such entries
are in "invalid" state.
o Lifetime of the binding. Once this lifetime expires the
binding cache entry must be either deleted or marked
invalid. Unlike [MIPv6] the lifetime is a function of
both the lifetime field in the BU packets and the delay
between generating the BUC cookie and receiving the BU.
o Last update time. This field contains the local timestamp
value from the cookie indicating when the binding cache
draft-nordmark-mobileip-bu3way-00.txt [Page 16]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
entry was created or last updated by a BU message.
o Cookie Lifetime. Set from the BU that last created or
updated the binding.
o The Acknowledgement Cookie value and an indication whether
this field is valid i.e. set from a Binding Update
message. This might be useful if the protocol is extended
to use the Acknowledgement Cookie to filter out spoofed
Binding Request messages. Note that this specification
currently does not apply such filtering; in fact it is
silent on the use of BR messages.
In addition, on a Home Agent the binding cache entries
contain additional information which is specified in [MIPv6].
AdvCookieLifetime.
- The CookieLifetime the CN uses to send in BUC messages. MUST
not exceed MAX_COOKIE_LIFETIME.
List of secrets
- A list with all the secrets that the CN has used to generate
BUC cookies in the last AdvCookieLifetime seconds. This list
contains either one or two entries, unless the CN creates a
new secret more often than every AdvCookieLifetime seconds.
Each entry in the list has the secret as well as the
timestamp value the last time the secret was used to create a
cookie.
Each Mobile Node, in addition to the above per-node conceptual data
structures, need to maintain
Binding Update List
- A list with all nodes to which the MN has sent a BUR or BU
and the binding has not yet expired.
The binding update list is indexed by address of the CN to
which the BUR or BU was sent and the Home Address i.e., there
can only be one entry per each <CN, HoA> pair.
Each entry contains:
o The IP address to which the BUR or BU was sent. See
[MIPv6].
draft-nordmark-mobileip-bu3way-00.txt [Page 17]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
o The Home Address for which the binding was made. See
[MIPv6].
o The Care of Address in the last binding update sent. See
[MIPv6].
o The state of the binding. The possible states are
BUC_WAIT (sent BUR; waiting for a BUC), BA_WAIT (send BU;
waiting for BA), NO_BA (sent BU not requesting a BA), and
BA_OK (not waiting for anything).
o Remaining Cookie Lifetime. Set to the CookieLifetime when
the BUC is received and decremented as time passes. This
is needed to avoid retransmitting BUs using a cookie that
is older than the CookieLifetime in the BUC since the CN
will ignore such cookies.
o When in the BA_WAIT or NO_BA state: the cookie received in
the BUC to be used when retransmitting the BU.
o The Acknowledgement Cookie value used.
o The initial value of the lifetime field sent in the BU.
See [MIPv6].
o The remaining lifetime of the binding. See [MIPv6].
o The time a BUR or BU was last sent (transmitted or
retransmitted) needed in order to rate limit the sending
and implement retransmissions.
o The state of the binary exponential back-off mechanism for
BUR and BU messages. This is a factor which is multipled
with the retransmit timer value and doubled for each
unsuccessful retransmission.
o A flag that, when set, indicates that future BUR and BU
messages should not be sent to the destination. See
[MIPv6].
5.2. Forming Cookies
The recommended way to form cookies is to use a secret (the current
secret in the list of secrets), a keyed hash, and a timestamp.
draft-nordmark-mobileip-bu3way-00.txt [Page 18]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
The timestamp should have a finer granularity than the minimal
spacing between subsequent binding updates in order to prevent two
binding updates from the same MN using the same timestamp. Should
the same timestamp be used then the "new" BU will be considered to be
a replay of an "old" BU and be ignored i.e., the MN would fail to
update the binding cache.
Therefor it is recommended that the timestamp have a granularity of
one millisecond or better.
The number of bits in the timestamp should be such that an attacker
can not just wait for the timestamp to wrap around and then replay an
old BU with what now looks like a new timestamp. This threat can be
avoided by requiring that a new secret is used before the time stamp
wraps around. For example, if a 32-bit timestamp with granularity
one millisecond is used than a new secret must be generated at least
every 4 million seconds i.e. about 1000 hours.
Note that when a new secret is generated the node should continue to
use the monotonically increasing timestamps to be able to tell
whether the old or new secret was used for handshakes that were in
progress during the change of secret.
When the node looses all state e.g., when it reboots, the node can
choose to either use the same secret as before the reboot provided
that it ensures that the timestamps are monotonically increasing
across the reboot and ensures that no BU message are accepted until
at least AdvCookieLifetime seconds after the loss of state. (The
latter is easy to ensure if it takes at least AdvCookieLifetime
seconds to reboot.) If the node can not make this guarantees then it
should select a new secret each time it reboots.
The secret MUST be a good random number as specified in [RANDOM].
The recommended algorithm to use for the keyed hash is for further
study. MD5 or SHA-1 are likely choices.
The keyed hash should operate on the concatenation of the timestamp,
the HoA, the CoA, and CN's address, and the AdvCookieLifetime that
will be sent in the Binding Update Challenge Message.
Then the cookie can be formed by concatenating the timestamp and the
hash value. With a 32-bit timestamp it becomes 4 octets of timestamp
followed by TBD bytes of hash.
TBD: Specify the length of the cookie based on the algorithm chosen.
draft-nordmark-mobileip-bu3way-00.txt [Page 19]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
5.3. Garbage Collection and Timeout Requirements
Unlike in [MIPv6] a CN can not arbitrarily choose to garbage collect
binding cache entries, since that would open up potential replay
attacks.
Independently of how a binding cache entry is deleted i.e. whether
its lifetime expires, the CN desires to garbage collect it, or the CN
receives a BU with a zero lifetime, the CN must retain the binding
cache entry in the "invalid" state for at least AdvCookieLifetime
seconds after the entry is deleted.
This ensures that even if an attacker sent a Binding Update Request
and received a cookie (valid for AdvCookieLifetime seconds) just
before the binding cache entry was deleted, the cookie contained in
the Binding Update Challenge can not be used to recreate an old
binding for the MN.
Even without the ability to do arbitrary garbage collection of
binding cache entries the CN can still control the size of this
cache. This can be done by rejecting either Binding Update Request
messages (by silently dropping them) or by rejecting Binding Update
messages when there is no more space in the cache. In addition, the
ability for the CN to use different CookieLifetime values can help.
But in order to conform the state loss behavior above the CN needs to
have a conservative (i.e., maximum) estimate of the CookieLifetime
value used before loosing the state. Thus a CN that varies the
AdvCookieLifetime over time must maintain the maximum cookie lifetime
value that it has used. This can be done by using the
MAX_COOKIE_LIFETIME constant.
As specified in [MIPv6] a mobile node can not choose to garbage
collect binding update list entries. They must be allowed to time
out based on the lifetime of the binding as specified in [MIPv6].
6. BEHAVIORAL SPECIFICATION
This section describes the rules for sending and receiving the
messages used by this protocol.
6.1. Sending Binding Update Request Messages
When a MN wishes to provide a binding update for a CN it first checks
if there is a binding update list entry for the <CN,HoA> pair. If
such an entry exists and is in state BUC_WAIT or BA_WAIT then there
draft-nordmark-mobileip-bu3way-00.txt [Page 20]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
is already an on-going attempt to create such a binding thus the
retransmissions will take care of creating one if possible.
If the state is BA_OK then the previous BU was acknowledged with a BA
and a new binding update exchange is only necessary should the CoA
have changed since the last one.
If the state if NO_BA it might be the case that the unacknowledged BU
was lost. In this case, assuming that "last sent" indicates that the
last BU was sent more than the binary backed off timeout seconds ago,
then an additional BU can be sent per the retransmission rules in
section 6.9. Note that the BU retransmission rules might determine
that the cookie from the BUC is too old and revert to sending a new
BUR.
If no binding update list entry then one is created for <CN,HoA>.
The state of the existing or created binding cache entry is set so
that
- The CoA is the current CoA of the MN
- the state is BUC_WAIT
- the time last sent set to the current time
- the binary exponential back-off factor set to 1.
- The flag to not send BUR/BU set to false
Then a BUR message is formatted according to section 4.1 and
transmitted.
Note that since the source address of the BUR is always the Care of
Address, the BUR will never be reverse tunneled to the HA of the
sender.
6.2. Retransmission of Binding Update Request Messages
When the retransmission timer fires and the binding update list entry
is in state BUC_WAIT the MN
- Double the binary exponential factor. This is used to compute the
next timeout value.
- Records the current time in the "time last sent"
draft-nordmark-mobileip-bu3way-00.txt [Page 21]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
- Retransmits the BUR message.
6.3. Validation of Binding Update Request Messages
A node MUST silently discard any received Binding Update Request
messages that do not satisfy all of the following validity checks:
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- The IP source address is not a multicast address or the
unspecified address.
- The IP destination address is not a multicast address or the
unspecified address.
- The Home Address field is not a multicast address or the
unspecified address.
The contents of the Reserved field and any data after the first 24
octets MUST be ignored. Future, backward-compatible changes to the
protocol may specify the contents of the Reserved field or add fields
after the Home Address field; backward-incompatible changes may use
different Code values.
A binding update request that passes the validity checks is called a
"valid BUR".
6.4. Processing Valid Binding Update Request Messages
The processing consists of forming a cookie as specified in section
5.2 and sending a Binding Update Challenge message.
No state is created on the node doing this processing.
draft-nordmark-mobileip-bu3way-00.txt [Page 22]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
6.5. Sending Binding Update Challenge Messages
A BUC message is formatted as specified in section 4.2. The
CookieLifetime field is set to the value of AdvCookieLifetime.
If the sending node has a binding cache entry for the destination of
the BUC then the sending MUST bypass that and send the packet
directly to the destination address i.e. not add a routing header per
the information in the binding cache. This ensures that the HA-MN
pre-established security association can be used to provide
confidentiality for the cookie between the HA and MN.
If the sending node is a mobile node itself then it MUST reverse
tunnel the BUC message through its home agent. This removes any
concerns about ingress filtering and allows the cookie field to be
confidential on the path from the sender to its home agent.
The Binding Update Challenge messages are never retransmitted.
Instead, if the BUC is lost, then MN will retransmit the BUR causing
a new BUC to be sent.
6.6. Validation of Binding Update Challenge Messages
A node MUST silently discard any received Binding Update Challenge
messages that do not satisfy all of the following validity checks:
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 24 or more octets.
- The IP source address is not a multicast address or the
unspecified address.
- The IP destination address is not a multicast address or the
unspecified address.
- The Care of Address field is not a multicast address or the
unspecified address.
The contents of the Reserved field MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents
of the Reserved field; backward-incompatible changes may use
different Code values.
draft-nordmark-mobileip-bu3way-00.txt [Page 23]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
A binding update challenge that passes the validity checks is called
a "valid BUC".
6.7. Processing Valid Binding Update Challenge Messages
The MN will first look up the <CN, HoA> in the binding update list.
If no entry is found, if the entry is not in BUC_WAIT state, or if
the CoA field does not match the Care of Address field in the BUC,
then the BUC must be silently dropped.
Then the MN updates the binding update list information with
- Record the time the BUC was received
- Record the Cookie.
- Record the CookieLifetime in the Remaining Cookie Lifetime. This
value will limit for how long the BU will be retransmitted using
this cookie.
- Cancel any timer for retransmitting the BUR for that entry.
- Set the state of NO_BA.
- Set the time last sent to the current time (since a BU will be
sent)
- Reset the exponential back-off factor to 1.
- Set the lifetime field in the binding cache entry to the lifetime
value that will be sent in the BU.
In addition, if the MN will set the A-bit in the BU in order to
request a Binding Acknowledgement it:
- Computes a 64-bit random number and store that in the
Acknowledgement Cookie field in the binding cache entry.
- Sets the state to BA_WAIT.
6.8. Sending Binding Update Messages
If the sending node has a binding cache entry for the destination of
the BU then the sending MUST bypass that and send the packet directly
draft-nordmark-mobileip-bu3way-00.txt [Page 24]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
to the destination address i.e. not add a routing header per the
information in the binding cache. This ensures that the HA-MN pre-
established security association can be used to provide
confidentiality for the cookie between the HA and MN.
The source address of the BU is the Home Address. Thus the packet
MUST be reverse tunneled through the home agent. This removes any
concerns about ingress filtering and allows the cookie field and
acknowledgement cookie field to be confidential on the path from the
sender to its home agent.
Then a BUR message is formatted according to section 4.3 and
transmitted.
6.9. Retransmission of Binding Update Messages
When the state is BA_WAIT BUs will be retransmitted based on a
timeout. When the state is NO_BA then BUs will be retransmitted,
subject to the rate limiting imposed by the binary exponentially
backed off timeout value, when the MN receives a packet from the CN
which has been tunneled by the HA to the MN since this indicates that
the CN did not receive and accept the BU message.
When this happens and the Remaining Cookie Lifetime in binding update
list entry is less than zero the then the cookie is too old to use in
a retransmission. In this case the state should be changed to
BUC_WAIT without changing the binary exponential back-off factor and
immediately retransmit the BUR as specified in section 6.2.
Otherwise the retransmission should be handled as follows:
- Double the binary exponential factor. This is used to compute the
next timeout value.
- Records the current time in the "time last sent"
- Retransmits the BU message. If the A-bit is set the
Acknowledgement Cookie field is set from the binding cache entry
i.e., retransmitted BU messages have the same Acknowledgement
Cookie value.
draft-nordmark-mobileip-bu3way-00.txt [Page 25]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
6.10. Validation of Binding Update Messages
A node MUST silently discard any received Binding Update messages
that do not satisfy all of the following validity checks:
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 40 or more octets.
- The IP source address is not a multicast address or the
unspecified address.
- The IP destination address is not a multicast address or the
unspecified address.
- The Care of Address field is not a multicast address or the
unspecified address.
The contents of the Reserved field MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents
of the Reserved field; backward-incompatible changes may use
different Code values.
A binding update that passes the validity checks is called a "valid
BU".
6.11. Processing Valid Binding Update Messages
The CN must first extract the timestamp and the hash from the cookie
field in order to verify them. The suggestion in section 5.2 is that
the timestamp is the first 4 octets of the cookie followed by the
hash.
If the timestamp is more than the CookieLifetime field in the BU or
the CookieLifetime field is more than MAX_COOKIE_LIFETIME then the
message MUST be silently discarded. If the timestamp is new i.e.
greater than the current time then the message is a replay after the
timestamp wrapped around and the message MUST be silently discarded.
The node use the timestamp to determine which secret was used to
generate the keyed hash based on the secret list. Then it can
compute the keyed hash using the same algorithm that it used when
draft-nordmark-mobileip-bu3way-00.txt [Page 26]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
sending the BUC; using that secret and the information in the packet
(Care of address, Correspondent address, Home address, timestamp, and
CookieLifetime) as specified in section 5.2. If the generated hash
does not match the hash in the received cookie then the packet MUST
be silently discarded.
Next the node MUST verify against the binding cache to make sure that
the BU is not the replay of an old binding update. If there is no
binding cache entry for the home address then the BU can not be a
duplicate per the rules in section 5.3. If there already exists a
binding cache entry for the home address then compare the "last
update time" timestamp in that entry with the timestamp contained in
the cookie. If the timestamp is older than the one in the binding
cache entry then the BU MUST be silently discarded. Note: BUs where
the timestamp matches are processed in order to generate a Binding
Acknowledgement in response to a retransmitted BU.
At this point the node knows that the BU is indeed a valid and
authentic one. Thus it creates or updates the entry in binding cache
as specified in [MIPv6]. Note that the lifetime used is the above
conservative estimate. In addition it records the timestamp part of
the cookie field in the "last update" field in the binding cache
entry. (Note that the timestamp in the cookie is recorded - not the
current time when the BU is received by the CN.)
If a BU with a lifetime of zero is received an no binding cache entry
exists then no binding cache entry needs to be created. However,
should a binding cache entry exist in this case than that entry can
not be immediately deleted in all cases. The binding cache entry
must remain in "invalid" state for at least CookieLifetime seconds
after the last non-zero lifetime BU was received as specified in
section 5.3 in order to prevent replays after MN moves home and de-
registers.
If the A-bit is set in the BU message the node records the
Acknowledgement Cookie in the binding cache entry and sends a Binding
Acknowledgement message.
6.12. Sending Binding Acknowledgement Messages
If the sending node has a binding cache entry for the destination of
the BA then the sending MUST bypass that and send the packet directly
to the destination address i.e. not add a routing header per the
information in the binding cache. This ensures that the HA-MN pre-
established security association can be used to provide
confidentiality for the acknowledgement cookie between the HA and MN.
draft-nordmark-mobileip-bu3way-00.txt [Page 27]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
If the sending node is a mobile node itself then it MUST reverse
tunnel the BA message through its home agent. This removes any
concerns about ingress filtering and allows the cookie field to be
confidential on the path from the sender to its home agent.
Form the Binding Ack as follows:
- The Lifetime field is set to the minimum of the conservative
lifetime above and whatever the CN wishes to support.
- The Status and Refresh is set as in [MIPv6].
- The acknowledgement cookie and care of address is set from the
binding cache fields.
The binding acknowledgement is never retransmitted by the CN. Should
the BA be lost then the MN will retransmit the BU and in some cases
the MN will need to retransmit the BUR due to a too old cookie.
6.13. Validation of Binding Acknowledgement Messages
A node MUST silently discard any received Binding Acknowledgement
messages that do not satisfy all of the following validity checks:
- ICMP Checksum is valid.
- ICMP Code is 0.
- ICMP length (derived from the IP length) is 40 or more octets.
- The IP source address is not a multicast address or the
unspecified address.
- The IP destination address is not a multicast address or the
unspecified address.
- The Care of Address field is not a multicast address or the
unspecified address.
The contents of the Reserved field and any data after the first 40
octets MUST be ignored. Future, backward-compatible changes to the
protocol may specify the contents of the Reserved field or add fields
after the Care of Address field; backward-incompatible changes may
use different Code values.
draft-nordmark-mobileip-bu3way-00.txt [Page 28]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
A binding acknowledgement that passes the validity checks is called a
"valid BA".
6.14. Processing Valid Binding Acknowledgement Messages
The MN will first look for a matching <CN, HoA> in the binding update
list. If no entry exists, the CoA doesn't match, or the state in the
entry is not BA_WAIT then the BA MUST be silently discarded.
If the acknowledgement cookie field in the packet does not match the
acknowledgement cookie in the binding update list then the packet
MUST be silently discarded.
Mark the binding update list entry with state BA_OK and stop any
timers associated with retransmitting BUs.
7. SECURITY PROPERTIES
The following set of threats are believed to be handled by the
proposal:
- Off-paths attackers are prevented by the use of the Cookie in the
BUC-BU exchange.
- Off-path attackers can't inject spoofed binding acknowledgements
due to the acknowledgement cookie in the BU-BA exchange.
- Replay attacks of BUs after a new BU has been received by a CN are
ignored due to the timestamp in the cookie being older.
- Replay attacks of BUs while the MN is in the location indicated by
the BU has no effect; the cookie can not be used with a different
CoA, Home Address, CN address, or timestamp.
- Replay attacks after a MN has moved home and unregistered with a
CN (using a BU with lifetime zero) have no effect since the
binding cache state is maintained (with no effect on routing) for
AdvCookieLifetime.
- While the MN remains at the same CoA there is no effect of
replaying/repeating the same BU since it doesn't redirect packets
away from the correct CoA. Replay attacks after a MN has become
unreachable are of course possible for CookieLifetime seconds, but
once the MN becomes reachable on a different link, it will
initiate a new BUR/BUC/BU exchange based on the binding update
list. The rules in section 6.11 ensure that this will happen.
draft-nordmark-mobileip-bu3way-00.txt [Page 29]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
- Replay attacks due to the CN garbage collecting the binding cache
entries or loosing state are avoided using the rules in section
5.3.
- Flooding of spoofed BUR messages to a CN causes the CN compute a
keyed hash and to send a BUC message. It does not create any
state based on this. The BUC message is sent to the Home Address
field in the BUR, but the IP source address of the BUR is included
in the BUC message. Thus this can not be used as a more severe
type of reflector attack than e.g. an ICMP echo packet. [TBD: The
reflector threat is a bit different than an ICMP echo due to the
extra address in the packets. Perhaps the BUR should be sent with
the HoA as the source i.e. reverse tunneled through the HA to
reduce the reflector risk.]
- Flooding of spoofed BUC and BA packets cause a minimal amount of
work to determine that the corresponding BUR and BU where never
sent.
- Flooding of spoofed BU packets causes some work on the CN to
compute the keyed hash and compare it with the cookie in the
message in order to reject the message.
7.1. Residual Threats
A node capable of passively observing packets between the CN and HA
as well as being able to send packets, can redirect packets for any
MN using that HA. This requires neither being able to modify the
packets being delivered towards the HA, nor being able to prevent
those packets from being delivered.
Note that the above threat is introduced by Binding Updates whether
or not the node named MN is indeed a mobile node; there is no way a
CN can tell that a node isn't mobile. The reception of a binding
update is taken as proof that the sender is indeed mobile.
This is done by the attacker sending a BUR and seeing the resulting
BUC, taking the cookie from that packet to form a BU. The MN will
also observe the BUC but it will silently ignore it since it has not
sent a BUR (and having the MN do anything differently would make BUCs
a potential DoS attack opportunity).
If ingress filtering [INGRESS] is used then the CoA that the attacker
can use is limited to what the attacker can put in the IP source
address field, which is not very limiting.
draft-nordmark-mobileip-bu3way-00.txt [Page 30]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
Note that this threat is potentially more severe than what it takes
to redirect traffic without using of Binding Updates; an attacker on
the path between two nodes can of course observe all the traffic but
it requires some active capability on the link for it to be able to
prevent this packets to be delivered. An example of such active
capabilities would be use of the Neighbor Discovery protocol on a
shared Ethernet to make packets destined to the next hop router
instead arrive at the attacker.
A particular flavor of this attack is an attacker or the same LAN as
the CN or HA.
Note that the threat applies to any node; the CN has no means of
determining whether a node is mobile or not but instead infers this
from the reception of a BU with a matching cookie.
A node capable of passively observing packets between the HA and MN
can launch the same type of attack under the same constraints. This
includes nodes on the same LAN as the MN. However, if the pre-
established security association between the HA and MN provides in
confidentiality, then such attacks are prevented.
It is also possible for an attacker to inject spoofed data traffic
(e.g., an ICMP echo) from a valid CN address to the MN with the
intent to make the MN perform a binding update exchange which will
create state in the CN's binding cache and in the MN's binding update
list. This threat is external and independent of the actual
mechanism to perform the binding update. The only known technique to
address it is to have some threshold in the MN when it comes to
performing a binding update which a CN which isn't already in the
binding update list so that it requires multiple packets to and from
the CN before the binding update is triggered. Note that CNs in the
binding update list need to be notified of the new CoA when the MN
moves thus they can not be subject to such a threshold.
TBD: Does the ICMP parameter problem cause a threat? As specified
[MIPv6] the reception of such indicating that the CN doesn't
understand binding update options/messages is supposed to make the MN
stop sending binding updates to the CN. They could be used to make a
MN mark the binding update list entry as "don't bother sending BUR/BU
to this node". It isn't clear what affect such marking will (or
should) have on the behavior of the MN and whether this behavior can
be exploited. Thus such ICMP messages appear to be usable by an
attacker to prevent a CN from receiving binding updates.
draft-nordmark-mobileip-bu3way-00.txt [Page 31]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
7.2. HA to MN Security Association
A possible way to prevent attackers on the path between the HA and MN
is to protect all packets that the HA tunnels to the MN using a pre-
established security association that provides confidentiality.
However, such a approach might be deemed costly for mobile devices
with limited crypto performance. Thus there might be a desire to
only apply the confidentiality to packets related to binding updates;
in particular the BUC packets containing the cookie needed to
generate a BU.
This could be approached by making the HA apply different security
associations depending on the content of the packets being
encapsulated. The specification of selectors in [IPv6-SA], appear to
say that the selectors (such as protocol type; port numbers) apply
when packets are forwarded as well as originated. However, it isn't
clear to what extent existing IPsec implementations have this
capability to use different IPsec tunnels depending on the selectors
in the forwarded packets. Also, it isn't clear what the performance
impact would be in such a case since the Home Agent would need to
inspect the selectors when forwarding packets to mobile nodes.
Conceptually an alternative would be to make the BUC packets be
addressed to the Home Agent (instead of the MN's Home Address) but
this is non-trivial since
o The CN has no way of finding out the address of the HA
o In general the MN can't tell the CN the HA address, since that
would allow a form of spoofing by an attacker claiming that the HA
is some node other than the real HA.
It might be possible, by hard-coding the knowledge of 64-bit
prefixes, to either:
o Have the CN determine the all-home agents anycast address for the
MN based on the MN's home address.
o Have the MN send a HA's address to the CN, and have the CN verify
that the address falls in the same 64-bit prefix as the MN's home
address.
But hard-coding the 64-bit prefix boundary in nodes that are not
attached to the particular link where the prefix is assigned would
remove some flexibility in evolving the IPv6 addressing architecture
draft-nordmark-mobileip-bu3way-00.txt [Page 32]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
over the lifetime of the IPv6 protocol.
7.3. MN to MN Binding Updates
As specified any attacker on the same LAN as the CN can redirect
traffic destined from the CN to any node on the Internet as outlined
in the previous section.
Of course, such a threat might not be much severe than the ability to
use Neighbor Discovery to spoof the IP address of the routers on the
LAN, thereby being able to redirect or capture all packets sent by a
CN. Given the increasing prevalence of wireless LANs and other
public access LANs, it is important to understand the security
properties for such cases.
However, in the case that the CN is also a mobile node, i.e., it has
a pre-established security association with its home agent, then this
security association potentially provides better security than
without mobile IPv6. This is done by the specification requiring
that BUC, BU, and BA messages are reverse tunneled to the HA, which
is also required to avoid any ingress filtering problems for the BUC
and BA messages.
This specification also requires that the BUC, BU and BA messages are
sent bypassing any binding cache entry. This means that a
correspondent that is mobile can in fact reject any BUC, BU and BA
messages that are not received over the secure channel from its HA.
----------
| |
| HA1 |
| | ------------- LAN
---------- | |
| | ---------- ----------
| | | | | |
| | Secure tunnel | CN | | X |
| | | | | |
| | ---------- ----------
| |
----------
| |
| MN1 |
| |
----------
Figure 1: Attacker next to CN
draft-nordmark-mobileip-bu3way-00.txt [Page 33]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
In Figure 1 the X can send a BUR to CN specifying that the home
address MN1 and the care of address X (or any other care of address).
Note that MN1 could be any node in the Internet; in particular it
does not need to be a mobile node.
X would be able to observe the BUC sent by the CN towards the
specified home address, and could use this to send a BU to the CN.
---------- ----------
| | | |
| HA1 | | HA2 |
| | | |
---------- ----------
| | | |
| | | |
| | Secure tunnel | | Secure tunnel
| | | |
| | | ------------- LAN
| | | | | |
---------- ---------- ----------
| | | | | |
| MN1 | | MN2 | | X |
| | | | | |
---------- ---------- ----------
Figure 2: Attacker next to CN which is a mobile node
Given the rules in section 6, the same attack would not be effective
in figure 2. While X can send the BUR to MN2, MN2 will reverse
tunnel the BUC to HA2 and HA2 will forward the packet towards HA1.
Thus assuming that the MN2-HA2 security association provides
confidentiality then X is not able to generate a BU with a matching
cookie. And MN1 will not respond to the BUC caused by the spoofed
BUR since it did not send the BUR.
8. ORTHOGONAL SECURITY ISSUES
The following issues that have been identified on the Mobile IP WG
mailing list are not addressed in this document:
- Use of unauthenticated Home Address options for general reflector
attacks.
- Possible DoS attacks by flooding Binding Requests; potentially
with spoofed IP source addresses.
draft-nordmark-mobileip-bu3way-00.txt [Page 34]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
It is the author's belief that solutions to that problem are
orthogonal to the proposed use of 3-way BUs.
For instance, a possible solution to the unauthenticated Home Address
option would be to
- have the CNs reject packets with a Home Address option unless they
have a matching binding cache entry, and
- require that MNs by default tunnel all packets (where the IP
address is its home address) through its home agent
- When the MN knows that the CN will accept the Home Address option
i.e., when it has received a binding ack from the CN, the it can
optionally use the Home Address option thus avoid tunneling
packets through the home agent.
- A CN can not discard (garbage collect or loose) a binding cache
entry until the lifetime of the binding expires, unless it can
notify the MN that it can no longer use a home address option.
Thus such a solution has no bearing on the proposal in this document.
Also, handling of Binding Requests is also likely to be orthogonal.
A MN could simply silently ignore any binding requests unless it has
a binding update list entry for the CN and Home Address.
Note in such an approach the acknowledgement cookie provided by this
proposal might be helpful; one could require that the binding request
contain the acknowledgement cookie from the last BU to prevent off-
path attackers from injecting binding requests with a spoofed CN IP
source address.
The details of addressing these threats are outside of the scope of
this document.
9. WHAT IFS - ALTERNATE APPROACHES
This section tries to provide some initial thoughts on how the
security properties of the solution would change with a few
modifications to the protocol described above. The purpose of this
is to try to feed a discussion in order to gain a wider understanding
of how the security properties are different in different parts of
the design space.
This section does not claim to be complete. In fact it only looks at
draft-nordmark-mobileip-bu3way-00.txt [Page 35]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
two possible modifications:
o During the first 3-way BU as specified in the protocol,
additionally pass a clear-text key from the CN through the HA to
the MN. The MN can then use that key to authenticate future BUs
and not require a 3-way handshake.
o As part of the first 3-way BU exchange perform a Diffie-Hellman
exchange to establish a shared secret between the MN and CN. Use
the shared secret to secure future BUs.
The purpose of looking at the first modification is to understand the
implications of trying to optimize the exchange for subsequent BUs.
The purpose of looking at the second modification is to try to
understand how to potentially limit the capabilities of attackers
that are mostly passive.
9.1. Establish a Key for Authenticating BUs
For the purposes of making it simple to describe this modification it
makes sense to introduce an additional message: Authenticated Binding
Update (ABU) Such a message could of course be encoded as a variant
of the BU message.
Also, without loss of generality, assume that it is the Binding
Acknowledgement that carries the authentication key from CN to MN.
[It is also possible to carry this on the BUC but in order to avoid
the CN creating state when receiving a BUR this requires making the
authentication key be derived in similar ways to the Cookie sent in
the BUC. This is probably possible but introduces complexities that
are not believed to be germane to understanding the security
properties in general.]
We also assume that the CN send the BA to the Home Address (i.e.,
bypassing any binding cache entries). While this isn't strictly
required it does allow using the assumed MN to HA security
association to obtain higher security.
The idea in this modification is that the exchange consists of a BUR,
BUC, BU, and an additional BA. In the BU there is a bit indicating
that the MN requests a authentication key. This causes the CN to
generate such a key, store it in the binding cache entry, and send it
in the clear to the MN with the binding ack.
Presumably the binding ack would be extended to carry not only the
key but also the lifetime of the key and the algorithm used to
draft-nordmark-mobileip-bu3way-00.txt [Page 36]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
authenticate such as HMAC-SHA1.
The MN would then, after verifying the binding ack using the
acknowledgement cookie as before, store the authentication key in the
binding update list.
When the MN needs to update the binding in the CN, it would form a
Authenticated Binding Update message and authenticate that using the
key and algorithm. This then forms some authentication data which is
included in the ABU.
The CN then needs to verify the ABU packet. It would use the Home
Address to lookup the binding cache entry for the MN. This would
contain the authentication key which is then used to verify the
authentication data included in the ABU. Presumably the ABU would
contain a sequence number (starting at zero for the first ABU sent
after receiving the authentication key) that might protect against
certain replay attacks.
The properties of such a scheme seem to be that, since anybody on the
path between the CN and the HA can see the BA packet, attackers on
path can redirect packets. To no surprise this isn't any better than
the proposed 3-way protocol.
But also, an attacker that was on the path between the HA and MN when
the authentication key was established but due to later movements of
the MN no longer is on that path, can use the authentication key to
redirect the MN's traffic during the lifetime of the authentication
key. The use of a sequence number in the ABU packet doesn't protect
against this since the attacker can presumably pick large sequence
numbers whereas the MN itself would use sequence numbers 0,1,2,3 etc
as it moves. Thus such a sequence number would just protect against
subsequent BU packets from the legitimate MN being reordered in the
network.
The above concern can presumably be addressed by requiring that the
BA containing the authentication key be protected by an HA to MN
security association that provides confidentiality. In such a case
the cursory analysis on this approach seems to have the same security
properties as the original 3-way proposal i.e. in that case they
share the same residual threats with respect to nodes that are on the
path between the CN and HA.
9.2. Diffie-Hellman Exchange
Assume that once the BUR/BUC/BU exchange has happened there is an
ephemeral Diffie-Hellman exchange between the CN and MN. This
draft-nordmark-mobileip-bu3way-00.txt [Page 37]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
exchange could presumably be done by the CN sending packets to the
MN's home address and the MN reverse tunneling the packets through
its home agent. Such an approach, combined with confidentiality for
these packets over the HA-MN path, seems to add additional security
beyond the original 3-way proposal.
In particular, an attacker would need to be more active than an
attacker in the 3-way scheme. For instance, an attacker on the same
LAN as the CN would not only need to observe the packets passing by
but would instead need to actively insert itself as a Man-in-the-
Middle in the Diffie-Hellman exchange by intercepting packets in both
directions, being able to inject modified packets, and perhaps being
able to prevent that the original packets it intercepted are not
delivered. [TBD: Is this difference significant?]
If a DH exchange is done it can presumably start with the BU i.e.,
the BU and BA packets would perform the exchange. It would be
undesirable to start the exchange before this point in time since the
CN should avoid to create any state before the 3-way handshake has
completed.
10. PROTOCOL CONSTANTS
Common constants:
MAX_COOKIE_LIFETIME 30 seconds
All protocol constants are subject to change in future revisions of
the protocol.
11. CONCLUSIONS
The section tries to extract some lessons from designing and
analyzing the bu3way proposal.
For the purposes of this section we define these names for the
variants of the proposal:
o bu3way-int is the proposal with just integrity protection for the
HA-MN paths
o bu3way-conf is the proposal with confidentiality on the HA-MN
paths
o bu3way+key-int is the outline of the ideas in section 9.1 with
just integrity for the HA-MN paths
draft-nordmark-mobileip-bu3way-00.txt [Page 38]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
o bu3way+key-conf is that outline with confidentiality on the HA-MN
paths
The conclusions so far are:
- bu3way-int: Anybody on the MN-HA path can spoof binding updates as
long as they are on the path. They have to spoof for each BU sent
by the MN. So when the MN moves they will loose this ability if
they are no longer on the MN-HA path.
- bu3way-conf: No such spoofing possible.
- bu3way+key-int: Anybody on the HA-MN path when the key is
established can spoof BUs for the lifetime of the key even after
they are no longer on the HA-MN path due to the MN having moved.
- bu3way+key-conf: No such spoofing possible.
For potential attackers on the CN-HA path there is not much
difference whether or an authentication key is distributed or not.
With bu3way such an attacker can send a BUR with e.g. itself as the
CoA and snoop the BUC packet between the CN and HA and use it to send
a BU that will be accepted. But if ingress filtering [INGRESS] is
used it can not pick an arbitrary CoA, since the CoA is the source
address in the BUR.
With bu3way+key such an attacker can just silently snoop the key from
the BUC and at some later time during the lifetime of that key, send
a BU using any CoA.
In addition, using DH exchange instead of bu3way+key is different in
that it requires attackers on the CN-HA path to actively insert
themselves as a man-in-the-middle in the DH exchange, which may or
may not be more difficult than just snooping at the packets as they
pass by.
There are also some performance tradeoffs between distributing an
authentication key or not:
o How many binding updates are performed between a pair of MN and CN
vs. the cost of creating the authentication key. If there is only
one binding update than bu3way+key is slower since it needs to
generate a key.
draft-nordmark-mobileip-bu3way-00.txt [Page 39]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
12. SECURITY CONSIDERATIONS
Security issues are discussed in section 7.
TBD Need to evaluate with respect to [SEC-REQ]
13. ACKNOWLEDGEMENTS
The security requirements, threats, and proposed solutions that have
been discussed on the MobileIP WG mailing list have help form this
the approach taken in this document.
Phil Roberts, Jari Arkko, and Claude Castellucci provided comments
that helped clarify the document. Phil suggested making the
CookieLifetime a choice for the CN instead of it being a protocol
constant.
REFERENCES
[ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", draft-ietf-ipngwg-icmp-v3-01.txt.
[IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[MIPv6] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft-
ietf-mobileip-ipv6-14.txt.
[IPv6-SA] R. Atkinson. "Security Architecture for the Internet
Protocol". RFC 2401, November 1998.
[IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402,
November 1998.
[IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)",
RFC 2406, November 1998.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[INGRESS] P. Ferguson, D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing.", RFC 2827, May 2000.
draft-nordmark-mobileip-bu3way-00.txt [Page 40]
INTERNET-DRAFT Securing BUs using routability (BU3WAY) Nov 12, 2001
[SEC-REQ] A. Mankin et al, "Threat Models introduced by Mobile IPv6
and Requirements for Security in Mobile IPv6", draft-ietf-
mobileip-mipv6-scrty-reqts-02.txt.
[RANDOM] D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
AUTHORS' ADDRESSES
Erik Nordmark
Sun Microsystems Laboratories, Europe
29 Chemin du Vieux Chene
38240 Meylan, France
phone: +33 (0)4 76 18 88 03
fax: +33 (0)4 76 18 88 88
email: Erik.Nordmark@sun.com
draft-nordmark-mobileip-bu3way-00.txt [Page 41]