Network Working Group C. Vogt
Internet-Draft Univ. of Karlsruhe, Germany
Expires: August 18, 2005 February 14, 2005
Credit-Based Authorization for HIP Mobility with Concurrent
IP-Address Tests
draft-vogt-hip-credit-based-authorization-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
End-host mobility with the Host Identity Protocol uses IP-address
tests to protect against malicious packet redirection and third-party
flooding. The tests cause handover signaling delays to increase by
one round-trip time. This document proposes a credit-based strategy
that allows peers to securely resume active communications after
handover as soon as possible, and to pursue a concurrent IP-address
Vogt Expires August 18, 2005 [Page 1]
Internet-Draft Credit-Based Authorization February 2005
test subsequently. The optimization thus eliminates the additional
handover delay that IP-address tests entail.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Redirection-Based Flooding . . . . . . . . . . . . . . . . . . 3
3. Review of HIP Mobility . . . . . . . . . . . . . . . . . . . . 5
4. Credit-Based Authorization . . . . . . . . . . . . . . . . . . 7
5. Applying CBA . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informational References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Vogt Expires August 18, 2005 [Page 2]
Internet-Draft Credit-Based Authorization February 2005
1. Introduction
End-host mobility [3] with the Host Identity Protocol (HIP) [1]
allows a mobile node to change its point of IP attachment without
loosing active communications connections. Peers mutually
authenticate themselves through their cryptographic identifiers.
Unfortunately, mobility introduces the possibility for a new type of
amplified flooding attacks in spite of authentication: In such an
attack, the perpetrator, who may or may not be really mobile, claims
to have moved to a new IP subnet and registers a victim's IP address
as its alleged new locality. The correspondent node can so be
tricked into spamming the victim with unwanted packets.
Flooding attacks have been thoroughly considered in recent research
[1][3][5][6][9]. In HIP, a mobile node must show that it is
reachable at a new IP address which it wants to register with a peer.
Specifically, it must return a probing packet with some unguessable
piece of data that its peer sends to it. Yet, an adverse side effect
of this IP-address test is that it increases handover latency by one
round-trip time, precluding interactive or real-time applications in
many scenarios.
This document presents "Credit-Based Authorization" (CBA), an
optimization mechanism that allows HIP nodes to securely use a new IP
address while this address is being probed. CBA can reduce signaling
delays by one round-trip time, which amounts to 50% of the overall
latency in the case of HIP. Following this introduction, Section 2
further discusses the threat of redirection-based flooding attacks.
Section 3 is a brief review of the HIP mobility protocol. Section 4
explains CBA conceptually, and Section 5 describes how CBA can be
integrated with HIP mobility. Section 6 provides additional security
considerations. Section 7 finally concludes this document.
CBA was originally proposed for Mobile IPv6 Early Binding Updates
[7][8], where it allows for secure concurrent care-of-address tests.
It was first presented at the 59th IETF meeting in Seoul, Republic of
Korea, in February 2004.
2. Redirection-Based Flooding
This section discusses new possibilities for malicious packet
redirection and third-party flooding that poorly designed mobility
protocols could introduce. It relates these to similar threats in
the non-mobile Internet, discusses the role of packet filtering, and
outlines and evaluates the protection mechanism used in end-host
mobility with HIP.
Vogt Expires August 18, 2005 [Page 3]
Internet-Draft Credit-Based Authorization February 2005
HIP nodes can mutually authenticate themselves by means of their
cryptographic identifiers. Mutual authentication, however, does not
imply any sort of trust between the nodes. As a consequence, it is
often unclear from the correspondent node's perspective whether a
mobile node is faithful with respect to its current locality. The
mobile node might misuse such unawareness for redirecting packets,
the true recipient of which it itself is, to a victim somewhere else
in the Internet. Redirection-based flooding attacks are an
attractive means for denial of service because of their enormous
potential for amplification at relatively low cost [6]. For
instance, a mobility protocol that fails to provide appropriate
counter-measures would allow an attacker to setup a TCP connection
through its own IP address, learn the initial sequence number this
way, and subsequently redirect the connection to someone else's
address. The attacker could influence the rate of misrouted TCP
segments through fake acknowledgements that appear to originate from
the redirection target. As the segments are typically much bigger
than their acknowledgements, the correspondent node would spend,
unknowingly, much more resources on the flooding attack than the
attacker itself.
One may argue that flooding attacks are already a major problem in
the non-mobile Internet [10], and that mobility protocols such as [3]
cannot do anything about them. However, it is important to
understand that misuse of packet redirection could render these
attacks much more accessible: Today's attackers gain amplification
by compromising as many Internet nodes as possible through viral
software and have them contribute to the attack this way. In
contrast, a widely deployed, but improperly designed mobility
protocol would allow the attacker to take advantage of the large base
of co-operating nodes, making any viral assaults unnecessary.
Most mobility protocols hinder registration of false IP addresses by
requiring mobile nodes to put a new IP address in the Source Address
field of the registration message's IP header. Filtering techniques
on the mobile node's side [4] so get a chance to unveil fraudulent
registration attempts. Yet, the problem with verifying IP source
addresses at the fringe of the Internet is that it does not fully
protect unless applied universally. It is questionable whether this
will always be the case. As things stand, an attacker can always
find a network where no filtering is applied, even though the
technique has already been deployed in many places. Mobility
protocols should hence provide independent protection against
malicious packet redirection.
As previously mentioned, end-host mobility with HIP requires the
mobile node to receive and return some random data at a new IP
address before any data packets are sent to that address. A
Vogt Expires August 18, 2005 [Page 4]
Internet-Draft Credit-Based Authorization February 2005
successful exchange guarantees that the mobile node either owns the
new IP address, or is at least on the path towards it. In either
case, any packets sent to the address are routed to, or via, the
mobile node. The rationale for considering this evidential that no
flooding attack is in the making is that an attacker in such a
position would not depend on redirection: It could wage a flooding
attack more easily by setting up, say, a TCP connection directly on
behalf of its victim.
3. Review of HIP Mobility
This section is a brief outline of the HIP base protocol and its
extension for mobility support. The protocol details can be found in
[2] and [3].
HIP uses a node's DSA or RSA public key, rather than an IP address,
as a "Host Identifier" (HI) at stack layers above IP. A HI is hashed
into a 128-bit "Host Identity Tag" (HIT) to have it be syntactically
compatible with an IPv6 address. Peers swap their HITs and actual IP
addresses within a shim layer between the IP stack and upper layers.
The advantage of a HI over an IP address is that the owner can
*cryptographically* prove to a peer that its identifier is correct
through being able to sign or decrypt messages with the corresponding
private key. HIP uses this feature to authenticate a Diffie-Hellman
key exchange for IPsec ESP protection of both signaling and data
packets.
Mobile Node Correspondent Node
| |
|-I1--------------------------->| Select puzzle
| |
Solve puzzle |<---------------------------R1-|
Compute D-H | |
|-I2--------------------------->| Check puzzle
| | Compute D-H
|<---------------------------R2-|
| |
Figure 1: HIP Base Exchange
Contact establishment is shown in Figure 1. Either one of the peers,
the initiator, starts a "HIP base exchange" by sending the other, the
responder, an I1 message. This prompts the responder to send its HI
Vogt Expires August 18, 2005 [Page 5]
Internet-Draft Credit-Based Authorization February 2005
and a public Diffie-Hellman key to the initiator in the R1 message.
The initiator, in turn, provides its HI and a public Diffie-Hellman
key in the I2 message. Based on their own private and the other's
public Diffie-Hellman keys, both peers compute secret shared keying
material from which authentication and encryption keys are taken.
Finally, the R2 message serves to activate IPsec ESP processing on
both sides. The R1, I2, and R2 messages are signed with the HIs.
This makes the base exchange robust to man-in-the-middle attacks.
Since a Diffie-Hellman key exchange includes heavy cryptographic
computations, it can potentially be misused for a resource-exhaustion
attack against the responder. In such an attack, the perpetrator
uses any random number as its public Diffie-Hellman key and makes the
responder compute keying material from it. The perpetrator may
repeat the attack with different falsified IP source addresses and
bogus HIs. (HI verification is equivalent to Diffie-Hellman key
generation in terms of computational complexity.)
Resource-exhaustion attacks can be averted by requiring the initiator
to invest some reasonable effort before the responder does so. To
this end, the R1 message contains a random number X, a "puzzle",
which the initiator has to concatenate with both peers' HITs and with
a number Y such that the hash on the concatenation yields a string
with a certain minimum of trailing zeros. The R1 message, including
its signature, can be pre-computed and reused across multiple base
exchanges. The appealing property of a puzzle is that the complexity
of solving it grows exponentially with the required count of trailing
zeros, whereas a potential solution can be validated very
efficiently.
Mobile nodes can change their IP addresses without running the base
exchange again. They may derive new keys at any time, but usually
retain their existing ones across multiple handovers. When the
mobile node moves to a different IP subnet, it configures a new IP
address and signals it to its peer through an Update message carrying
a Readdress parameter (UPD[REA]). The UPD[REA] holds the
corresponding IPsec Security Parameter Index, the new IP address, and
some auxiliary data. The IPsec ESP context, within which all
signaling takes place, ensures the authenticity of this UPD[REA].
Figure 2 illustrates the registration procedure.
Vogt Expires August 18, 2005 [Page 6]
Internet-Draft Credit-Based Authorization February 2005
Mobile Node Correspondent Node
| |
Handover ~ |
Use new address |-UPD[REA]--------------------->|
| |
|<----------------UPD[ECHO_REQ]-|
| |
|-UPD[ECHO_RESP]--------------->| Use new address
| |
Figure 2: HIP Address Registration
A node may register multiple IP addresses with its peer and declare
one of them "preferred". IP-address verification is mandatory only
in case the preferred address changes to an address that has not yet
been actively used. To verify a mobile node's reachability at a new
preferred address, the peer sends an Update message including an Echo
Request parameter (UPD[ECHO_REQ]). The UPD[ECHO_REQ] includes a
random number, which the mobile node must return in an Update message
with an Echo Response parameter (UPD[ECHO_RESP]).
4. Credit-Based Authorization
The HIP mobility extension requires verification of a mobile node's
reachability at a new IP address *before* data packets are sent to
that address. This inhibits direct use of the new IP address as soon
as it becomes available. At the same time, as previously explained,
the severity of redirection-based flooding attacks over conventional
flooding attacks not so much emanates from packet redirection per se,
but rather from the enormous potential for flooding amplification.
If no amplification could be gained through redirection, it would
just be easier for an attacker to bombard its victim directly. As a
consequence, introducing a mechanism that prevents this amplification
would affort reasonably secure, *immediate* use of a new IP address
subsequent to handover. Such is the approach followed by CBA.
CBA allows a peer to probe a mobile node's reachability at a new IP
address while the address is already in active use. This conforms
with the UNVERIFIED and ACTIVE address states that [3] defines: The
new IP address is UNVERIFIED until the correspondent node knows the
result of the reachability test, and it is ACTIVE thereafter. The
idea of CBA is to restrict the maximum data volume and rate that a
peer can send to an UNVERIFIED IP address to the data volume and rate
that the mobile node has sent the other way in the recent past. For
Vogt Expires August 18, 2005 [Page 7]
Internet-Draft Credit-Based Authorization February 2005
this, the mobile node has a credit account at the peer. The account
fills up as the mobile node sends packets to the peer. Subsequent to
handover, while the new IP address is UNVERIFIED, packets sent to
this address consume the credit. Packets continue to be sent there
as long as sufficient credit is left.
The balance of a mobile node's credit account increases and decreases
proportionally to the size of the received and sent packets. This
guarantees that the data volume sent to an UNVERIFIED IP address
cannot be greater than the previously received data volume. In
addition, unused credit withers over time through exponential aging.
This helps to bound the rate at which data can be sent to an
UNVERIFIED IP address by the rate at which data was previously
received.
Up to this point, the mobile node earns credit for sending packets,
while it needs the credit for receiving them. This works well when
traffic patterns are for the most part symmetric, as it is in the
case of Internet telephony. On the other hand, asymmetric traffic
patterns are also very common. File transfers and media streaming,
for instance, feature high throughput towards the client, typically
the mobile node, and comparably little throughput towards the serving
peer.
To prevent a mobile node from running out of credit, CBA can be made
a bit more sophisticated. The key observation is that the mobile
node invests comparable effort for packet reception as for packet
transmission, in terms of bandwidth, memory, and processing capacity.
It hence stands to reason that packets received by the mobile node
may be taken as the basis for credit allocation, just like the
packets that the mobile node sends. The question, though, is how the
peer can determine how many of the packets sent to the mobile node
are actually received and processed at the other end. The mobile
node may position itself behind a low-bandwidth link and deliberately
collect more credit than appropriate. It may also fake
transport-protocol acknowledgements as previously explained. To
overcome the issue, the peer needs some feedback on packet-loss
conditions along the path towards the mobile node. Such feedback can
optionally be provided through "IP-Address Spot Checks". Here, the
peer periodically tags packets that it sends to the mobile node with
a random, unguessable token. When the mobile node receives the
packet, it stores it in a cache until a local application delivers
the next packet for the peer. The mobile node includes all cached
tokens in this packet and sends it. The peer keeps an eye on how
many of the tokens that it sent the mobile node correctly returns.
New credit is allocated proportionally. The preciseness of
IP-Address Spot Checks can be traded with overhead through the
frequency with which they are exercised.
Vogt Expires August 18, 2005 [Page 8]
5. Applying CBA
Applying CBA to end-host mobility with HIP is straightforward. The
peer switches to the new, UNVERIFIED IP address when it receives the
UPD[REA], and changes the address status to ACTIVE upon reception of
the UPD[ECHO_RESP]. Figure 3 illustrates this procedure.
Mobile Node Correspondent Node
| |
Handover ~ |
Use new address |-UPD[REA]--------------------->| Use UNVERIFIED
| | address
|<----------------UPD[ECHO_REQ]-|
| |
|-UPD[ECHO_RESP]--------------->| Address ACTIVE
| |
Figure 3: HIP Address Registration with CBA
6. Security Considerations
The HIP mobility extension requires cryptographic authentication
before packets can be redirected to a new IP address. This prevents
unauthorized nodes from interfering with other nodes' communications
connections. It is hence a common understanding that the only
conceivable purpose of malicious packet redirection is third-party
flooding.
There are plenty of tactics for non-amplified flooding in the
current, non-mobile Internet. In its simplest form, an attacker can
directly spam a victim with unwanted packets. Another possibility is
TCP-SYN flooding. Most of these tactics require less coordinative
effort than a redirection-based flooding attack. It hence stands to
reason that an attacker will use a redirection-based flooding attack
only if it can expect a gain in terms of amplification.
CBA precludes amplification and should therefore sufficiently
discourage redirection-based flooding attacks. However, it is
important to recognize that CBA does not prevent packet redirection
per se.
Heuristics for misuse detection have been considered as a possible
Vogt Expires August 18, 2005 [Page 9]
Internet-Draft Credit-Based Authorization February 2005
alternative to CBA. If responsive enough, they can prevent, or at
least effectually discourage, malicious packet redirection. The
challenge here seems to be a good trade-off: On one hand, the
heuristic must be sufficiently rigid to stop an attacker early on.
On the other hand, it should not adversely affect communications with
faithful mobile nodes.
7. Conclusions
Mobility protocols may introduce a new type of flooding attacks if
designed without sufficient precautions. Compared to existing
flooding techniques, such redirection-based flooding attacks can
yield unprecedented amplification at negligible investments from the
attacker's side, jeopardizing not only nodes that participate in the
mobility protocol, but the Internet at a whole.
This document explains the new threat of malicious packet
redirection, clarifies why existing security techniques fail to
provide full protection, and infers that it is up to the mobility
protocols themselves to protect against it. The document evaluates
the standard security mechanism adopted in end-host mobility with
HIP, namely, to probe a new IP address before any data packets are
sent there. As it becomes evident that this simple approach
adversely affects handover latency, a credit-based strategy,
Credit-Based Authorization, is proposed for secure concurrent
probing. Finally, the document explains how Credit-Based
Authorization can be integrated into mobility with HIP, where it can
reduce handover-signaling delays by 50%.
8. References
8.1 Normative References
[1] Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", Internet-Draft draft-ietf-hip-arch (work in
progress).
[2] Moskowitz, R., Nikander, P., Jokela, P. and T. Henderson, "Host
Identity Protocol", Internet-Draft draft-ietf-hip-base (work in
progress).
[3] Nikander, P., Arkko, J. and T. Henderson, "End-Host Mobility and
Multi-Homing with Host Identity Protocol",
Internet-Draft draft-ietf-hip-mm (work in progress).
Vogt Expires August 18, 2005 [Page 10]
Internet-Draft Credit-Based Authorization February 2005
8.2 Informational References
[4] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", RFC 2827, May 2000.
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", Internet-Draft draft-ietf-mip6-ro-sec (work
in progress).
[6] Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments",
Internet-Draft draft-roe-mobileip-updateauth (work in
progress).
[7] Vogt, C. and J. Arkko, "Credit-Based Authorization for Mobile
IPv6 Early Binding Updates",
Internet-Draft draft-vogt-mobopts-credit-based-authorization
(work in progress).
[8] Vogt, C., "Early Binding Updates for Mobile IPv6",
Internet-Draft draft-vogt-mobopts-early-binding-updates (work
in progress).
[9] Aura, T., Roe, M. and J. Arkko, "Security of Internet Location
Management", Proceedings of the Computer Security Applications
Conference, December 2002.
[10] Paxson, V., "An Analysis of Using Reflectors for Distributed
Denial-of-Service Attacks", ACM SIGCOMM Computer Communication
Review, volume 31, number 3, July 2001.
Author's Address
Christian Vogt
Institute of Telematics
University of Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany
Email: chvogt@tm.uka.de
URI: http://www.tm.uka.de/~chvogt/
Vogt Expires August 18, 2005 [Page 11]
Internet-Draft Credit-Based Authorization February 2005
Appendix A. Acknowledgements
For their valuable feedback and advice with respect to the work
presented in this paper the author wishes to thank Jari Arkko, Roland
Bless, Mark Doll, Lars Eggert, Tobias Kuefner, Marco Liebsch, Pekka
Nikander, and Lars Voelker.
Vogt Expires August 18, 2005 [Page 12]
Internet-Draft Credit-Based Authorization February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vogt Expires August 18, 2005 [Page 13]