idnits 2.17.1 draft-herbert-ila-messages-00.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 577: '...refore, the HMAC MUST be based on a ha...' RFC 2119 keyword, line 584: '...pport multiple hash functions but MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FIPS180-4' is mentioned on line 585, but not defined == Unused Reference: 'I-D.lapukhov-ila-deployment' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-02 == Outdated reference: A later version (-01) exists of draft-lapukhov-ila-deployment-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Facebook 4 Expires: September 22, 2016 6 March 21, 2016 8 ILA Control Messages 9 draft-herbert-ila-messages-00 11 Abstract 13 This specification defines control messages for Identifier Locator 14 Addressing. These control messages are sent between ILA hosts or from 15 ILA routers to ILA hosts to notify a sending host to change its entry 16 for an identifier in its ILA mapping table. Messages indicate that no 17 mapping was found for a destination identifier or indicate a redirect 18 to use a different locator for an identifier. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright and License Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 ILA control message format . . . . . . . . . . . . . . . . . . . 4 60 2.1 Host No Identifier . . . . . . . . . . . . . . . . . . . . . 5 61 2.2 Router No Mapping . . . . . . . . . . . . . . . . . . . . . 6 62 2.3 Host redirect . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4 Router redirect . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1 Host control message generation . . . . . . . . . . . . . . 8 66 3.2 ILA router processing . . . . . . . . . . . . . . . . . . . 10 67 3.3 Host processing of received ILA messages . . . . . . . . . . 11 68 3.4 Other properties . . . . . . . . . . . . . . . . . . . . . . 12 69 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 70 4.1 HMAC authentication and integrity . . . . . . . . . . . . . 12 71 4.1.1 Security fields in ILA control messages . . . . . . . . 13 72 4.1.2 Selecting a hash algorithm . . . . . . . . . . . . . . 13 73 4.1.3 Pre-shared key management . . . . . . . . . . . . . . . 14 74 4.2 DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 76 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 78 6.2 Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1 Introduction 83 Identifier locator addressing is described in [I-D.herbert-nvo3-ila] 84 and an architecture for ILA deployment is described in [I-D.lapukhov- 85 ila-deployment]. In this specification we describe ILA control 86 messages. These are messages concerning the state of ILA mappings and 87 are sent between ILA hosts or between ILA routers and ILA hosts. 88 These messages are sent in response to data plane packets in order to 89 notify a sender about status of the ILA mapping for the identifier in 90 a destination address. There are four different types of 91 notifications: 93 o "Host No Identifier" is sent by an ILA host if it receives a 94 packet addressed with its local locator but cannot match the 95 identifier. 97 o "Router No Mapping" is sent by an ILA router when it receives a 98 SIR addressed packet however does not have a mapping for the 99 identifier. In this case the destination identifier is 100 unreachable 102 o "Host redirect" is sent by an ILA host when it receives a packet 103 addressed with its local locator and the identifier has a 104 forwarding mapping entry. This is used to redirect senders to a 105 new location after an identifier has been moved to a different 106 host. 108 o "Router redirect" is sent by an ILA router when it receives a 109 SIR addressed packet and the locator for the identifier is in 110 the mapping table. Upon receiving this message a host is able to 111 send packets directly using the locator instead of the SIR 112 address. 114 2 ILA control message format 116 ILA messages are sent in the payload of UDPv6 packets. The general 117 format is: 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 |Version| Traffic Class | Flow Label | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Payload Length | NxtHdr=17(UDP)| Hop Limit | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | 127 + + 128 | | 129 + Source Address + 130 | | 131 + + 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | | 135 + + 136 | | 137 + Destination Address + 138 | | 139 + + 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Source port | Destination port | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Length | Checksum | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |H| Reserved | Code | Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 ~ Data ~ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 | | 154 ~ HMAC (256 bits) (optional) ~ 155 | | 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 o Source address is the common locator address (CLA) of the device 160 sending the message. (the common locator address has the form: 161 ::1). 163 o Destination address is the common locator address derived from 164 the source address of the received packet. The source address of 165 the received packet is a SIR address, so to send an ILA control 166 message the SIR address must be reverse mapped to a locator 167 which is set in the CLA. 169 o Source port: set to ILA control message port number (assignment 170 TDB). 172 o Destination UDP port: set to ILA control message port number 173 (assignment TBD). 175 o H: Indicates the HMAC field is present. 177 o Code indicates the type of the ILA message. Defined codes are: 179 o 0x1: Host No Identifier 181 o 0x2: Router No Mapping 183 o 0x3: Host Redirect 185 o 0x4: Router Redirect 187 o Data: The data portion of the control messages. 189 o HMAC: HMAC Key ID and HMAC field, and their use are defined in 190 Section 4. 192 2.1 Host No Identifier 194 The Host No Identifier message is sent by an ILA host if it 195 receives a packet addressed with its local locator but cannot 196 match the identifier. The format of this message is: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |H| Reserved | 0x1 | Reserved | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | SIR prefix | 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Identifier | 207 | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Original locator | 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 o SIR prefix: the SIR prefix associated with the locator of the 214 sending host (i.e. the locator in the original packet) 216 o Identifier: The identifier received in the packet. The host 217 sending the ILA message has no mapping for this identifier. 219 o Original locator: The locator that was in the destination 220 address of the received packet. If there is a only one locator 221 assigned per host this will be the same as the locator used in 222 the source address of the ILA message (see above). 224 2.2 Router No Mapping 226 Router No Mapping is sent by an ILA router when it receives a 227 SIR addressed packet however does not have a mapping for the 228 identifier. The format of this message is: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 |H| Reserved | 0x2 | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | SIR prefix | 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Identifier | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 o SIR prefix: the SIR prefix associated with the locator of the 243 sending host (i.e. the locator in the original packet) 245 o Identifier: The identifier received in the packet. The ILA 246 router sending the ILA message has no mapping for this 247 identifier. 249 2.3 Host redirect 251 A Host Redirect is sent by an ILA host when receives a packet 252 addressed with its local locator and the identifier has a forwarding 253 mapping entry. The format of this message is: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |H| Reserved | 0x3 | Reserved | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | SIR prefix | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Identifier | 264 | | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Old locator | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | New Locator | 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 o SIR prefix: the SIR prefix associated with the locator of the 274 sending host (i.e. the locator in the original packet) 276 o Identifier: The identifier received in the packet. The host 277 sending the ILA message is suggesting a new locator for this 278 identifier. 280 o Old locator: The locator that was set in destination of the 281 received packet. 283 o New Locator: The locator that the a sending host is being 284 redirected to use. 286 2.4 Router redirect 288 A Router Redirect is sent by an ILA router when it receives a SIR 289 addressed packet and the locator for the identifier in the 290 destination address is in the mapping table. The format of this 291 message is: 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |H| Reserved | 0x4 | Reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | SIR prefix | 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Identifier | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Locator | 305 | | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 o SIR prefix: the SIR prefix associated with the locator of the 309 sending host (i.e. the locator in the original packet) 311 o Identifier: The identifier received in the packet. The router 312 sending the ILA message is suggesting a new locator for this 313 identifier. 315 o Locator: The locator that the a sending host is being redirected 316 to use. 318 3. Operation 320 ILA messages can only be sent in response to packets whose source 321 address is a SIR address in the same domain as the host or router 322 sending the control messages. ILA messages must not be sent to non- 323 ILA hosts or ILA hosts in a different domain (i.e. use a different 324 SIR prefix). 326 ILA messages must be verified for authenticity (see Section 4). 328 3.1 Host control message generation 330 An ILA host may send control messages in response to packets received 331 that have its local locator in the destination address. 333 The steps in receive processing of an ILA host are: 335 1) Receive packets where the destination locator matches the local 336 locator of the host. 338 2) Lookup the identifier in the destination address in the ILA 339 locator mapping database. 341 3) If the identifier is found and it is marked as a local 342 identifier (i.e. this is the location for the identifier), then 343 overwrite the locator in the destination address with the SIR 344 prefix and receive the packet in the local stack as per ILA 345 processing. 347 4) Else, if the source address is not a SIR address in the same 348 ILA domain as the host, then drop the packet and take no 349 further action. 351 5) Lookup the identifier in the source address in the ILA mapping 352 table. If no entry is found or there is no locator associated 353 with the entry, then drop the packet and take no further 354 action. 356 6) If the identifier in the destination address was found in the 357 mapping database and there is a forwarding address set in the 358 mapping entry, then send a Host Redirect message: 360 a) The destination address of the control message is set to the 361 common locator address which is comprised of the locator 362 associated with the identifier in the source address and ::1 363 in the low order 64 bits. 364 b) The source address of the control message packet is set to 365 the common locator address of the host sending the message. 366 c) The SIR prefix in the control message is set to that 367 associated with the locator the packet was received on. 368 d) The identifier in the control message is set to the 369 identifier in the destination address of the received packet. 370 e) The Old Locator in the control message is set to the locator 371 in the destination address of the received packet (should be 372 a local locator). 373 f) The New locator in the control message data is set to the 374 corresponding value in the mapping table. 376 7) Else, send a Host No Identifier. The host has no information 377 regarding the received identifier: 379 a) The destination address of the control message is set to the 380 common locator address which is comprised of the locator 381 associated with the identifier in the source address and ::1 382 in the low order 64 bits. 383 b) The source address of the control message packet is set to 384 the common locator address of the host sending the message. 385 c) The SIR prefix in the control message is set to that 386 associated with the locator the packet was received on. 387 d) The identifier in the control message is set to the 388 identifier in the destination address of the received packet. 390 e) The Original Locator in the control message is set to the 391 locator in the destination address of the received packet 392 (should be a local locator). 394 3.2 ILA router processing 396 An ILA router should send control messages in response to packets 397 received whose destination address is a SIR address. 399 The steps in receive processing of an ILA router are: 401 1) Receive anycast SIR addressed packets that are routed to the 402 router. 404 2) Lookup the identifier in the destionation address in the ILA 405 locator database. 407 3) If an entry for the identifier is found and there is an 408 associated locator, then overwrite the SIR prefix in the 409 destination address with the found locator and forward the 410 packet per ILA processing. 412 4) Else, if the source address is not a SIR address in the same 413 ILA domain as the host, then drop the packet and take no 414 further action. 416 5) Lookup the identifier in the source address in the ILA mapping 417 table. If no entry is found or there is no locator associated 418 with the entry, then take no further action. 420 6) If the locator was found in the mapping table then send a 421 Router Redirect message: 423 a) The destination address of the control message is set to the 424 common locator address which is comprised of the locator 425 associated with the identifier in the source address and ::1 426 in the low order 64 bits. 427 b) The source address of the control message packet is set to 428 the common locator address of the ILA router sending the 429 message. 430 c) The SIR prefix in the control message is set to that 431 associated with the locator the packet was received on. 432 d) The identifier in the control message is set to the 433 identifier in the destination address of the received packet. 434 f) The Locator in the control message data is set to the 435 corresponding value in the mapping table. 437 7) Else, send a Router No Mapping messages 438 a) The destination address of the control message is set to the 439 common locator address which is comprised of the locator 440 associated with the identifier in the source address and ::1 441 in the low order 64 bits. 442 b) The source address of the control message packet is set to 443 the common locator address of the ILA router sending the 444 message. 445 c) The SIR prefix in the control message is set to that 446 associated with the locator the packet was received on. 447 d) The identifier in the control message is set to the 448 identifier in the destination address of the received packet. 450 3.3 Host processing of received ILA messages 452 Hosts listen on the appropriate UDP port for ILA control messages. 453 The steps in processing control messages are: 455 1) Control messages are received on the common locator address for 456 the host. 458 2) If the message code is Host No Mapping 460 a) Lookup the specified identifier in the ILA mapping cache. If 461 an entry is found, there is a locator in the mapping, and the 462 locator matches that in the Original Locator in the control 463 message-- then invalidate the locator. The next packet that 464 is sent to that identifier will not be translated and so will 465 be sent with a destination SIR address. 466 b) If the mapping entry has no locator set or a different 467 locator than what is reported in the Host No mapping, then 468 disregard the message 470 3) If the message code is Router No Mapping 472 a) Lookup the specified identifier in the ILA mapping cache. If 473 a match is found, then mark the entry is unreachable (subject 474 to a timer) 475 b) If an entry is not found then disregard the message. 477 4) If the message code is Host redirect 479 a) Lookup the specified identifier in the ILA mapping cache. If 480 an entry is found, there is a locator in the mapping, and the 481 locator matches that in the Old Locator in the control 482 message-- then set the locator to the value of New Locator. 483 The next packet that is sent to that identifier will use the 484 new locator. 485 b) If the mapping entry has no locator set or a different 486 locator than what is reported in the Host Redirect then 487 disregard the message 489 5) If the message is Router Redirect 491 a) Lookup the specified identifier in the ILA mapping cache. If 492 an entry is found then set the locator to the value of 493 Locator in the control message. The next packet that is sent 494 to that identifier will use the new locator. 496 b) If no mapping entry is found for the identifier then 497 disregard the message or, optionally, create a new cache 498 entry for the redirected identifier (this permits a mechanism 499 for ILA routers to push mappings). 501 3.4 Other properties 503 Host No Mapping and Host Redirect are considered optional messages 504 for hosts to send. If they are sent, then rate limiting should be a 505 applied to avoid sending more than 100 control messages per second. 506 If control messages are not generated, then a sender that has an out 507 of date mapping should eventually timeout and stop sending packets to 508 an incorrect locator. A host should not forward ILA addressed packets 509 even in the case that it has the forwarding address for an 510 identifier. 512 Router No Mapping and Router Redirect must be sent in order to keep 513 hosts synchronized with mapping state. The number of messages sent to 514 particular host should be rate limited so that no more than 100 515 messages per second are sent. An ILA router may proactively send 516 Router No Mapping and Router Redirect messages upon a mapping state 517 change to those hosts that are known to possess a mapping (the list 518 of hosts that have sent packets through the router using a mapping 519 could be kept in the mapping database). Conceivably, an ILA router 520 could also multicast messages to inform hosts of a state (the details 521 for this are outside the scope of this document). 523 4 Security Considerations 525 ILA control messages convey sensitive control information so they 526 need to be protected against spoofing. ILA control messages should be 527 authenticated and may be encrypted. 529 4.1 HMAC authentication and integrity 531 ILA control messages may optionally use HMAC authentication. The use 532 of HMAC in a message is indicated by the H bit being set. 534 4.1.1 Security fields in ILA control messages 536 This section summarizes the use of specific fields in the ILA 537 messages. They are based on a key-hashed message authentication code 538 (HMAC). 540 The security-related fields in ILA messages are: 542 o HMAC Key-id, 8 bits wide; 544 o HMAC, 256 bits wide (optional, exists only if HMAC Key-id is not 545 0). 547 The HMAC field is the output of the HMAC computation (per RFC 2104 548 [RFC2104]) using a pre-shared key and hashing algorithm identified by 549 HMAC Key-id and of the text which consists of the concatenation of: 551 o the source IPv6 address; 553 o the ILA control message header and data 555 The purpose of the HMAC field is to verify the validity, the 556 integrity and the authorization of the ILA control messages itself. 557 If an outsider of the ILA domain does not have access to a current 558 pre-shared secret, then it cannot compute the right HMAC so when the 559 receiver of a control messages checks the validity of the HMAC it 560 will simply reject the packet. 562 The HMAC Key-id field allows for the simultaneous existence of 563 several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 564 well as pre-shared keys. This allows for pre-shared key roll-over 565 when two pre-shared keys are supported for a while when all ILA nodes 566 converged to a fresher pre-shared key. The HMAC Key-id field is 567 opaque, i.e., it has neither syntax not semantic except as an index 568 to the right combination of pre-shared key and hash algorithm and 569 except that a value of 0 means that there is no HMAC field. It could 570 also allow for interoperation among different ILA domains if allowed 571 by local policy and assuming a collision-free Key Id allocation which 572 is out of scope of this memo. 574 4.1.2 Selecting a hash algorithm 576 The HMAC field in the ILA control messages is 256 bits wide. 577 Therefore, the HMAC MUST be based on a hash function whose output is 578 at least 256 bits. If the output of the hash function is 256, then 579 this output is simply inserted in the HMAC field. If the output of 580 the hash function is larger than 256 bits, then the output value is 581 truncated to 256 by taking the least-significant 256 bits and 582 inserting them in the HMAC field. 584 ILA implementations can support multiple hash functions but MUST 585 implement SHA-2 [FIPS180-4] in its SHA-256 variant. 587 4.1.3 Pre-shared key management 589 The field HMAC Key-id allows for: 591 o key roll-over: when there is a need to change the key (the hash 592 pre-shared secret), then multiple pre-shared keys can be used 593 simultaneously. The validating routing can have a table of 594 for the 595 currently active and future keys. 597 o different algorithm: by extending the previous table to , the validating router 599 can also support simultaneously several hash algorithms (see 600 section Section 4.1.2) 602 The pre-shared secret distribution can be done: 604 o in the configuration of the validating nodes, either by static 605 configuration or any SDN oriented approach; 607 o dynamically using a trusted key distribution such as [RFC6407] 609 The intent of this document is NOT to define yet-another-key- 610 distribution-protocol. 612 4.2 DTLS 614 For stronger security, including encryption of ILA control 615 messages, DTLS may be used. The use of DTLS necessitates a 616 separate UDP port. 618 5 IANA Considerations 620 IANA will be requested to assign one UDP port number for ILA 621 control messages, and one for ILA control messages with DTLS. 623 6 References 625 6.1 Normative References 627 [I-D.herbert-nvo3-ila] Herbert, T., "Identifier-locator addressing 628 for network virtualization", draft-herbert-nvo3-ila-02 629 (work in progress), March 2016. 631 6.2 Informative References 633 [I-D.lapukhov-ila-deployment] Lapukhov, P., "Deploying Identifier- 634 Locator Addressing (ILA) in datacenter", draft-lapukhov- 635 ila-deployment-00 (work in progress), March 2016. 637 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 638 Hashing for Message Authentication", RFC 2104, DOI 639 10.17487/RFC2104, February 1997, . 642 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of 643 Interpretation", RFC 6407, DOI 10.17487/RFC6407, October 644 2011, . 646 Authors' Addresses 648 Tom Herbert 649 Facebook 650 1 Hacker Way 651 Menlo Park, CA 652 US 654 EMail: tom@herbertland.com