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]