idnits 2.17.1 draft-hummen-hip-middle-puzzle-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5201]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 35 has weird spacing: '...itiator is t...' == Line 38 has weird spacing: '...sponder is t...' -- The document date (January 09, 2013) is 4118 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol R. Hummen, Ed. 3 Internet-Draft M. Henze 4 Intended status: Experimental J. Hiller 5 Expires: July 13, 2013 RWTH Aachen University, 6 Communication and Distributed 7 Systems Group 8 January 09, 2013 10 HIP Middlebox Puzzle Offloading and End-host Notification 11 draft-hummen-hip-middle-puzzle-01 13 Abstract 15 The Host Identity Protocol [RFC5201] is a secure signaling protocol 16 with a cryptographic namespace. It provides the communicating peers 17 with a cryptographic puzzle mechanism to protect against Denial of 18 Service (DoS) attacks exploiting the computation and memory overheads 19 of the protocol exchange. This document specifies an extension of 20 the protocol that enables an on-path network entity to assist in the 21 choice of the puzzle difficulty in case of an attack. Furthermore, 22 it defines a modification of the puzzle mechanism that enables a host 23 to delegate puzzle solving to an on-path network entity. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Notation 33 {x} indicates that x is signed. 35 Initiator is the host that initiates a HIP association 36 (cf. HIP base protocol). 38 Responder is the host that responds to the Initiator 39 (cf. HIP base protocol). 41 --> signifies "Initiator to Responder" communication. 43 <-- signifies "Responder to Initiator" communication. 45 Status of this Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on July 13, 2013. 61 Copyright Notice 63 Copyright (c) 2013 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Considerations concerning the HIP puzzle . . . . . . . . . . . 4 80 2.1. Resource-constrained Initiator . . . . . . . . . . . . . . 5 81 2.2. Resource-constrained Responder . . . . . . . . . . . . . . 6 82 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 83 3.1. Assisting Resource-constrained Initiators . . . . . . . . 6 84 3.2. Assisting Resource-constrained Responders . . . . . . . . 7 85 4. HIP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.1. HOST_OFFLOADING_SUPPORT . . . . . . . . . . . . . . . . . 8 87 4.2. MIDDLEBOX_OFFLOADING_SUPPORT . . . . . . . . . . . . . . . 9 88 4.3. OFFLOADED_SOLUTION . . . . . . . . . . . . . . . . . . . . 9 89 4.4. VIA_UNTRUSTED_NETWORK . . . . . . . . . . . . . . . . . . 10 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 94 7.2. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . 12 95 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 98 1. Introduction 100 The Host Identity Protocol (HIP) [RFC5201] is a secure signaling 101 protocol that introduces a cryptographic namespace for the 102 identification and authentication of the communicating peers. As the 103 protocol employs computationally expensive public-key-based 104 operations in the protocol exchange, HIP provides the communicating 105 peers with mechanisms to protect against Denial of Service (DoS) 106 attacks targeting its computation and memory overheads. 107 Specifically, the Responder in the protocol handshake may require the 108 Initiator to solve a cryptographic puzzle with a dynamically 109 adjustable difficulty. The puzzle enables the Responder to require a 110 commitment of resources from the Initiator before performing 111 computationally expensive operations and setting up association 112 state. 114 While such a protection mechanism is generally desirable for 115 protocols involving computationally expensive operations, the correct 116 choice of the puzzle difficulty is hard. This is especially true in 117 communication scenarios where the resources of the communicating 118 peers are highly diverse. An example for such a scenario is a 119 resource-constrained sensor node communicating with a comparably 120 powerful modern desktop computer. 122 This document specifies an extension of the HIP signaling channel 123 that enables on-path network entities (i.e., middleboxes [RFC3234]) 124 to participate in the handshake between two hosts in order to assist 125 either in the choice of the puzzle difficulty or in solving the 126 puzzle. To this end, the extension introduces additional signaling 127 between hosts and middleboxes that are located on the communication 128 path. The corresponding message exchanges and the newly introduced 129 parameters are described in this document. Note, however, that the 130 recommendation of specific puzzle difficulties is out-of-scope for 131 this document as these are highly scenario and situation dependent. 133 2. Considerations concerning the HIP puzzle 135 The cryptographic puzzle mechanism used in HIP allows the responder 136 to protect against maliciously induced computations as well as memory 137 exhaustion. In a scenario with low or medium load, the Responder 138 should set the puzzle difficulty K to 0. As a result, any value is a 139 correct solution for the puzzle. Hence, the Initiator does not need 140 to commit resources into solving the puzzle to continue the HIP 141 handshake. However, when the Responder is under high load (e.g., due 142 to an on-going attack), it may increase the puzzle difficulty K. The 143 exact value of K should depend on the available resources of the 144 Initiator in order to prevent the use of undemanding or excessively 145 hard puzzles. However, IP addresses, HITs, and cipher suites that 146 are known to the Responder when setting the puzzle difficulty do not 147 suffice to make this information available to the Responder. 149 +--------------+---------------+--------------------------+ 150 | Difficulty K | MSP430 16 MHz | Intel Core 2 Duo 2.4 GHz | 151 +--------------+---------------+--------------------------+ 152 | 5 | 0.15 sec | 0.001 sec | 153 | 10 | 4.92 sec | 0.02 sec | 154 | 15 | 127.06 sec | 0.45 sec | 155 | 20 | 4253.08 sec | 14.90 sec | 156 +--------------+---------------+--------------------------+ 158 Table 1: Average time for solving puzzles with difficulty K for 159 sensor-class (MSP430) and desktop-class (Core 2 Duo) devices over 50 160 measurements 162 Table 1 shows that high values of K (e.g., K = 20) require an 163 excessive number of computations for sensor-class devices, while low 164 puzzle difficulties (e.g., K = 5) only provide negligible protection 165 against modern desktop-class attackers. This observation results in 166 the following two obstacles when using a puzzle to protect the 167 Responder against DoS attacks. 169 2.1. Resource-constrained Initiator 171 Assume a scenario where a resource-constrained device initiates a new 172 handshake with an (Internet-connected) desktop-class Responder that 173 is currently under high load (e.g., due to an attack). In the 174 optimal case (i.e., without NATs), the Responder learns the IP 175 address of the Initiator, its HIT, and the DH_GROUP_LIST. However, 176 the provided information does not allow the Responder to deduce 177 whether it is communicating with a resource-constrained or a 178 comparably powerful device. Hence, the Responder has to guess the 179 class of the Initiator and set the puzzle difficulty accordingly. If 180 the Responder sets the puzzle difficulty for a desktop-class device, 181 the puzzle is most likely unsolvable for sensor-class devices. 182 Likewise, if the Responder assumes a sensor-class device, the puzzle 183 does not protect against DoS attacks from a desktop-class device. As 184 the latter choice negates the use of the puzzle mechanism, the 185 Responder should always set the difficulty such that it protects 186 against attacks from computationally powerful peer hosts. 188 In order to enable communication with a resource-constrained device 189 despite the use of high puzzle difficulties, this document proposes a 190 mechanism that allows resource-constrained Initiators to offload 191 solving of the puzzle to on-path middleboxes. 193 2.2. Resource-constrained Responder 195 Assume a scenario where resource-constrained devices primarily 196 communicate with each other. However, at the same time, they are 197 directly accessible from the Internet via gateway nodes. An example 198 for such a network topology may be a 6LowPAN-enabled sensor network 199 that is equipped with a 6LBR (see Section 1.2 in 200 [I-D.ietf-6lowpan-nd]). 202 If a HIP-enabled device initiates a new connection with a resource- 203 constrained device that is currently under high load (e.g., due to an 204 attack), the resource-constrained Responder cannot identify the 205 capabilities of the peer similarly to the case described above. 206 Hence, the Responder does not protect itself against malicious 207 Internet hosts, if it sets a puzzle difficulty that is suitable for 208 sensor-class devices. Contrarily, if it sets the puzzle difficulty 209 too high, this prevents connections from benign sensor-class devices. 211 To allow communication with other legitimate resource-constrained 212 devices, the resource-constrained Responder should use puzzle 213 difficulties targeting other resource-constrained devices. However, 214 to still protect against malicious desktop-class devices, this 215 document introduces a mechanism that enables the on-path gateway to 216 signal the Responder that traffic is routed via an untrusted network. 217 This enables the Responder to set higher puzzle difficulties in case 218 of communication where the capabilities of the peer host are 219 uncertain. 221 3. Protocol Overview 223 This section gives an overview of the interaction between hosts and 224 middleboxes that assist resource-constrained hosts in using the HIP 225 puzzle mechanism. Specifically, this document describes how 226 resource-constrained Initiators can offload solving of a puzzle to an 227 on-path middlebox and how a middleboxes can signal resource- 228 constrained Responders to set the puzzle difficulty for Internet 229 hosts. 231 3.1. Assisting Resource-constrained Initiators 233 A resource-constrained Initiator may receive a puzzle that would 234 require excessive computations. If energy, time, or availability 235 constraints do not allow the Initiator to solve the puzzle itself, it 236 can offload its computation to on-path middleboxes. 238 As puzzle offloading requires changes to the SOLUTION parameter, the 239 offloading Initiator, the computing middlebox, and the verifying 240 Responder are required to support the extension described in this 241 documents. Hence, end host (EOS) and middlebox puzzle offloading 242 support (MOS) are negotiated in the R1 packet (see Figure 1). As a 243 result of the negotiation, the Initiator learns if the puzzle 244 offloading extension described in this document can be used when 245 processing the received R1 packet. 247 Initiator Middlebox Responder 248 .-----------------. 249 I1 | Add MOS | I1 250 -----------------> | |----------------------------> 251 | | 252 R1, EOS + MOS | Add MOS | R1, + EOS 253 <----------------- | |<---------------------------- 254 | | 255 I2, + OS | Solve Puzzle | I2, OS 256 -----------------> | Add Solution |----------------------------> 257 | | 258 R2 | | R2 259 <----------------- | |<---------------------------- 260 '-----------------' 262 EOS: End-host Offloading Support 263 MOS: Middlebox Offloading Support 264 OS: Offloaded Solution 266 Figure 1 268 In the I2 packet, the OFFLOADED_SOLUTION replaces the SOLUTION 269 parameter (see Figure 1). The OFFLOADED_SOLUTION has got the same 270 parameter layout as the original SOLUTION parameter. However, it is 271 placed in the unsigned part of the I2 packet. The Initiator echoes 272 the puzzle parameters in the OFFLOADED_SOLUTION, while leaving the 273 solution value blank. When receiving an OFFLOADED_SOLUTION 274 parameter, an on-path middlebox computes the solution based on the 275 parameter fields in the OFFLOADED_SOLUTION parameter and places the 276 solution value in the blank solution field of the OFFLOADED_SOLUTION. 277 The algorithm used to compute the puzzle solution can be derived from 278 the HIT of the Responder contained in the HIP header. Note that the 279 puzzle offloading extension is designed not to require additional 280 state at either the initiator, the middlebox, or the responder. 282 3.2. Assisting Resource-constrained Responders 284 A resource-constrained device that is currently under high load may 285 receive an initial handshake packet (I1). In order to protect 286 against attacks from within the local (resource-constrained) network 287 environment, the Responder SHOULD set a low puzzle difficulty by 288 default. To still protect against malicious Internet hosts, an on- 289 path middlebox notifies the Responder about handshakes that originate 290 from the Internet. Such a notification SHOULD trigger the Responder 291 to set a higher puzzle difficulty for this specific handshake 292 targeting the uncertain capabilities of the Internet-connected peer. 294 Initiator Middlebox Responder 295 .-----------------. 296 I1 | | I1 + VUN 297 -----------------> | Add IH | -----------------> 298 | | 299 R1 | | R1 300 <----------------- | | <----------------- 301 | | 302 I2 | | I2 303 -----------------> | | -----------------> 304 | | 305 R2 | | R2 306 <----------------- | | <----------------- 307 '-----------------' 309 VUN: Via Untrusted Network 311 Figure 2 313 As shown in Figure 2, the middlebox notifies the Responder in the I1 314 packet that the current handshake originates from an Internet host. 315 The Responder SHOULD then set the puzzle difficulty as to protect 316 against an attack from a desktop-class device. 318 4. HIP Parameters 320 This HIP extension specifies four new HIP parameters that allow on- 321 path middleboxes to assist in choosing a puzzle difficulty as well as 322 in computing a puzzle solution on behalf of a host. 324 4.1. HOST_OFFLOADING_SUPPORT 326 The Responder MAY append the HOST_OFFLOADING_SUPPORT parameter to an 327 R1 packet in order to indicate the support of the puzzle offloading 328 mechanism described in this document. The parameter is located in 329 the signed part of the HIP control packet and is, therefore, bound to 330 the host identity of the Responder. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Padding | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Type 5600 341 Length 0 343 4.2. MIDDLEBOX_OFFLOADING_SUPPORT 345 A middlebox MAY append the MIDDLEBOX_OFFLOADING_SUPPORT parameter to 346 an R1 packet in order to indicate the support of the puzzle 347 offloading mechanism described in this document. The parameter is 348 located in the unsigned part of the HIP control packet. Middleboxes 349 SHOULD check for the existence of an MIDDLEBOX_OFFLOADING_SUPPORT in 350 the R1 packet before adding the parameter in order to prevent 351 multiple parameters of this type to be included in the R1 packet. 352 Note, however, that this check SHOULD be done for reasons of space- 353 efficiency and does not have an impact on the offloading mechanism 354 itself. Middleboxes that support the puzzle offloading extension 355 SHOULD NOT keep per-association state about their notifications. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Padding | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Type 64600 366 Length 0 368 4.3. OFFLOADED_SOLUTION 370 When receiving a HOST_OFFLOADING_SUPPORT and a 371 MIDDLEBOX_OFFLOADING_SUPPORT parameter in the R1 packet, the 372 Initiator MAY add the OFFLOADED_SOLUTION instead of the SOLUTION 373 parameter in the I2 packet. In this case, the Initiator SHOULD skip 374 the computation of the puzzle solution. 376 The structure and semantics of the OFFLOADED_SOLUTION parameter equal 377 the SOLUTION parameter in [RFC5201]. However, the Initiator sets the 378 #J to 0. This indicates that an on-path middlebox MUST compute the 379 puzzle solution. 381 When receiving an I2 packet containing the OFFLOADED_SOLUTION 382 parameter, an on-path middlebox that supports the puzzle offloading 383 extension first inspects the #J. If #J is 0, the middlebox uses the 384 echoed PUZZLE values in the OFFLOADED_SOLUTION parameter as well as 385 the RHASH function to compute the puzzle solution. It then adds the 386 computed solution to the #J of the OFFLOADED_SOLUTION parameter. 387 Hence, the first middlebox supporting the puzzle offloading mechanism 388 computes the puzzle solution on behalf of the Initiator. Note that 389 the OFFLOADED_SOLUTION parameter is located in the unsigned part of 390 the HIP packet. Hence, the modification of the parameter by the 391 middlebox does not invalidate existing integrity protection 392 mechanisms. 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Type | Length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | #K, 1 byte | Reserved | Opaque, 2 bytes | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Random #I, n bytes | 402 / / 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Puzzle solution #J, RHASH_len/8 bytes | 405 / / 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Type 64602 409 Length 4 + RHASH_len /4 410 #K #K is the number of verified bits 411 Reserved zero when sent, ignored when received 412 Opaque copied unmodified from the received PUZZLE 413 Random #I random number of size RHASH_len bits 414 Puzzle solution #J random number of size RHASH_len bits 416 4.4. VIA_UNTRUSTED_NETWORK 418 A middlebox MAY append the VIA_UNTRUSTED_NETWORK parameter to an R1 419 packet in order to indicate that the handshake is routed via an 420 untrusted network. As a result, the Responder SHOULD set the puzzle 421 difficulty in the PUZZLE parameter to target the uncertain 422 capabilities of the peer host. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Padding | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Type 64604 433 Length 0 435 5. Security Considerations 437 This document describes a modification of the HIP puzzle mechanism 438 used in the initial HIP handshake. The puzzle offloading extension 439 replaces the signed SOLUTION parameter by the unsigned 440 OFFLOADED_SOLUTION parameter. This allows an on-path attacker to 441 increase the puzzle difficulty K. As a result, the middlebox has to 442 commit additional resources for computing the puzzle solution for a 443 higher difficulty than originally required by the Responder. 445 The MIDDLEBOX_OFFLOADING_SUPPORT parameter is not cryptographically 446 bound to a specific middlebox that claims to support the extension 447 and to take over the workload of computing the puzzle solution. 448 Hence, an on-path attacker could use the new parameter to trick the 449 Initiator into using the offloading extension described in this 450 document, although it is not supported on the communication path or 451 despite the fact that he is unwilling to compute the puzzle solution. 452 As a result, the Responder would receive a blank, invalid puzzle 453 solution and drop the I2 packet. However, the attacker could achieve 454 the same result by simply dropping any of the handshake packets. 456 The VIA_UNTRUSTED_NETWORK parameter is not cryptographically bound to 457 the middlebox that claims a specific handshake to originate from an 458 untrusted network. Hence, an on-path attacker could trick the 459 Responder into increasing the puzzle difficulty, although the peer 460 host is within the local (resource-constrained) network environment. 461 As a result, the Initiator would drop the resulting puzzle due to its 462 excessive difficulty. However, the attacker could simply drop the I1 463 or the R1 packet in order to achieve the same result. 465 6. IANA Considerations 467 This document specifies four new HIP parameter types. The 468 preliminary parameter type numbers are 5600, 64600, 64602, and 64604. 470 7. Changelog 472 7.1. Version 1 474 - Rename INTERNET_HOST to VIA_UNTRUSTED_NETWORK parameter in Figure 2 476 - Add reference to RFC 3234 478 - Editorial changes 480 7.2. Version 0 482 - Initial Version 484 8. Normative References 486 [I-D.ietf-6lowpan-nd] 487 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 488 Discovery Optimization for Low Power and Lossy Networks 489 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 490 August 2012. 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 496 Issues", RFC 3234, February 2002. 498 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 499 "Host Identity Protocol", RFC 5201, April 2008. 501 Authors' Addresses 503 Rene Hummen (editor) 504 RWTH Aachen University, Communication and Distributed Systems Group 505 Ahornstrasse 55 506 Aachen 52074 507 Germany 509 Email: hummen@cs.rwth-aachen.de 510 URI: http://www.comsys.rwth-aachen.de/team/rene-hummen/ 511 Martin Henze 512 RWTH Aachen University, Communication and Distributed Systems Group 513 Ahornstrasse 55 514 Aachen 52074 515 Germany 517 Email: henze@comsys.rwth-aachen.de 518 URI: http://www.comsys.rwth-aachen.de/team/martin-henze/ 520 Jens Hiller 521 RWTH Aachen University, Communication and Distributed Systems Group 522 Ahornstrasse 55 523 Aachen 52074 524 Germany 526 Email: hiller@comsys.rwth-aachen.de