[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01
Host Identity Protocol R. Hummen, Ed.
Internet-Draft M. Henze
Intended status: Experimental RWTH Aachen University,
Expires: January 10, 2013 Communication and Distributed
Systems Group
July 09, 2012
HIP Middlebox Puzzle Offloading and End-host Notification
draft-hummen-hip-middle-puzzle-00
Abstract
The Host Identity Protocol [RFC5201] is a secure signaling protocol
with a cryptographic namespace. It provides the communicating peers
with a cryptographic puzzle mechanism to protect against Denial of
Service (DoS) attacks targeting its computation and memory overhead.
This document specifies an extension that enables middleboxes to
assist in the choice of the puzzle difficulty as well as in solving
the puzzle on behalf of the host.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Notation
{x} indicates that x is signed.
Initiator is the host that initiates a HIP association
(cf. HIP base protocol).
Responder is the host that responds to the INITIATOR
(cf. HIP base protocol).
--> signifies "Initiator to Responder" communication.
<-- signifies "Responder to Initiator" communication.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Hummen & Henze Expires January 10, 2013 [Page 1]
Internet-Draft Hip-Middle-Puzzle July 2012
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hummen & Henze Expires January 10, 2013 [Page 2]
Internet-Draft Hip-Middle-Puzzle July 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Considerations concerning the HIP puzzle . . . . . . . . . . . 4
2.1. Resource-constrained Initiator . . . . . . . . . . . . . . 5
2.2. Resource-constrained Responder . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Assisting Resource-constrained Initiators . . . . . . . . 6
3.2. Assisting Resource-constrained Responders . . . . . . . . 7
4. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. HOST_OFFLOADING_SUPPORT . . . . . . . . . . . . . . . . . 8
4.2. MIDDLEBOX_OFFLOADING_SUPPORT . . . . . . . . . . . . . . . 9
4.3. OFFLOADED_SOLUTION . . . . . . . . . . . . . . . . . . . . 9
4.4. VIA_UNTRUSTED_NETWORK . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Hummen & Henze Expires January 10, 2013 [Page 3]
Internet-Draft Hip-Middle-Puzzle July 2012
1. Introduction
The Host Identity Protocol (HIP) [RFC5201] is a secure signaling
protocol that introduces a cryptographic namespace for the
identification and authentication of the communicating peers. As the
protocol employs computationally expensive public-key-based
operations in the protocol exchange, HIP provides the communicating
peers with mechanisms to protect against Denial of Service (DoS)
attacks targeting its computation and memory overhead. Specifically,
the Responder in the protocol handshake may require the Initiator to
solve a dynamically adjustable cryptographic puzzle. The puzzle
enables the Responder to require a commitment of resources from the
Initiator before performing computationally expensive operations and
setting up association state.
While such a protection mechanism is generally desirable for
protocols involving computationally expensive operations, the correct
choice of the puzzle difficulty is hard. This is especially true in
communication scenarios where the resources of the communicating
peers are highly diverse. An example for such a scenario is a
resource-constrained sensor node communicating with a comparably
powerful modern desktop computer.
This document specifies an extension of the HIP signaling channel
that enables middleboxes to participate in the handshake between two
hosts in order to assist either in the choice of the puzzle
difficulty or in solving the puzzle. To this end, the extension
introduces additional signaling between hosts and middleboxes that
are located on the communication path. The corresponding message
exchanges and the newly introduced parameters are described in this
document. Note, however, that the recommendation of specific puzzle
difficulties is out-of-scope for this document as these are highly
scenario and situation dependent.
2. Considerations concerning the HIP puzzle
The cryptographic puzzle mechanism used in HIP allows the responder
to protect against maliciously induced computations as well as memory
exhaustion. In a scenario without load, the Responder should set the
puzzle difficulty K to 0. As a result, any value is a correct
solution for the puzzle. Hence, the Initiator does not need to
commit resources into solving the puzzle to continue the HIP
handshake. However, when the Responder is under high load (e.g., due
to an on-going attack), it may increase the puzzle difficulty K. The
exact value of K should depend on the available resources of the
Initiator in order to prevent the use of undemanding or excessively
hard puzzles. However, IP addresses, HITs, and cipher suites that
Hummen & Henze Expires January 10, 2013 [Page 4]
Internet-Draft Hip-Middle-Puzzle July 2012
are known to the Responder when setting the puzzle difficulty do not
suffice to make this information available to the Responder.
+--------------+---------------+--------------------------+
| Difficulty K | MSP430 16 MHz | Intel Core 2 Duo 2.4 GHz |
+--------------+---------------+--------------------------+
| 5 | 0.15 sec | 0.001 sec |
| 10 | 4.92 sec | 0.02 sec |
| 15 | 127.06 sec | 0.45 sec |
| 20 | 4253.08 sec | 14.90 sec |
+--------------+---------------+--------------------------+
Table 1: Average time for solving puzzles with difficulty K for
sensor-class (MSP430) and desktop-class (Core 2 Duo) devices over 50
measurements
Table 1 shows that high values of K (e.g., K = 20) require an
excessive number of computations for sensor-class devices, while low
puzzle difficulties (e.g., K = 5) only provide negligible protection
against modern desktop-class attackers. This observation results in
the following two obstacles when using a puzzle to protect the
Responder against DoS attacks.
2.1. Resource-constrained Initiator
Assume a scenario where a resource-constrained device initiates a new
handshake with an (Internet-connected) desktop-class Responder that
is currently under high load (e.g., due to an attack). In the
optimal case (i.e., without NATs), the Responder learns the IP
address of the Initiator, its HIT, and the DH_GROUP_LIST. However,
the provided information does not allow the Responder to deduce
whether it is communicating with a resource-constrained or a
comparably powerful device. Hence, the Responder has to guess the
class of the Initiator and set the puzzle difficulty accordingly. If
the Responder sets the puzzle difficulty for a desktop-class device,
the puzzle is most likely unsolvable for sensor-class devices.
Likewise, if the Responder assumes a sensor-class device, the puzzle
does not protect against DoS attacks from a desktop-class device. As
the latter choice negates the use of the puzzle mechanism, the
Responder should always set the difficulty such that it protects
against attacks from computationally powerful peer hosts.
In order to enable communication with a resource-constrained device
despite the use of high puzzle difficulties, this document proposes a
mechanism that allows resource-constrained Initiators to offload
solving of the puzzle to on-path middleboxes.
Hummen & Henze Expires January 10, 2013 [Page 5]
Internet-Draft Hip-Middle-Puzzle July 2012
2.2. Resource-constrained Responder
Assume a scenario where resource-constrained devices primarily
communicate with each other. However, at the same time, they are
directly accessible from the Internet via gateway nodes. An example
for such a network topology may be a 6LowPAN-enabled sensor network
that is equipped with a 6LBR (see Section 1.2 in
[I-D.ietf-6lowpan-nd]).
If a HIP-enabled device initiates a new connection with a resource-
constrained device that is currently under high load (e.g., due to an
attack), the resource-constrained Responder cannot identify the
capabilities of the peer similarly to the case described above.
Hence, the Responder does not protect itself against malicious
Internet hosts, if he sets a puzzle difficulty that is suitable for
sensor-class devices. Contrarily, if he sets the puzzle difficulty
too high, this prevents connections from benign sensor-class devices.
To allow communication with other legitimate resource-constrained
devices, the resource-constrained Responder should use puzzle
difficulties targeting other resource-constrained devices. However,
to still protect against malicious desktop-class devices, this
document introduces a mechanism that enables the on-path gateway to
signal the Responder that traffic is routed via an untrusted network.
This enables the Responder to set higher puzzle difficulties in case
of communication where the capabilities of the peer host are
uncertain.
3. Protocol Overview
This section gives an overview of the interaction between hosts and
middleboxes that assist resource-constrained hosts in using the HIP
puzzle mechanism. Specifically, this document describes how
resource-constrained Initiators can offload solving of a puzzle to an
on-path middlebox and how a middleboxes can signal resource-
constrained Responders to set the puzzle difficulty for Internet
hosts.
3.1. Assisting Resource-constrained Initiators
A resource-constrained Initiator may receive a puzzle that would
require excessive computations. If energy, time, or availability
constraints do not allow the Initiator to solve the puzzle itself, it
can offload its computation to on-path middleboxes.
As puzzle offloading requires changes to the SOLUTION parameter, the
offloading Initiator, the computing middlebox, and the verifying
Hummen & Henze Expires January 10, 2013 [Page 6]
Internet-Draft Hip-Middle-Puzzle July 2012
Responder are required to support the extension described in this
documents. Hence, end host (EOS) and middlebox puzzle offloading
support (MOS) are negotiated in the R1 packet (see Figure 1). As a
result of the negotiation, the Initiator learns if the puzzle
offloading extension described in this document can be used when
processing the received R1 packet.
Initiator Middlebox Responder
.-----------------.
I1 | Add MOS | I1
-----------------> | |---------------------------->
| |
R1, EOS + MOS | Add MOS | R1, + EOS
<----------------- | |<----------------------------
| |
I2, + OS | Solve Puzzle | I2, OS
-----------------> | Add Solution |---------------------------->
| |
R2 | | R2
<----------------- | |<----------------------------
'-----------------'
EOS: End-host Offloading Support
MOS: Middlebox Offloading Support
OS: Offloaded Solution
Figure 1
In the I2 packet, the OFFLOADED_SOLUTION replaces the SOLUTION
parameter (see Figure 1). The OFFLOADED_SOLUTION has got the same
parameter layout as the original SOLUTION parameter. However, it is
placed in the unsigned part of the I2 packet. The Initiator echoes
the puzzle parameters in the OFFLOADED_SOLUTION, while leaving the
solution value blank. When receiving an OFFLOADED_SOLUTION
parameter, an on-path middlebox computes the solution based on the
parameter fields in the OFFLOADED_SOLUTION parameter and places the
solution value in the blank solution field of the OFFLOADED_SOLUTION.
The algorithm used to compute the puzzle solution can be derived from
the HIT of the Responder contained in the HIP header. Note that the
puzzle offloading extension is designed not to require additional
state at either the initiator, the middlebox, or the responder.
3.2. Assisting Resource-constrained Responders
A resource-constrained device that is currently under high load may
receive an initial handshake packet (I1). In order to protect
against attacks from within the local (resource-constrained) network
environment, the Responder SHOULD set a low puzzle difficulty by
Hummen & Henze Expires January 10, 2013 [Page 7]
Internet-Draft Hip-Middle-Puzzle July 2012
default. To still protect against malicious Internet hosts, an on-
path middlebox notifies the Responder about handshakes that originate
from the Internet. Such a notification SHOULD trigger the Responder
to set a higher puzzle difficulty for this specific handshake
targeting the uncertain capabilities of the Internet-connected peer.
Initiator Middlebox Responder
.-----------------.
I1 | | I1 + IH
-----------------> | Add IH | ----------------->
| |
R1 | | R1
<----------------- | | <-----------------
| |
I2 | | I2
-----------------> | | ----------------->
| |
R2 | | R2
<----------------- | | <-----------------
'-----------------'
IH: Internet Host
Figure 2
As shown in Figure 2, the middlebox notifies the Responder in the I1
packet that the current handshake originates from an Internet host.
The Responder SHOULD then set the puzzle difficulty as to protect
against an attack from a desktop-class device.
4. HIP Parameters
This HIP extension specifies four new HIP parameters that allow on-
path middleboxes to assist in choosing a puzzle difficulty as well as
in computing a puzzle solution on behalf of a host.
4.1. HOST_OFFLOADING_SUPPORT
The Responder MAY append the HOST_OFFLOADING_SUPPORT parameter to an
R1 packet in order to indicate the support of the puzzle offloading
mechanism described in this document. The parameter is located in
the signed part of the HIP control packet and is, therefore, bound to
the host identity of the Responder.
Hummen & Henze Expires January 10, 2013 [Page 8]
Internet-Draft Hip-Middle-Puzzle July 2012
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 5600
Length 0
4.2. MIDDLEBOX_OFFLOADING_SUPPORT
A middlebox MAY append the MIDDLEBOX_OFFLOADING_SUPPORT parameter to
an R1 packet in order to indicate the support of the puzzle
offloading mechanism described in this document. The parameter is
located in the unsigned part of the HIP control packet. Middleboxes
SHOULD check for the existence of an MIDDLEBOX_OFFLOADING_SUPPORT in
the R1 packet before adding the parameter in order to prevent
multiple parameters of this type to be included in the R1 packet.
Note, however, that this check SHOULD be done for reasons of space-
efficiency and does not have an impact on the offloading mechanism
itself. Middleboxes that support the puzzle offloading extension
SHOULD NOT keep per-association state about their notifications.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64600
Length 0
4.3. OFFLOADED_SOLUTION
When receiving a HOST_OFFLOADING_SUPPORT and a
MIDDLEBOX_OFFLOADING_SUPPORT parameter in the R1 packet, the
Initiator MAY add the OFFLOADED_SOLUTION instead of the SOLUTION
parameter in the I2 packet. In this case, the Initiator SHOULD skip
the computation of the puzzle solution.
The structure and semantics of the OFFLOADED_SOLUTION parameter equal
the SOLUTION parameter in [RFC5201]. However, the Initiator sets the
#J to 0. This indicates that an on-path middlebox MUST compute the
puzzle solution.
Hummen & Henze Expires January 10, 2013 [Page 9]
Internet-Draft Hip-Middle-Puzzle July 2012
When receiving an I2 packet containing the OFFLOADED_SOLUTION
parameter, an on-path middlebox that supports the puzzle offloading
extension first inspects the #J. If #J is 0, the middlebox uses the
echoed PUZZLE values in the OFFLOADED_SOLUTION parameter as well as
the RHASH function to compute the puzzle solution. It then adds the
computed solution to the #J of the OFFLOADED_SOLUTION parameter.
Hence, the first middlebox supporting the puzzle offloading mechanism
computes the puzzle solution on behalf of the Initiator. Note that
the OFFLOADED_SOLUTION parameter is located in the unsigned part of
the HIP packet. Hence, the modification of the parameter by the
middlebox does not invalidate existing integrity protection
mechanisms.
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #K, 1 byte | Reserved | Opaque, 2 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random #I, n bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puzzle solution #J, RHASH_len/8 bytes |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64602
Length 4 + RHASH_len /4
#K #K is the number of verified bits
Reserved zero when sent, ignored when received
Opaque copied unmodified from the received PUZZLE
Random #I random number of size RHASH_len bits
Puzzle solution #J random number of size RHASH_len bits
4.4. VIA_UNTRUSTED_NETWORK
A middlebox MAY append the VIA_UNTRUSTED_NETWORK parameter to an R1
packet in order to indicate that the handshake is routed via an
untrusted network. As a result, the Responder SHOULD set the puzzle
difficulty in the PUZZLE parameter to target the uncertain
capabilities of the peer host.
Hummen & Henze Expires January 10, 2013 [Page 10]
Internet-Draft Hip-Middle-Puzzle July 2012
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64604
Length 0
5. Security Considerations
This document describes a modification of the HIP puzzle mechanism
used in the initial HIP handshake. The puzzle offloading extension
replaces the signed SOLUTION parameter by the unsigned
OFFLOADED_SOLUTION parameter. This allows an on-path attacker to
increase the puzzle difficulty K. As a result, the middlebox has to
commit additional resources for computing the puzzle solution for a
higher difficulty than originally required by the Responder.
The MIDDLEBOX_OFFLOADING_SUPPORT parameter is not cryptographically
bound to a specific middlebox that claims to support the extension
and to take over the workload of computing the puzzle solution.
Hence, an on-path attacker could use the new parameter to trick the
Initiator into using the offloading extension described in this
document, although it is not supported on the communication path or
despite the fact that he is unwilling to compute the puzzle solution.
As a result, the Responder would receive a blank, invalid puzzle
solution and drop the I2 packet. However, the attacker could achieve
the same result by simply dropping any of the handshake packets.
The VIA_UNTRUSTED_NETWORK parameter is not cryptographically bound to
the middlebox that claims a specific handshake to originate from an
untrusted network. Hence, an on-path attacker could trick the
Responder into increasing the puzzle difficulty, although the peer
host is within the local (resource-constrained) network environment.
As a result, the Initiator would drop the resulting puzzle due to its
excessive difficulty. However, the attacker could simply drop the I1
or the R1 packet in order to achieve the same result.
6. IANA Considerations
This document specifies four new HIP parameter types. The
preliminary parameter type numbers are 5600, 64600, 64602, and 64604.
Hummen & Henze Expires January 10, 2013 [Page 11]
Internet-Draft Hip-Middle-Puzzle July 2012
7. Acknowledgments
Thanks to Jens Hiller for commenting and helping to improve the
quality of this document.
8. Changelog
8.1. Version 0
- Initial Version
9. Normative References
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
Authors' Addresses
Rene Hummen (editor)
RWTH Aachen University, Communication and Distributed Systems Group
Ahornstrasse 55
Aachen 52074
Germany
Email: hummen@cs.rwth-aachen.de
URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/
Hummen & Henze Expires January 10, 2013 [Page 12]
Internet-Draft Hip-Middle-Puzzle July 2012
Martin Henze
RWTH Aachen University, Communication and Distributed Systems Group
Ahornstrasse 55
Aachen 52074
Germany
Email: henze@comsys.rwth-aachen.de
URI: http://www.comsys.rwth-aachen.de/team/martin-henze/
Hummen & Henze Expires January 10, 2013 [Page 13]
Html markup produced by rfcmarkup 1.127, available from
https://tools.ietf.org/tools/rfcmarkup/