Internet DRAFT - draft-hummen-hip-middle-puzzle
draft-hummen-hip-middle-puzzle
Host Identity Protocol R. Hummen, Ed.
Internet-Draft M. Henze
Intended status: Experimental J. Hiller
Expires: July 13, 2013 RWTH Aachen University,
Communication and Distributed
Systems Group
January 09, 2013
HIP Middlebox Puzzle Offloading and End-host Notification
draft-hummen-hip-middle-puzzle-01
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 exploiting the computation and memory overheads
of the protocol exchange. This document specifies an extension of
the protocol that enables an on-path network entity to assist in the
choice of the puzzle difficulty in case of an attack. Furthermore,
it defines a modification of the puzzle mechanism that enables a host
to delegate puzzle solving to an on-path network entity.
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
Hummen, et al. Expires July 13, 2013 [Page 1]
Internet-Draft Hip-Middle-Puzzle January 2013
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 13, 2013.
Copyright Notice
Copyright (c) 2013 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, et al. Expires July 13, 2013 [Page 2]
Internet-Draft Hip-Middle-Puzzle January 2013
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. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Hummen, et al. Expires July 13, 2013 [Page 3]
Internet-Draft Hip-Middle-Puzzle January 2013
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 overheads.
Specifically, the Responder in the protocol handshake may require the
Initiator to solve a cryptographic puzzle with a dynamically
adjustable difficulty. 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 on-path network entities (i.e., middleboxes [RFC3234])
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 with low or medium 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
Hummen, et al. Expires July 13, 2013 [Page 4]
Internet-Draft Hip-Middle-Puzzle January 2013
hard puzzles. However, IP addresses, HITs, and cipher suites that
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, et al. Expires July 13, 2013 [Page 5]
Internet-Draft Hip-Middle-Puzzle January 2013
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 it sets a puzzle difficulty that is suitable for
sensor-class devices. Contrarily, if it 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, et al. Expires July 13, 2013 [Page 6]
Internet-Draft Hip-Middle-Puzzle January 2013
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, et al. Expires July 13, 2013 [Page 7]
Internet-Draft Hip-Middle-Puzzle January 2013
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 + VUN
-----------------> | Add IH | ----------------->
| |
R1 | | R1
<----------------- | | <-----------------
| |
I2 | | I2
-----------------> | | ----------------->
| |
R2 | | R2
<----------------- | | <-----------------
'-----------------'
VUN: Via Untrusted Network
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, et al. Expires July 13, 2013 [Page 8]
Internet-Draft Hip-Middle-Puzzle January 2013
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, et al. Expires July 13, 2013 [Page 9]
Internet-Draft Hip-Middle-Puzzle January 2013
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, et al. Expires July 13, 2013 [Page 10]
Internet-Draft Hip-Middle-Puzzle January 2013
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, et al. Expires July 13, 2013 [Page 11]
Internet-Draft Hip-Middle-Puzzle January 2013
7. Changelog
7.1. Version 1
- Rename INTERNET_HOST to VIA_UNTRUSTED_NETWORK parameter in Figure 2
- Add reference to RFC 3234
- Editorial changes
7.2. Version 0
- Initial Version
8. 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-21 (work in progress),
August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[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, et al. Expires July 13, 2013 [Page 12]
Internet-Draft Hip-Middle-Puzzle January 2013
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/
Jens Hiller
RWTH Aachen University, Communication and Distributed Systems Group
Ahornstrasse 55
Aachen 52074
Germany
Email: hiller@comsys.rwth-aachen.de
Hummen, et al. Expires July 13, 2013 [Page 13]