idnits 2.17.1 draft-shore-nls-tl-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1780. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1793. 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2008) is 5764 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3547 (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Shore 3 Internet-Draft D. McGrew 4 Intended status: Standards Track K. Biswas 5 Expires: January 14, 2009 Cisco Systems 6 July 13, 2008 8 Network-Layer Signaling: Transport Layer 9 draft-shore-nls-tl-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The RSVP model for communicating requests to network devices along a 43 datapath has proven useful for a variety of applications beyond what 44 the protocol designers envisioned, and while the architectural model 45 generalizes well the protocol itself has a number of features that 46 limit its applicability to applications other than IntServ. Network 47 Layer Signaling uses the RSVP on-path communication model and 48 provides a lightweight transport layer for non-QoS signaling 49 applications, such as discovery or diagnostics. It is based on a 50 "two-layer" architecture that divides protocol function into 51 transport and application. This document describes the transport 52 protocol. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5 58 2. NLS-TL Messages . . . . . . . . . . . . . . . . . . . . . . . 7 59 2.1. Message Processing Overview . . . . . . . . . . . . . . . 7 60 2.1.1. Congestion Considerations . . . . . . . . . . . . . . 8 61 2.2. NAT Traversal Support . . . . . . . . . . . . . . . . . . 8 62 2.3. NLS-TL Message Format . . . . . . . . . . . . . . . . . . 9 63 2.3.1. The NLS-TL Message Header . . . . . . . . . . . . . . 9 64 2.3.2. NLS-TL TLVs . . . . . . . . . . . . . . . . . . . . . 10 65 2.4. Cryptographic Datatypes . . . . . . . . . . . . . . . . . 18 66 3. Sending NLS-TL Messages . . . . . . . . . . . . . . . . . . . 20 67 4. Messaging and state maintenance . . . . . . . . . . . . . . . 21 68 4.1. BUILD-ROUTE . . . . . . . . . . . . . . . . . . . . . . . 21 69 4.1.1. Route state deletion . . . . . . . . . . . . . . . . . 21 70 4.2. HOP-BY-HOP . . . . . . . . . . . . . . . . . . . . . . . . 21 71 4.3. BIDIRECTIONAL . . . . . . . . . . . . . . . . . . . . . . 22 72 4.4. Path Teardown Messages . . . . . . . . . . . . . . . . . . 22 73 4.5. Network Address Translation . . . . . . . . . . . . . . . 23 74 4.6. Authentication Exchange . . . . . . . . . . . . . . . . . 23 75 4.6.1. Authentication Exchange Messages . . . . . . . . . . . 24 76 4.6.2. Authentication TLV calculation . . . . . . . . . . . . 27 77 4.6.3. Security state transition table . . . . . . . . . . . 28 78 5. Application Interface . . . . . . . . . . . . . . . . . . . . 30 79 6. NAT Interactions . . . . . . . . . . . . . . . . . . . . . . . 31 80 7. Using NLS-TL as a stand-alone NAT traversal protocol . . . . . 32 81 8. Discovery of non-NLS NATs, and recovery . . . . . . . . . . . 33 82 9. Endpoint Processing . . . . . . . . . . . . . . . . . . . . . 35 83 9.1. Sending . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 9.2. Receiving . . . . . . . . . . . . . . . . . . . . . . . . 36 85 10. Intermediate node processing . . . . . . . . . . . . . . . . . 37 86 11. Using NLS-TL to support bidirectional reservations . . . . . . 38 87 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 88 12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 39 89 12.2. Security Model . . . . . . . . . . . . . . . . . . . . . . 39 90 12.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . . 40 91 12.3.1. Keys . . . . . . . . . . . . . . . . . . . . . . . . . 40 92 12.3.2. Reflection Attacks . . . . . . . . . . . . . . . . . . 41 93 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 94 13.1. NLS Application Identifiers . . . . . . . . . . . . . . . 42 95 13.2. NLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 43 96 13.3. Error codes and values . . . . . . . . . . . . . . . . . . 44 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 98 14.1. Normative References . . . . . . . . . . . . . . . . . . . 45 99 14.2. Informative References . . . . . . . . . . . . . . . . . . 45 100 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 102 Intellectual Property and Copyright Statements . . . . . . . . . . 48 104 1. Introduction 106 RSVP is based on a "path-coupled" signaling model, in which signaling 107 messages between two endpoints follow a path that is tied to the data 108 path between the same endpoints, and in which the signaling messages 109 are intercepted and interpreted by RSVP-capable routers along the 110 path. While RSVP was originally designed to support QoS signaling 111 for Integrated Services [RFC1633], this model has proven to 112 generalize to other problems extremely well. Some of these problems 113 include topology discover, communicating with firewalls and NATs, 114 discovery of IPSec tunnel endpoints, test applications, diagnostic 115 triggers, and so on. 117 This document describes the core protocol for a generalized on-path 118 request protocol that is being used today to carry topology discovery 119 and other requests -- one that is not tied directly to IntServ or 120 other QoS mechanisms and in which the protocol machinery itself is 121 sufficiently generalized to be able to support a variety of 122 applications (this protocol is referred to as "Network Layer 123 Signaling", or "NLS"). What this means in practice is that there 124 will be different signaling applications, all of which share a base 125 NLS transport layer. This architecture is based on work done by Bob 126 Braden and Bob Lindell, and described in [braden]. It is also 127 similar to the concepts used in secsh, where authentication and 128 connection protocols run on top of a secsh transport protocol (see 129 [RFC4251] for details). 131 The protocol machinery was originally based somewhat on RSVP 132 [RFC2205] without refresh overhead reduction extensions [RFC2961], 133 but in the process of generalization has lost many of the features 134 that define RSVP, such as necessary receiver-oriented reservations 135 and processing requirements at each node. 137 NLS differs from RSVP in several important ways. One of the most 138 significant of these is that the transport protocol described in this 139 document (NLS-TL) does not itself trigger reservations in network 140 nodes. Reservations will be installed and managed by NLS 141 applications, however some NLS applcations may not carry reservation 142 requests at all (discovery protocols, for example). Because of this 143 NLS-TL does not support reservation styles (those would be also be 144 attributes of an application). Another significant difference is 145 that that reservations may be installed by a NLS application in 146 either a forward (from the sender toward the receiver) or backward 147 (from the receiver toward the sender) direction -- this is 148 application-specific. 150 Other possibly significant differences include that NAT traversal 151 support is integrated into the message transport, and that NLS allows 152 an application to install reservations for paths that are 153 bidirectional and asymmetric.Multicast is not supported in this 154 version of the protocol. 156 NLS shares some basic design features with NSIS [RFC4080], which is 157 another path-coupled protocol. However, unlike NLS, the NSIS 158 transport provides reliable delivery of request messages (in NLS this 159 is left to the application rather than the transport layer), and NLS 160 was not designed with QoS signaling support in mind. We leave the 161 question of reliable delivery up to the NLS application. Not every 162 signaling application requires reliable delivery and by moving 163 reliable delivery into the application layer we are able to keep 164 complexity in the transport layer to a minimum, providing only the 165 services which tend to need to be available in all on-path signaling 166 applications. It is also the case that by providing a light-weight, 167 datagram-based protocol we are able to rely on IP layer routing and 168 forwarding for delivery and do not require a separate routing 169 process. 171 The NLS Transport Layer is being used by PacketCable and the ITU-T to 172 carry topology discovery requests, in a protocol called "Control 173 Point Discovery" (CPD). 175 1.1. Transport layer 177 This document describes the transport layer. The NLS transport layer 178 is as simple as we could make it, supporting two basic functions: 179 routing and NAT traversal. The sources of complexity in signaling 180 protocols tend to be the signaling applications themselves. Those 181 applications have varying performance and reliability requirements, 182 and consequently we feel that application-specific functions belong 183 in the application layer. 185 The NLS transport layer is also relatively stateless. By "stateless" 186 we mean that the transport layer does not itself create or manipulate 187 state in participating nodes. By "relatively" we take exception to 188 the previous assertion, in that the transport layer provides 189 facilities for route identification and route pinning. This is an 190 optimization, albeit a significant one, which allows NLS to be used 191 without a separate route discovery process. Another source of state 192 is in the case of NATs, where an NLS-TL request may trigger the 193 creation of a NAT table mapping. However, this latter case does not 194 create NLS-TL maintenance state. 196 An application may wish to support summary refreshes or other 197 performance enhancements; that type of function is application- 198 specific and requires no support from the transport layer. 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in [RFC2119]. 204 2. NLS-TL Messages 206 2.1. Message Processing Overview 208 Unlike RSVP, NLS-TL has only one fundamental message type, and 209 directionality is significant to the NLS application only. Three new 210 attributes, HOP-BY-HOP, BUILD-ROUTE, and BIDIRECTIONAL, have been 211 added in support of greater flexibility in the NLS application. For 212 example, some applications which already know network topology or 213 which run a separate routing protocol may choose to route hop-by-hop 214 in a forward direction. Conversely, a topology discovery protocol 215 may choose to route end-to-end in the return direction. Both of 216 these would be departures from the Path/Resv message handling 217 specified in RSVP. 219 The BUILD-ROUTE flag has been added to allow route discovery to be 220 overloaded on top of basic messaging, much like the RSVP Path 221 message. If the BUILD-ROUTE flag is present, NLS nodes store routing 222 information carried in incoming HOP objects. They also overwrite 223 routing information into the HOP TLV in outgoing NLS messages. 225 The HOP-BY-HOP flag is used to instruct an NLS-TL node to address an 226 outgoing message to the address stored in routing state associated 227 with the message flow. Typically this will be state accumulated 228 through the use of the BUILD-ROUTE flag but it may be manually 229 configured, installed through an external routing or discovery 230 process, etc. 232 The BIDIRECTIONAL flag may be used to indicate that the application 233 for which this NLS-TL message carries a payload must be executed in 234 each direction. It may be used in combination with the HOP-BY-HOP 235 flag in some circumstances, but typically it will be used with the 236 HOP-BY-HOP flag set to 0. 238 Even with these departures, the basic operation of the protocol may 239 made be similar to RSVP with the appropriate use of the new 240 attributes. For example, a message may be injected into a network by 241 the sender towards a receiver, routed end-to-end with the receiver's 242 address in the destination address in the IP header. If the BUILD- 243 ROUTE bit is set in the NLS header, entities along the path the 244 message traverses will intercept it, store path state, act on (or 245 not) the application payload data, and forward the message towards 246 its destination. In NLS-TL, "path state" refers specifically to the 247 unicast IP address of the previous hop node along with locally- 248 relevant path information (for example, interface identifier). 250 When the message arrives at the receiver (or its proxy), the receiver 251 may generate another NLS message in response, this time back towards 252 the original sender. As with the message in the forward direction, 253 this message may be routed either end-to-end or hop- by-hop, 254 depending on the requirements of the application. In order to 255 emulate an RSVP Resv message, the HOP-BY-HOP is set to 1 and the 256 BUILD-ROUTE bit is set to 0. 258 BUILD-ROUTE and HOP-BY-HOP must not be set in the same NLS-TL 259 message, and BUILD-ROUTE and TEARDOWN MUST NOT be set in the same 260 NLS-TL message. 262 2.1.1. Congestion Considerations 264 Transmission, loss response, and resend timings are out-of-scope for 265 this document. Different NLS applications will have different 266 transmission timing and resend characteristics and will need to be 267 specified in a manner appropriate to each application. For example, 268 a discovery application will need to behave differently from an 269 application which requests and maintains state in middleboxes. 271 However, each NLS application MUST specify how it will handle message 272 loss and MUST specify a backoff mechanism in the case where messages 273 are retransmitted as a response to message loss. 275 Loss response for stand-alone NAT traversal is described in 276 Section 7. 278 2.2. NAT Traversal Support 280 NAT traversal poses a particular challenge to a layered protocol like 281 NLS. If we assume the use of discrete, opaque applications, one of 282 which is NAT, interactions between other applications that make use 283 of addresses (for example, firewall rules or QoS filter specs) and 284 the NAT application are complicated. Either every application will 285 need to be able to peek into NAT payloads and identify which address 286 mapping is the one they need, or NATs supporting NLS will need to be 287 able to parse and write into every application payload type. Neither 288 approach is particularly robust, reintroducing a type of stateful 289 inspection and constraining how applications can be secured. 291 Because of the desire to be able to have a variety of NLS 292 applications successfully interact with NATs and because of the 293 constraints described above, in NLS NAT is supported in the transport 294 layer rather than in a separate application. Each address that needs 295 translation is tagged, put into a NAT_ADDRESS TLV, and passed to the 296 appropriate application at each NLS node. Application identification 297 is based on tag contents. Note that NLS supports Network Address 298 Translation for IPv4 only. 300 2.3. NLS-TL Message Format 302 NLS messages consist of an NLS-TL header followed by optional TLV 303 fields followed by an optional application payload. 305 2.3.1. The NLS-TL Message Header 307 All NLS-TL messages (and by implication, all NLS messages) start with 308 an NLS header. The header is formatted as follows: 310 0 1 2 3 311 +-------------+-------------+-------------+-------------+ 312 | Version | (Reserved) | Message Length | 313 +-------------+-------------+-------------+-------------+ 314 | Flags | Checksum | 315 +-------------+-------------+-------------+-------------+ 316 | Flow ID | 317 +-------------+-------------+-------------+-------------+ 319 Figure 1 321 where the fields are as follows: 323 Version: 8 bits. The protocol version number; in this case 0x01. 325 Reserved: 8 bits. MUST be set to 0x0 when sending and ignored on 326 receipt. 328 Message Length: 16 bits. The total number of octets in the 329 message, including the NLS-TL header and complete payload. 331 Flags: 16 bits. Flag bits include 333 0x01 HOP-BY-HOP 334 0x02 BUILD-ROUTE 335 0X04 TEARDOWN 336 0x08 AX_CHALLENGE 337 0x10 AX_RESPONSE 338 0x20 BIDIRECTIONAL 340 Checksum: 16 bits. The one's complement of the one's complement 341 sum of the entire message. The checksum field is set to zero for 342 the purpose of computing the checksum. This may optionally be set 343 to all zeros. If a message is received in which this field is all 344 zeros, no checksum was sent. 346 Flow ID: 32 bits. This is a value which, combined with the source 347 IP address of the message, provides unique identification of a 348 flow of NLS-TL messages, which may be used for later reference for 349 actions such as quick teardowns, status queries, etc. The 350 mechanism used for generating the value is implementation- 351 specific. 353 Throughout, we assume the use of 8-bit bytes, or octets. 355 2.3.2. NLS-TL TLVs 357 NLS-TL carries additional transport-layer information and requests as 358 type-length-value fields, which are inserted after the header and 359 before the application payload. The TLV format is as follows: 361 0 1 2 3 362 +-------------+-------------+-------------+-------------+ 363 |M|R| Type | Length | 364 +-------------+-------------+-------------+-------------+ 365 | | 366 // Value // 367 | | 368 +-------------+-------------+-------------+-------------+ 370 Figure 2 372 where the fields are as follows: 374 Mandatory: 1 bit. If this bit is set, this TLV MUST NOT be ignored 375 silently, even if the recipient does not understand the type code. 376 If the recipient does not understand the TLV, it MUST return an 377 IPv4_ERROR_CODE or an IPv6_ERROR_CODE, as appropriate, with the 378 error code set to 0x02 (Unrecognized TLV). If it is not set then 379 the recipient MAY ignore the TLV. 381 Reserved: 1 bit. This bit is reserved for future use. It MUST be 382 set to 0 before sending and ignored on receipt. 384 Type: 14 bits. The type of information or request. Defined below. 386 Length: 16 bits. Total TLV length in octets, including the type 387 type and length fields. It must always be at least 4 and be a 388 multiple of 4. 390 Value: Variable length. At least 4 octets and a multiple of 4 391 octets). The TLV semantic content. The format of the Value field 392 is determined by the value of the Type field 394 2.3.2.1. NAT_ADDRESS, TYPE=1 396 +-------------+-------------+-------------+-------------+ 397 | Application ID | Flags | Proto | 398 +-------------+-------------+-------------+-------------+ 399 | Address ID Tag | 400 +-------------+-------------+-------------+-------------+ 401 | Original IPv4 Address | 402 +-------------+-------------+-------------+-------------+ 403 | Mapped IPv4 Address | 404 +-------------+-------------+-------------+-------------+ 405 | Original Port | Mapped Port | 406 +-------------+-------------+-------------+-------------+ 408 where the fields are as follows: 410 Application ID: 16 bits. This is the same as the value that's used 411 for identifying application payloads. The Application ID field is 412 set by the sender. 414 Flags: 16 bits. Flag bits include 416 0x01 = NO_TRANSLATE 417 0x02 = NO_REWRITE 419 NO_TRANSLATE indicates that a NAT device handling the packet 420 should not create a NAT table entry for the original address. If 421 the NO_TRANSLATE bit is set, the NAT does nothing. 423 NO_REWRITE indicates that when the reply message is being returned 424 towards the sender, any NATs along the path MUST NOT overwrite the 425 Mapped Address. 427 Proto: IP protocol for this translation (TCP, UDP, SCTP, etc.). 429 Address ID: 32 bits. An value that's unique within the set of 430 Address IDs used with a particular Application ID; used to 431 uniquely identify a particular address (i.e. provide a tag). 433 Original IPv4 Address: The original address for which a translation 434 is being requested. 436 Mapped IPv4 Address: The address created by the NAT -- i.e. the 437 "external" address. 439 Original Port: The original port for which a translation is being 440 requested 442 Mapped Port: The port number created by the NAT for this mapping. 444 The mandatory bit in the TLV header MUST always be set to 1 for this 445 TLV. 447 2.3.2.2. APPLICATION PAYLOAD, TYPE=2 449 +-------------+-------------+-------------+-------------+ 450 | Application ID | Payload | 451 +-------------+-------------+-------------+-------------+ 452 | | 453 // Payload // 454 | | 455 +-------------+-------------+-------------+-------------+ 457 The application payload TLV carries the NLS application data. It 458 MUST follow any NAT TLVs. It consists of a 16-bit Application ID, 459 which uniquely identifies the NLS application for which the TLV is 460 intended, and the application payload itself. The application 461 payload is transparent to the NLS Transport Layer. 463 The APPLICATION_PAYLOAD TLV MUST be a multiple of 4 bytes in length. 465 2.3.2.3. TIMEOUT, TYPE=3 467 +-------------+-------------+-------------+-------------+ 468 | Timeout Value | 469 +-------------+-------------+-------------+-------------+ 471 The TIMEOUT TLV carries the number of milliseconds for which state 472 associated with a particular flow should be retained, with the 473 expectation that the state will be deleted when the timeout expires. 474 "State" in this case refers to routing state and to NAT state; NLS 475 application state will be managed by its application. 477 2.3.2.4. IPV4_HOP, TYPE=4 479 +-------------+-------------+-------------+-------------+ 480 | IPv4 Hop Address | 481 +-------------+-------------+-------------+-------------+ 483 The IPv4_HOP TLV carries the IPv4 address of the interface through 484 which the last NLS entity forwarded the message. 486 2.3.2.5. IPv6_HOP, TYPE=5 488 +-------------+-------------+-------------+-------------+ 489 | | 490 + + 491 | | 492 + IPv6 Next/Previous Hop Address + 493 | | 494 + + 495 | | 496 +-------------+-------------+-------------+-------------+ 498 The IPv6_HOP TLV carries the IPv6 address of the interface through 499 which the last NLS entity forwarded the message. 501 2.3.2.6. IPv4_ERROR_CODE, TYPE=6 503 +-------------+-------------+-------------+-------------+ 504 | IPv4 Error Node Address (4 octets) | 505 +-------------+-------------+-------------+-------------+ 506 | Flags | Error Code | Error Value | 507 +-------------+-------------+-------------+-------------+ 509 The IPv4_ERROR_CODE TLV carries the address of a node at which an 510 NLS-TL error occurred, along with an error code and error value. 511 When no Error Value is defined, the Error Value field MUST be set to 512 0 by its sender and ignored by its receiver. 514 If the high-order bit of the Error Code is not set, the TLV carries 515 an error message. If it is set, the TLV carries an informational 516 message. Therefore Error Codes with values between 0 and 127 contain 517 error messages and Error Codes with values between 128 and 255 518 contain informational messages. 520 IPv4 Error Node Address: 4 octets. The IPv4 address of the 521 interface on the node that generated the error message. 523 Flags: 8 bits. None currently defined. 525 Error Code: 8 bits. The type of error or informational message, 526 with values as follows: 528 Error Code = 0: No error 530 Error Code = 1: Bad parameters 532 Error Value = 1: HOP-BY-HOP and BUILD-ROUTE both present 534 Error Value = 2: BUILD-ROUTE present but no HOP TLV 536 Error Value = 3: HOP-BY-HOP present but no local stored 537 routing state 539 Error Value = 4: Message length not a multiple of 4 541 Error Code = 2: Unrecognized TLV 543 Error Value = TLV number 545 Error Code = 3: Unrecognized application 547 Error Value = Application ID 549 Error Code = 4: Non-NLS NAT detected in path 551 Error Code = 5: Security error 553 Error Value = 1: AGID not found 554 Error Value = 2: Insufficient authorization 556 Error Value = 3: Request/reply mismatch 558 Error Value = 4: Authentication Failure 560 Error Code = 128: No message 562 Error Code = 129: Sending node has detected a route change 564 2.3.2.7. IPv6_ERROR_CODE, TYPE=7 566 +-------------+-------------+-------------+-------------+ 567 | | 568 + + 569 | | 570 + IPv6 Error Node Address (16 octets) + 571 | | 572 + + 573 | | 574 +-------------+-------------+-------------+-------------+ 575 | Flags | Error Code | Error Value | 576 +-------------+-------------+-------------+-------------+ 578 The IPv6_ERROR_CODE TLV carries the address of a node at which an 579 NLS-TL error occurred, along with an error code and error value. 581 "IPv6 Error Node Address:" 16 octets. The IPv6 address of the 582 interface on the node that generated the error message. 584 Flags: 8 bits. None currently defined. 586 The Error Code and Error value fields are the same as those used in 587 the IPv4_ERROR_CODE. 589 2.3.2.8. AGID, TYPE=8 591 The AGID is the authentication group ID, used in the authentication 592 dialogue to identify the group key. 594 +-------------+-------------+-------------+-------------+ 595 // AGID // 596 +-------------+-------------+-------------+-------------+ 598 2.3.2.9. A_CHALLENGE, TYPE=9 600 The A_CHALLENGE TLV is used to carry a 16-octet random nonce to be 601 used as an authentication challenge. It MUST be generated using a 602 strong random or pseudorandom source. 604 For a description of why we need A_CHALLENGE and B_CHALLENGE (as 605 opposed to just a single CHALLENGE type), see Section 12.3.2. 607 +-------------+-------------+-------------+-------------+ 608 | | 609 + + 610 | | 611 + Nonce + 612 | | 613 + + 614 | | 615 +-------------+-------------+-------------+-------------+ 617 2.3.2.10. A_RESPONSE, TYPE=10 619 The A_RESPONSE TLV carries the response to the authentication 620 challenge. It is a variable length TLV with the length dependent on 621 the transform being used. 623 For a description of why we need A_RESPONSE and B_RESPONSE (as 624 opposed to just a single RESPONSE type), see Section 12.3.2. 626 +-------------+-------------+-------------+-------------+ 627 | | 628 // MAC // 629 | | 630 +-------------+-------------+-------------+-------------+ 632 2.3.2.11. B_CHALLENGE, TYPE=11 634 The B_CHALLENGE TLV is used to carry a 16-octet random nonce to be 635 used as an authentication challenge. It MUST be generated using a 636 strong random or pseudorandom source. 638 For a description of why we need A_CHALLENGE and B_CHALLENGE (as 639 opposed to just a single CHALLENGE type), see Section 12.3.2. 641 +-------------+-------------+-------------+-------------+ 642 | | 643 + + 644 | | 645 + Nonce + 646 | | 647 + + 648 | | 649 +-------------+-------------+-------------+-------------+ 651 2.3.2.12. B_RESPONSE, TYPE=12 653 The B_RESPONSE TLV carries the response to the authentication 654 challenge. It is a variable length TLV with the length dependent on 655 the transform being used. 657 For a description of why we need A_RESPONSE and B_RESPONSE (as 658 opposed to just a single RESPONSE type), see Section 12.3.2. 660 +-------------+-------------+-------------+-------------+ 661 | | 662 // MAC // 663 | | 664 +-------------+-------------+-------------+-------------+ 666 2.3.2.13. AUTHENTICATION, TYPE=13 668 The AUTHENTICATION TLV carries a cryptographic hash over the entire 669 packet, as well as a 32-bit sequence number. In order to use this 670 TLV, the peer must first have passed a challenge/response exchange to 671 negotiate the approprite agid to use. It is a variable length TLV 672 with the length of the MAC dependent on the transform being used (as 673 determined by the agid). Details of computing the MAC are described 674 in Section 4.6. 676 +-------------+-------------+-------------+-------------+ 677 | Sequence Number | 678 +-------------+-------------+-------------+-------------+ 679 | | 680 // MAC // 681 | | 682 +-------------+-------------+-------------+-------------+ 684 2.3.2.14. ECHO, TYPE=14 686 A device can include an ECHO element in the messages that it sends. 687 A device receiving a message containing such a element must send the 688 element back, verbatim, in the following response. 690 +-------------+-------------+-------------+-------------+ 691 | | 692 | | 693 // ECHO data // 694 | | 695 | | 696 +-------------+-------------+-------------+-------------+ 698 An ECHO TLV SHOULD only appear during an Authentication Exchange, and 699 SHOULD NOT appear in any other message. 701 2.4. Cryptographic Datatypes 703 This section provides further detail on message formats for the 704 authentication exchange. 706 An NLS-TL message MSG has the following format: 708 MSG :== HDR OPT* APP* SEC* 710 where HDR, OPT, APP, and SEC are as follows: 712 HDR is the NLS header 714 OPT is an NLS optional TLV 716 APP is the optional Application Object 718 SEC is an AGID, A_CHALLENGE, A_RESPONSE, B_CHALLENGE, B_RESPONSE, 719 or AUTHENTICATION TLV's. These datatypes are defined below. 721 Note that though both OPT and APP are optional, one or the other MUST 722 exist (or both together). 724 The security TLVs are always last in order to avoid data-formatting 725 issues with the inputs to the message authentication codes, and to 726 minimize the amount of data movement needed during the Authentication 727 Exchange. 729 Authorization Group Identifier (AGID): The AGID TLV identifies a 730 particular group key. The Value field carries an identifier; 731 there is no defined format. The length of this field is variable, 732 and MUST be a multiple of four octets. If it is generated at 733 random, then it SHOULD be at least 16 octets. 735 A_CHALLENGE: The A_CHALLENGE contains a 16-octet random nonce. 736 This TLV is put into a message whenever outbound authentication is 737 desired. When this TLV is received, then the next message sent 738 MUST contain either an A_RESPONSE TLV or an error message 739 indicating that no authentication is possible. 741 B_CHALLENGE: The B_CHALLENGE contains a 16-octet random nonce. 742 This TLV is put into a message whenever inbound authentication is 743 desired. When this TLV is received, then the following message 744 MUST contain either a B_RESPONSE TLV or an error message 745 indicating that no authentication is possible. 747 A_RESPONSE: The A_RESPONSE TLV is sent in response to a message 748 containing an A_CHALLENGE TLV. It contains a message 749 authentication code (MAC) value computed over the complete NLS 750 message containing the A_CHALLENGE, including the NLS header. 752 B_RESPONSE: The B_RESPONSE is sent in response to a message 753 containing a B_CHALLENGE TLV. It contains a message 754 authentication code (MAC) value computed over the complete NLS 755 message containing the B_CHALLENGE, including the NLS header. 757 3. Sending NLS-TL Messages 759 When an endhost or its proxy wishes to initiate a NLS session, it 760 creates an NLS-TL message. If the message is being sent end-to-end 761 the destination address in the IP header is the address of the device 762 interface that is expected to terminate the path along which 763 signaling is expected to be sent (n.b. multicast is not supported in 764 this version of the protocol). It may be a application peer host or 765 terminal, or it may be a proxy. If the message is being sent hop-by- 766 hop the destination address in the IP header is the address of the 767 device interface that is the next hop along the path. That address 768 will have been discovered either through a separate routing process 769 or through RSVP-style soft-state messaging. 771 NLS-TL messages are UDP-encapsulated and sent on UDP port 7549. They 772 MAY be sent with the router alert bit set in IPv4 headers or with the 773 IPv6 router alert option [RFC2711], but it is not required. If the 774 message is end-to-end and needs route discovery and pinning, the 775 BUILD-ROUTE bit in the NLS-TL flags header MUST be set to 1 and the 776 HOP-BY-HOP bit MUST be set to 0. If the message is being routed hop- 777 by-hop, the HOP-BY-HOP bit MUST be set to 1 and the BUILT-ROUTE bit 778 MUST be set to 0. (Note that there may be applications in which both 779 the HOP-BY-HOP and the BUILD- ROUTE bit will be set to 0.) 781 If the NLS application wishes to support bidirectional reservations, 782 the BIDIRECTIONAL flag must be set to 1, the BUILD-ROUTE flag should 783 be set to 1, and the HOP-BY-HOP flag should be set to 0, at least in 784 the initial message. If the application makes use of periodic 785 refreshes it may optionally choose to route some number of them hop- 786 by-hop along the discovered path before sending out another message 787 to refresh the route state; that is an application design issue. 789 In this version of the protocol, each NLS message must fit in one 790 datagram. An NLS-TL message originator should perform PMTU discovery 791 in order to avoid exceeding path MTU size. 793 4. Messaging and state maintenance 795 Message handling and state maintenance are determined by the presence 796 (or absence) of two flags in the NLS-TL header: the HOP-BY-HOP bit 797 and the BUILD-ROUTE bit. They also involve, and are involved by, NAT 798 processing. 800 4.1. BUILD-ROUTE 802 The BUILD-ROUTE bit in the flags field of the NLS-TL header allows 803 NLS-TL to function as a discovery and routing protocol, much like the 804 Path message described in RFC 2205. 806 If the BUILD-ROUTE flag is present in a NLS-TL message, upon receipt 807 a NLS node MUST check for the presence of an IPv4_HOP or IPv6_HOP TLV 808 in the NLS-TL payload. If one is not present, the message MUST be 809 discarded and an error returned to the sender. If both are present, 810 the message MUST be discarded and an error returned to the sender. 811 Otherwise, if there is no installed soft state associated with the 812 Flow ID, the node stores the HOP information, Flow ID, and other 813 state information it chooses to retain, and forwards the message 814 towards the address in the destination field of its IP header. If 815 there is installed soft state associated with the Flow ID, the node 816 compares the contents of the HOP field with the installed state. If 817 they are identical nothing needs to be done; if they are different 818 the HOP information in the node is overwritten with the information 819 in the current message. This allows the protocol to be responsive to 820 route changes, endpoint mobility, and so on. 822 A NLS node MAY send notification of a routing change back to the 823 sender. 825 4.1.1. Route state deletion 827 Routing state accumulated through BUILDROUTE MAY be deleted in one of 828 the following circumstances: 1) when the state is explicitly torn 829 down in a message with the TEARDOWN bit set; 2) following the timeout 830 period as described in Section 2.3.2.3, or 3) as a function of 831 implementation-specific resource management. 833 4.2. HOP-BY-HOP 835 If the HOP-BY-HOP bit is set in the flags field of the NLS-TL header, 836 a NLS node MUST forward the message to the address stored in 837 associated local soft state. That is to say, the node MUST write the 838 address in the local HOP information associated with the 839 MESSAGE_IDFlow ID into the destination field in the IP header on the 840 outbound message. This is like message processing in the Resv 841 message in RFC 2205. 843 The HOP information may have been acquired using a routing process 844 based on HOP-BY-HOP processing, but it may have been acquired using 845 an external routing mechanism. If there is no HOP information stored 846 locally, the node MUST drop the message and return an error to the 847 sender. 849 4.3. BIDIRECTIONAL 851 If the BIDIRECTIONAL flag is set, the receiver must send the 852 answering message to the sender (that is to say, the destination 853 address in the IP header must be set to the address of the sender) 854 with the BUILD_ROUTE flag set and the HOP_BY_HOP flag set to 0. As 855 with the message sent from the sender to the receiver, the HOP TLV 856 contains information used to install routing state. If the nodes are 857 already authenticated to one another (they were already traversed in 858 the forward direction) it is unnecessary for the authentication 859 dialogue to be performed again. If the nodes are not already 860 authenticated to one another then the route is asymmetric and the 861 authentication dialogue must be performed. 863 Note that the sender and receiver should retain knowledge that the 864 session is bidirectional, as it may affect subsequent messaging and 865 error processing. 867 Because a complete authentication dialogue may take place in each 868 direction, with each node being authenticated to its adjacent node 869 (i.e. the dialogue takes care of authenticating both A to B and B to 870 A), this proposal neither changes the authentication dialogue nor 871 should it undermine the security of the protocol. 873 4.4. Path Teardown Messages 875 Receipt of a NLS message with the TEARDOWN bit set indicates that 876 matching path state must be deleted. Note that this is independent 877 of directionality, and the teardown message may be sent in either 878 direction. The applications which have reservations that were 879 installed by a message containing a matching Flow ID must be 880 notified, and they are responsible for managing (in this case, 881 deleting) their own flow-related state. TEARDOWN and HOP-BY-HOP MUST 882 NOT be set in the same message. 884 Unlike RFC 2205, if there is no matching path state the teardown 885 message must be forwarded. There may be path state in support of an 886 NLS application that is not running on every node, and the teardown 887 message must not be lost. 889 4.5. Network Address Translation 891 If there is one or more NAT_ADDRESS TLVs present, an NLS-capable NAT 892 must process each one that has does not have the NO_TRANSLATE bit set 893 in the flags field. Processing takes place as follows: 895 o The originator (sender) of the message creates a NAT_ADDRESS TLV 896 for each address/port/protocol tuple requiring NAT mappings. It 897 also creates a random 32- bit tag, which is used to identify the 898 address in application payloads and to tag the mapping in the 899 NAT_ADDRESS TLV in the NLS-TL header. It also sets the TRANSLATE 900 bit in the flags field and zeros the Mapped Address field. 902 o When an NLS-capable NAT receives a request, for each NAT_ADDRESS 903 TLV in which the NO_TRANSLATE bit is not set and the Mapped 904 Address is all nulls, it creates a NAT table mapping for the 905 Original Address and Original Port and inserts the "external" 906 address and port into the Mapped Address and Mapped Port fields. 908 o When an NLS-capable NAT receives a request, for each NAT_ADDRESS 909 TLV in which the NO_TRANSLATE bit is not set and the Mapped 910 Address is not nulls, it creates a NAT table mapping for the 911 Mapped Address and Mapped port and overwrites those values with 912 the new external addresses and ports. 914 o When an NLS-capable node receives a request, for reach NAT_ADDRESS 915 TLV in which the Application ID matches an NLS application payload 916 ID and the application is supported by the node, the TLV is passed 917 to the application with the application payload, allowing the 918 application module on the node to correlate and use the address 919 based on the tag [and the Original Address?] 921 Note that this approach to NAT requires that participants be 922 sensitive to directional issues in cases where ordering matters, such 923 as the need to find the outermost NAT address. API support is 924 required in order to turn the NO_TRANSLATE bit on and off as needed 925 by a particular application. 927 Also note that in cases where the only function required is NAT table 928 mapping requests, there may be no application payloads, or it may be 929 desirable to create a rudimentary NAT NLS application that does 930 nothing other than allow the receiver, or other nodes, to turn the 931 NO_TRANSLATE bit on. 933 4.6. Authentication Exchange 935 NLS provides its own message authentication mechanism, based on a 936 dialogue between adjacent nodes. We refer to this as the 937 "Authentication Exchange," or AX. 939 4.6.1. Authentication Exchange Messages 941 In the following, we consider only the Security TLVs, and we use 942 REQUEST and REPLY to represent the body of the messages. 944 1. A -> B : HDR1, REQUEST, AGID*, A_CHALLENGE 946 2. B -> A : HDR2, REQUEST, AGID, B_CHALLENGE, A_RESPONSE 948 3. A -> B : HDR3, REQUEST, AGID, B_RESPONSE 950 /* at this point, B might forward the REQUEST onward */ 952 4. B -> A : HDR4, REPLY, AUTHENTICATION 954 Note that the Flow ID in each message in the Authentication Exchange 955 MUST be the Flow ID that appeared in the original request. 957 Note as well that the fields MUST be presented in the order 958 specified, or the MAC calculations will fail. 960 Message 1 (outbound). When device A sends a message, it constructs 961 the message as follows: 963 o It consults the policy associated with that interface to determine 964 which AGID values should be included in that message. For each 965 AGID in the policy that is associated with the Application ID in 966 the message, it includes in that message an AGID TLV containing 967 the AGID value. 969 o After the AGID TLVs have been included, an A_CHALLENGE TLV is 970 constructed and included in the message. 972 o In the NLS-TL header for message 1, the AX_CHALLENGE flag must be 973 set. 975 Message 1 (inbound). Device B receives (or intercepts) Message 1 and 976 processes it as follows: 978 o The local policy associated with the interface on which the 979 message arrived is checked to determine which AGIDs are associated 980 with the Application ID in the message. If the AGID set in the 981 message intersects with the locally derived AGID set, then one of 982 the AGID values is chosen to be 'active'; this choice is 983 arbitrary. Otherwise, the AX cannot be successfully completed, 984 and an "AGID not found" error message SHOULD be returned. 986 Message 2 (outbound). Device B constructs Message 2 as follows: 988 o The NLS header is identical to that of Message 1, except that the 989 AX_CHALLENGE and AX_RESPONSE flags are now set. The TLVs from 990 Message 1 are copied verbatim into Message 2, in order, except for 991 the AGID TLVs and the A_CHALLENGE TLV. A single AGID TLV 992 containing the active AGID is appended to Message 2, followed by a 993 B_CHALLENGE TLV and an A_RESPONSE TLV. The B_CHALLENGE TLV is 994 constructed by generating its Nonce field uniformly at random. 995 The A_RESPONSE TLV contains a message authentication code (MAC) 996 value computed over the complete Message 1, also containing the 997 A_CHALLENGE, the B_CHALLENGE, the A_RESPONSE (set to zero for the 998 purpose of the MAC calculation) and including the NLS header, 999 using the secret key associated with the AGID. Device B then 1000 sends Message 2 to Device A. 1002 o In the NLS-TL header in Message 2, the AX_CHALLENGE and 1003 AX_RESPONSE flags must be set 1005 o If the optional ECHO TLV is used, it must be placed after the AGID 1006 (i.e. between the AGID and the A_CHALLENGE) 1008 For the purpose of the MAC calculation for A_RESPONSE, the "entire 1009 NLS message" is: 1011 HDR1||REQUEST||AGID||A_CHALLENGE||A_RESPONSE||B_CHALLENGE 1013 Message 2 (inbound). Device A processes Message 2 by performing the 1014 following checks: 1016 o Verifying that the AGID in the message is associated with the 1017 Application ID in the NLS message. If it is not, then the 1018 Authentication Exchange cannot be successfully completed, an error 1019 message of "Insufficient authorization" SHOULD be returned, and 1020 the connection MUST be abandoned. 1022 o Verifying that the TLVs other than the security TLVs in Message 2 1023 match the non-security TLVs in Message 1. The two messages should 1024 be bitwise identical, besides the security TLVs (and the transport 1025 headers below the NLS header). If the messages do not match, then 1026 the Authentication Exchange cannot be successfully completed, an 1027 error message of "Request/reply mismatch" SHOULD be returned, and 1028 the connection MUST be abandoned. 1030 o If the other checks pass, then Device A computes its own value of 1031 the A_RESPONSE TLV, using as input the key associated with the 1032 AGID in the message, and the locally cached copy of Message 2. 1033 Note that it may be necessary to make a temporary copy of the 1034 value of the A_RESPONSE MAC field before setting that field to 1035 zero, in order to compare the locally computed value to the 1036 received value. 1038 o If the locally constructed A_RESPONSE does not match the 1039 A_RESPONSE in Message 2, then the Authentication Exchange cannot 1040 be successfully completed, an error message of "Authentication 1041 failure" SHOULD be returned, and the connection MUST be abandoned. 1043 If all of those those steps are passed, then Message 3 is computed as 1044 described below. 1046 o Message 3 (outbound): Device A constructs Message 3 as follows. 1047 The NLS header is identical to that of Message 2, except that the 1048 AX_RESPONSE flag is set, and the AX_CHALLENGE flag is not set. 1049 The TLVs from Message 2 are copied verbatim into Message 3, in 1050 order, except for the A_RESPONSE TLV. An A_CHALLENGE and 1051 B_RESPONSE TLV are appended to Message 3. The B_RESPONSE TLV is 1052 constructed by computing the MAC over the entire NLS message from 1053 the header up to and including the B_RESPONSE TLV (with the MAC 1054 field set to zero), using the secret key associated with the AGID. 1055 Device A then sends Message 3 to Device B. 1057 o In the Message 3 NLS-TL header, the AX_RESPONSE flag must be set 1059 o If the optional ECHO TLV is used, it MUST follow the AGID (i.e. 1060 between the AGID and the B_RESPONSE). 1062 For the purpose of the MAC calculation for B_RESPONSE, the "entire 1063 NLS message" is: 1065 HDR2||REQUEST||AGID||B_RESPONSE||A_CHALLENGE||B_CHALLENGE 1067 Message 3 (inbound): Device B processes Message 3 by performing the 1068 following checks: 1070 o Verifying that the AGID in the message is associated with the 1071 Application ID in the NLS message. If it is not, then the 1072 Authentication Exchange cannot be successfully completed, an error 1073 message of "Insufficient authorization" SHOULD be returned, and 1074 the connection MUST be abandoned. 1076 o Computing its own value of B_RESPONSE, by computing the MAC over 1077 the entire NLS message from the header up to and including the 1078 B_RESPONSE TLV (with the MAC field set to zero), using the secret 1079 key associated with the AGID. If the locally constructed 1080 B_RESPONSE does not match the one received in Message 3, then the 1081 message is rejected, and an error message of "Authentication 1082 failure" SHOULD be returned. Note that it may be necessary to 1083 make a temporary copy of the value of the B_RESPONSE MAC field 1084 before setting that field to zero, in order to compare the locally 1085 computed value to the received value. 1087 After an authentication exchange has completed sucessfully and a 1088 single AGID has been negotiated, the nonces sent to and received from 1089 the peer MUST both be saved for use with the AUTHENTICATION TLV. 1090 Also, the sequence number associated with the nonces MUST be set to 0 1091 immediately after finishing the exchange successfully, and before 1092 using an AUTHENTICATION TLV. Should any previous state exist (i.e. 1093 previous nonces and sequence numbers), these MUST be replaced by the 1094 new nonces (and the sequence numbers reset to 0). 1096 After these checks pass, then the body of the NLS message, with the 1097 B_RESPONSE TLV removed, is proccessed by the NLS application, that 1098 is, it is processed in the manner determined by the Application ID. 1100 4.6.2. Authentication TLV calculation 1102 The AUTHENTICATION TLV is calculated over the entire packet (as 1103 described in the next paragraph) as well as the nonce from the last 1104 challenge received from (or sent to, in the case of the receiver) the 1105 peer (from either A_CHALLENGE or B_CHALLENGE). The nonce is 1106 associated with a sequence number, which helps guard against replay 1107 attacks. The AUTHENTICATION TLV MUST be at the end of the TLV 1108 stream. 1110 The appropriate MAC algorithm to be used is negotiated in a previous 1111 Challenge/Response exchange, where AGID TLV's were exchanged and one 1112 single AGID was agreed upon. 1114 The sender: 1116 o Add an empty AUTHENTICATION TLV to the end of the TLV stream (i.e. 1117 with the HMAC field set to all 0's). 1119 o Find the last nonce received from the peer in either an 1120 A_CHALLENGE or B_CHALLENGE. 1122 o Increment the sequence number associated with the nonce by one, 1123 and write it into the 'sequence number' field of the 1124 AUTHENTICATION TLV 1126 o Calculate the HMAC from the concatenation of the entire packet 1127 (with header and the incomplete AUTHENTICATION TLV) and the nonce. 1128 Write the resulting HMAC value into the HMAC field of the 1129 AUTHENTICATION TLV. 1131 o Send the packet. 1133 The receiver: 1135 o Copy the HMAC field from the AUTHENTICATION TLV into local 1136 storage, and overwrite the HMAC value in the packet with all 0's. 1137 Find the last nonce sent to the peer in either an A_CHALLENGE or 1138 B_CHALLENGE 1140 o Calculate the HMAC from the concatenation of the entire packet 1141 (with header and the incomplete AUTHENTICATION TLV) and the nonce. 1143 o Compare the calculated value to the value copied out int he first 1144 step. 1146 o If the values match, check to see if the sequence number falls 1147 into the range of valid sequence number (as determined by a 1148 sliding window), and if so, the sliding window is updated. 1150 o If the values do NOT match, the packet MUST be discarded and an 1151 error message SHOULD be returned to the sender (rate-limited to 1152 prevent DoS attacks). 1154 The sliding window SHALL be done according to [RFC4303] Appendix A2. 1156 4.6.3. Security state transition table 1158 The security state transitions are as follows: 1160 +---------------------+-----------------------+---------------------+ 1161 | State name | Event | Transition next | 1162 | | | state | 1163 +---------------------+-----------------------+---------------------+ 1164 | Closed | Send unprotected | Closed | 1165 | | message | | 1166 | | | | 1167 | Closed | Send Message 1 | Waiting for Message | 1168 | | | 2 | 1169 | | | | 1170 | Closed | Accept Message 1, | Waiting for Message | 1171 | | send Message 2 | 3 | 1172 | | | | 1173 | Waiting for Message | Timeout expired | Closed | 1174 | 2 | | | 1175 | | | | 1176 | Waiting for Message | Reject invalid | Closed | 1177 | 2 | message | | 1178 | | | | 1179 | Waiting for Message | Accept Message 2 | Secure connection | 1180 | 2 | | established | 1181 | | | | 1182 | Waiting for Message | Timeout expired | Closed | 1183 | 3 | | | 1184 | | | | 1185 | Waiting for Message | Reject invalid | Closed | 1186 | 3 | message | | 1187 | | | | 1188 | Waiting for Message | Accept Message 3 | Secure connection | 1189 | 3 | | established | 1190 | | | | 1191 | Secure connection | Send authenticated | Secure connection | 1192 | established | message | established | 1193 +---------------------+-----------------------+---------------------+ 1195 5. Application Interface 1197 Application payloads are encapsulated within NLS-TL TLVs, and MUST 1198 follow any NAT TLVs. 1200 The Application Payload TLV carries includes the Application ID 1201 field, which is used to vector the requests off to the correct 1202 application on the router upon receipt. It is also used to identify 1203 NAT_ADDRESS TLVs to be passed to the application. In a nutshell, if 1204 the Application ID in a NAT_ADDRESS TLV matches the Application ID in 1205 an Application TLV, the NAT_ADDRESS TLV must be passed to the 1206 application along with the application payload. 1208 The Length field carries the total application payload length, 1209 excluding the header, in octets. The length must be at least 4 and 1210 be a multiple of 4. It may be necessary for an application to pad 1211 its payload to accomplish that. 1213 Note that there is no identifier in the TLV other than the 1214 Application ID. If there is a need for an application-specific 1215 identifer for reservations or other applications requiring retained 1216 state, those must be added to the application payload. 1218 6. NAT Interactions 1220 NLS uses IP addresses for routing, both end-to-end and hop-by-hop. 1221 Given the applications which NLS-TL will be transporting, it is 1222 highly likely that those applications will be using payload-embedded 1223 addresses and there will be some interactions. The use of a NAT 1224 application together with other applications can mitigate this, but 1225 there will be problems transiting non-NLS-capable NATs. 1227 When an NLS entity receives an TL message travelling in the forward 1228 direction, it writes the address in the IPv4_HOP or IPv6_HOP, as 1229 appropriate, from the packet into local per-session state and 1230 replaces the HOP data in the message with the address of the outgoing 1231 interface. When the entity is a NAT, it will write the translated-to 1232 address. Note that while it is usually the case that payload 1233 integrity protection breaks in the presence of NATs if embedded 1234 addresses are being rewritten, this is not substantially different 1235 from the rewriting of the HOP field which occurs within NLS anyway. 1237 However, if an NLS message crosses a non-NLS-capable NAT, several 1238 problems may occur. The first is that if the message is being 1239 dropped in a raw IP packet, the NAT may simply drop the packet 1240 because it doesn't know how to treat it. Another is that the address 1241 in the HOP field will be incorrect. NLS and the applications it 1242 carries cannot be expected to function properly across non- 1243 participating NATs. Discovery of a non-NLS-capable NAT is described 1244 in Section 8. 1246 7. Using NLS-TL as a stand-alone NAT traversal protocol 1248 Using the NLS Transport Layer as a stand-alone NAT traversal protocol 1249 is straightforward -- simply use the TL without application payloads, 1250 but set the NO_REWRITE flag in the NAT_ADDRESS TLV to 1. This 1251 provides two functions: 1) installation of new NAT table mappings, 1252 and 2) allowing the sender to learn what the "external" mappings are. 1253 The Application ID field in the NAT_ADDRESS TLV must be set to 0. 1255 The TL header flags in the forward direction must be 1257 HOP-BY-HOP = 0 1259 BUILD-ROUTE = 1 1261 TEARDOWN = 0 1263 The TL header flags in the reverse direction (i.e. in the response 1264 message) must be 1266 HOP-BY-HOP = 1 1268 BUILD-ROUTE = 0 1270 TEARDOWN = 0 1272 The NAT table mappings are kept fresh through the retransmission of 1273 the request every refresh period. The refresh messages are identical 1274 to the original request message. 1276 If a response message is not received, the retransmission and backoff 1277 procedures described in Section 6 of [RFC2961] MUST be used. 1279 When the NAT table mappings are no longer required, the sender must 1280 send a teardown message containing the Flow ID of the installed 1281 mappings and with the TL flags set to 1283 HOP-BY-HOP = 0 1285 BUILD-ROUTE = 0 1287 TEARDOWN = 1 1289 An acknowledgement response message is not required. If there has 1290 been no refresh message received prior to the expiration of the 1291 timeout period, the NAT table mappings must be deleted when the 1292 timeout period ends. 1294 8. Discovery of non-NLS NATs, and recovery 1296 This section describes a method of discovering non-NLS NATs in the 1297 path, and a recovery-mechanism if one is discovered. 1299 When there are non-NLS-capable NATs in the path, they will only be 1300 able to process or modify the IP/UDP header of the NLS-TL message and 1301 will not be able to understand or modify the NLS-TL message itself 1302 (including the NAT_ADDRESS_TLV inside). 1304 If there are non-NLS NATs in the path the sender needs to be made 1305 aware of this, and it should be able to fall back to processing 1306 without NLS, using any other mechanisms that may be available. Also, 1307 the NLS_ NATs in the path which have allocated the NAT mappings based 1308 on NLS NAT_ADDRESS_TLV processing, need to be able to release these 1309 mappings. 1311 The following algorithm can be applied for non-NLS NAT detection by 1312 NLS nodes : 1314 if (NAT_TL NAT_ADDRESS_TLV's mapped_addr == 0) { 1315 This NLS_TL NAT is first NLS_TL NAT in path 1316 if (NLS_TL packet's source IP address != NAT_ADDRESS_TLV's 1317 original_address) { 1318 This NLS_TL NAT is not the first in the path, and 1319 some non-NLS_TL NAT has touched this packet; 1320 send NLS_TL error message back to the sender 1321 with NLS_TL error-code = 4 (non-nls-nat in path) 1322 } else { 1323 This NLS_TL NAT is the first in the path, and no non- 1324 NLS_TL NAT has touched this packet; 1325 proceed with NLS_TL processing. 1326 } 1327 } else { 1328 This NLS_TL NAT is not the first NLS_TL NAT in path. 1329 if (NLS_TL packet's source IP address != NAT_ADDRESS_TLV's 1330 mapped_address) { 1331 Some non-NLS_TL NAT has touched this packet, send 1332 NLS_TL error message back to the sender with NLS_TL 1333 error-code = 4 (non-nls-nat in path) 1334 } else { 1335 No non-NLS_TL NAT has touched this packet; proceed 1336 with regular NLS_TL processing. 1337 } 1338 } 1340 The NLS_TL error message will be relayed back to the sender. 1341 Intermediate NLS nodes should not be processing the NLS error 1342 message, but let this NLS packet be routed back to the sender. 1344 Once the sender sees an NLS_TL error-message with Error-Code = 4 1345 (non-nls-nat in path), it should resend the same NLS_TL message as 1346 earlier with the NAT_ADDRESS_TLV's Original IPv4 Address/Port/ 1347 Protocol as earlier and the Mapped IPv4 Address/Port as NULL, but 1348 should set the TEARDOWN flag in the NLS-TL header. 1350 The intermediate NLS NATs in the path, upon seeing an NLS_TL message 1351 with the TEARDOWN bit set, should delete its local NAT mapping 1352 corresponding to the Flow ID and send the message on towards the 1353 receiver, traversing other NLS-capable NATs along the path which will 1354 also process the TEARDOWN message. 1356 9. Endpoint Processing 1358 This section describes the procedures used in the endpoints (that is 1359 to say, the sender and the receiver) for processing NLS packets. 1360 Note that these are the endpoints for the purposes of describing an 1361 end-to-end NLS path; they may actually be network entities or 1362 proxies. 1364 9.1. Sending 1366 When a host or its proxy wishes to send an NLS application request, 1367 it puts together the application payload and encapsulates it in a 1368 transport layer packet. 1370 If the application needs to request NAT service because of its use of 1371 addresses for reservations, etc., it must create a random 32-bit tag 1372 for use as an address token in the application payload, and it must 1373 create a NAT_ADDRESS TLV in which it inserts the address and port for 1374 which it is requesting NAT service, as well as the 32-bit tag. 1376 For example, in a hypothetical QoS application that needed NAT 1377 services for the address 192.0.2.110, TCP port 6603 in the flow 1378 description, it would generate the random tag 0x24924924, use that in 1379 the application payload instead of an address, and create a 1380 NAT_ADDRESS TLV with the following values: 1382 Application ID = QoS 1384 Flags = TRANSLATE 1386 Proto = TCP 1388 Address ID = 0x24924924 1390 Original IPv4 Address = 192.0.2.110 1392 Original Port = 6603 1394 The endpoint also needs to set the flags that determine how path 1395 establishment and routing are to be handled on intermediate nodes. 1396 In some cases the application requires no stored state in NLS nodes 1397 or it simply requires a single NLS pass. Examples of this kind of 1398 application include topology discovery, tunnel endpoint discovery, or 1399 diagnostic triggers. In this case, in the NLS-TL header both the 1400 HOP-BY-HOP flag and the BUILD-ROUTE flag are set to 0. 1402 If an application is establishing per-node state and wants the NLS 1403 transport layer to establish and pin NLS routing for it, as might be 1404 the case with a QoS application or a firewall pinholing application, 1405 the sending endpoint must set the BUILD-ROUTE flag to 1 and the HOP- 1406 BY-HOP flag to 0. 1408 The endhost then UDP encapsulates the NLS-TL packet, and transmits it 1409 on UDP port 7549. 1411 9.2. Receiving 1413 An NLS node "knows" that it's an endpoint or proxy when the following 1414 conditions are satisfied: 1416 if (IP destination address == my address) { 1417 if (HOP_BY_HOP) 1418 if (next hop data available) 1419 forward it on; 1420 else 1421 it's mine; 1422 } 1424 When an endpoint receives a packet and identifies it as terminating 1425 there, it demultiplexes the payload and passes the payload and 1426 associated NAT_ADDRESS data to the appropriate application. 1428 If an application in the payload is not supported by the endpoint, 1429 the endpoint must return a message to the sender with an ERROR_CODE 1430 TLV with the error value set to 3 (Unrecognized application). 1432 10. Intermediate node processing 1434 The processing of NLS-TL packets at intermediate nodes is 1435 substantially the same as processing at endpoints. Upon the arrival 1436 of a request, the node demultiplexes the packet contents and vectors 1437 the application payloads off to their respective applications. 1439 One major difference from endpoint processing is the handling of NAT 1440 requests by NAT intermediate nodes. When an NLS-capable NAT receives 1441 an NLS request, it checks for the presence of NAT_ADDRESS TLVs. For 1442 each NAT_TLV, it executes the process described in Section 4.5. 1444 For state maintenance and forwarding, the node must follow the 1445 processes described in Section 4.1, Section 4.2, and Section 4.4. 1447 11. Using NLS-TL to support bidirectional reservations 1449 When an application that uses NLS-TL to transport reservation 1450 requests (for example, QoS reservations or firewall pinholes) and it 1451 wishes to make the request for a bidirectional data stream, the 1452 reservations should be made when the message is received in the 1453 "forward" direction. Note that this is a significant departure from 1454 the model used in RSVP and assumed in previous versions of NLS-TL. 1455 The reason for this should be apparent -- if the route between the 1456 sender and receiver is asymmetric, it is possible that a device 1457 traversed by a PATH message may not be traversed by a RESV message, 1458 and vice-versa. 1460 It may be desirable to have different characteristics for the 1461 reservation in one direction than for the other. In this case the 1462 NLS application designer should make provision for identifying 1463 reservation specifications to be used in each direction. 1465 It should also not be assumed, as is done in RSVP, that error 1466 messages will traverse all affected nodes unless care is taken by the 1467 sender, or the "owner" of the reservation, to ensure that error 1468 messages are propagated correctly. So, for example, if a reservation 1469 fails at a particular node, it may not be sufficient to return the 1470 error message towards the sender. 1472 An application that manages reservations may wish to refresh 1473 application state more frequently than it wishes to refresh route 1474 state. In that case it should send the message with the 1475 BIDIRECTIONAL and HOP_BY_HOP flags set, and the BUILD_ROUTE flag set 1476 to 0. 1478 12. Security Considerations 1480 12.1. Overview 1482 This section describes a method for providing cryptographic 1483 authentication to the Network Layer Signaling (NLS) transport layer 1484 protocol. The method incorporates a peer discovery mechanism. 1485 Importantly, there is no provision for confidentiality. This fact 1486 simplifies the protocol, and removes the need for export control on 1487 products implementing it. NLS applications which require 1488 confidentiality may provide it themselves. 1490 This mechanism provides both entity and message authentication along 1491 a single hop. In other words, the device on each end of the hop is 1492 assured that the identity of the other device, and the content of the 1493 message from that device, are correct. These security services are 1494 provided only on a hop-by-hop basis. That is, there are no 1495 cryptogrpahic services provided across multiple hops, and each hop 1496 can independently use or not use authentication. In the following, 1497 we restrict our discussion to a single hop along an NLS path. 1499 In order to support authentication, we introduce an optional two- 1500 message exchange into NLS called the Authentication Exchange, or AX. 1501 This exchange is needed in order to carry the challenge-response 1502 information, and is described in detail in Section 4.6. 1504 12.2. Security Model 1506 Authenticated NLS-TL provides both authorization and entity 1507 authentication using a group model. Authorizations correspond to 1508 particular applications. An Authorization Group (AG) is a set of 1509 network interfaces that share the following information: 1511 o a list of NLS Application IDs; these correspond to applications 1512 which the group is authorized to use, 1514 o a group authentication key, 1516 o a Message Authentication Code (MAC) algorithm type 1518 Note that AGs are associated with interfaces and not devices since in 1519 many situations there are different trust levels associated with 1520 different interfaces. 1522 For each device implementing Authenticated NLS-TL, each interface is 1523 associated with a list of Application IDs, each of which is 1524 associated with: 1526 o a list of AGIDs that authorize the corresponding application, or 1528 o the symbol ALLOW, which indicates that the application has been 1529 explictly allowed on the associated interface, or 1531 o the symbol DROP, which indicates that the application has been 1532 explicitly disallowed on the associated interface. 1534 This model provides authorization at the NLS-TL layer. For example, 1535 it is impossible to authorize VoIP traversal of a firewall while 1536 still disallowing telnet across the firewall. The model can be 1537 expanded to accomodate finer grained authorizations, but this issue 1538 is not considered further in this draft. Sensitive applications, 1539 such as firewall pinholing, as well as applications requiring finer- 1540 grained authorizations, must provide their own authentication and 1541 authorization. 1543 12.3. Cryptography 1545 Authenticated NLS-TL uses a single cryptographic function: a 1546 pseudorandom function that accepts arbitrary-length inputs and 1547 produces fixed-length outputs. This function is used as a message 1548 authentication code (MAC). 1550 The default MAC algorithm is HMAC SHA1, with a length truncated to 96 1551 bits. No other message authentication code is defined. Other MACs 1552 MAY be implemented. Each key used in NLS is associated with a single 1553 MAC algorithm; thus crypto algorithm agility is supported by the same 1554 protocol mechanisms that support key agility. In particular, an NLS 1555 device can determine the MAC algorithm used by referencing the Value 1556 field of the Authorization Group ID, or AGID, (defined in 1557 Section 2.3.2.8). 1559 12.3.1. Keys 1561 Authenticated NLS-TL uses group keys, in order to reduce the amount 1562 of protocol state and to mitigate the peer-discovery problem. 1564 Keys may be acquired or provisioned one of three ways: 1) through 1565 manual provisioning, 2) by being fetched from a central data store, 1566 or 3) through an automated key management system. 1568 Implementations MUST provide a way to set and delete keys manually. 1569 However, they SHOULD also provide an automated group key management 1570 system such as GDOI [RFC3547], so that efficient revocation is 1571 possible. 1573 When using an automated key management system, the AGID MAY be used 1574 to differentiate key versions as well as authorization groups, to 1575 support rekeying. It can be expected to change over the lifetime of 1576 a message flow, while when using manually-provisioned keys the AGID 1577 may be expected to remain static. 1579 12.3.2. Reflection Attacks 1581 NLS is designed to resist reflection attacks. That family of attacks 1582 works against poorly designed mutual authentication systems by 1583 tricking one party into providing the response for its own challenge. 1584 In order to resist reflection attacks, distinct TLV types are defined 1585 for the first and second challenges, the A_CHALLENGE and B_CHALLENGE. 1586 This fact ensures that the two invocations of the MAC during a single 1587 challenge/response exchange will necessarily have different inputs, 1588 thus thwarting reflection attacks. 1590 13. IANA Considerations 1592 There are several parameters for which NLS-TL will need registry 1593 services. These include 1595 o a registry for NLS Application IDs (NLS Application Identifiers) 1596 and for 1598 o NLS-TL TLV identifiers (NLS TLVs). 1600 o NLS-TL Error codes and error values 1602 Initial values are given below. Future assignments are to be made 1603 through expert review. 1605 NLS-TL also uses UDP port number 7549. 1607 13.1. NLS Application Identifiers 1609 NAME VALUE DEFINITION 1611 Network Address Translation 0 NAT 1612 Control Point Discovery 1 PacketCable CDP 1613 Firewall Traversal 2 1615 Note that while there is no application payload for NAT, we define an 1616 application ID to support NLS-TL authentication when using an 1617 automated key management system. The details of the interface to a 1618 key management system are out of the scope of this document. 1620 13.2. NLS TLVs 1622 +---------------------+-------+----------------------+ 1623 | NAME | VALUE | DEFINITION | 1624 +---------------------+-------+----------------------+ 1625 | NAT_ADDRESS | 1 | See Section 2.3.2.1 | 1626 | | | | 1627 | APPLICATION_PAYLOAD | 2 | See Section 2.3.2.2 | 1628 | | | | 1629 | TIMEOUT | 3 | See Section 2.3.2.3 | 1630 | | | | 1631 | IPV4_HOP | 4 | See Section 2.3.2.4 | 1632 | | | | 1633 | IPV6_HOP | 5 | See Section 2.3.2.5 | 1634 | | | | 1635 | IPV4_ERROR_CODE | 6 | See Section 2.3.2.6 | 1636 | | | | 1637 | IPV6_ERROR_CODE | 7 | See Section 2.3.2.7 | 1638 | | | | 1639 | AGID | 8 | See Section 2.3.2.8 | 1640 | | | | 1641 | A_CHALLENGE | 9 | See Section 2.3.2.9 | 1642 | | | | 1643 | A_RESPONSE | 10 | See Section 2.3.2.10 | 1644 | | | | 1645 | B_CHALLENGE | 11 | See Section 2.3.2.11 | 1646 | | | | 1647 | B_RESPONSE | 12 | See Section 2.3.2.12 | 1648 | | | | 1649 | AUTHENTICATION | 13 | See Section 2.3.2.13 | 1650 | | | | 1651 | ECHO | 14 | See Section 2.3.2.14 | 1652 +---------------------+-------+----------------------+ 1654 13.3. Error codes and values 1656 NAME VALUE DEFINITION 1658 Error Code 0 No error 1659 Error Code 1 Bad parameters 1660 Error Value 1 HOP-BY-HOP and BUILD-ROUTE both 1661 present 1662 Error Value 2 BUILD-ROUTE present but no HOP TLV 1663 Error Value 3 HOP-BY-HOP present but 1664 no local stored routing state 1665 Error Value 4 Message length not a multiple of 4 1666 Error Code 2 Unrecognized TLV 1667 Error Code 3 Unrecognized application 1668 Error Code 4 Non-NLS NAT detected in path 1669 Error Code 5 Security error 1670 Error Value 1 AGID not found 1671 Error Value 2 Insufficient authorization 1672 Error Value 3 Request/reply mismatch 1673 Error Value 4 Authentication Failure 1674 Error Code 128 No message 1675 Error Code 129 Sending node has 1676 detected a route change 1678 14. References 1680 14.1. Normative References 1682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1683 Requirement Levels", BCP 14, RFC 2119, March 1997. 1685 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1686 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1687 Functional Specification", RFC 2205, September 1997. 1689 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 1690 and S. Molendini, "RSVP Refresh Overhead Reduction 1691 Extensions", RFC 2961, April 2001. 1693 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 1694 Group Domain of Interpretation", RFC 3547, July 2003. 1696 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1697 RFC 4303, December 2005. 1699 14.2. Informative References 1701 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1702 Services in the Internet Architecture: an Overview", 1703 RFC 1633, June 1994. 1705 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1706 RFC 2711, October 1999. 1708 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1709 Bosch, "Next Steps in Signaling (NSIS): Framework", 1710 RFC 4080, June 2005. 1712 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 1713 Protocol Architecture", RFC 4251, January 2006. 1715 [braden] Braden, R. and R. Lindell, "A Two-Level Architecture for 1716 Internet Signaling", draft-braden-2level-signaling-01.txt 1717 (work in progress), November 2002. 1719 Appendix A. Acknowledgements 1721 The authors would like to express their gratitude to Jan Vilhuber, 1722 Senthil Sivakumar, Bill Foster, and Dan Wing for their careful review 1723 and feedback. Special thanks to Jan for his text on challenge/ 1724 response calculations, and to Rajesh Karnik and Lisa Fang for their 1725 help in clarifying the text describing the authentication exchange. 1726 Brian Weis and Sheela Rowles provided invaluable discussion of 1727 automated group key management. 1729 Authors' Addresses 1731 Melinda Shore 1732 Cisco Systems 1733 809 Hayts Road 1734 Ithaca, New York 14850 1735 USA 1737 Email: mshore@cisco.com 1739 David A. McGrew 1740 Cisco Systems 1741 510 McCarthy Blvd 1742 Milpitas, California 95035 1743 USA 1745 Email: mcgrew@cisco.com 1747 Kaushik Biswas 1748 Cisco Systems 1749 510 McCarthy Blvd 1750 Milpitas, California 95035 1751 USA 1753 Email: kbiswas@cisco.com 1755 Full Copyright Statement 1757 Copyright (C) The IETF Trust (2008). 1759 This document is subject to the rights, licenses and restrictions 1760 contained in BCP 78, and except as set forth therein, the authors 1761 retain all their rights. 1763 This document and the information contained herein are provided on an 1764 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1765 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1766 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1767 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1768 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1769 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1771 Intellectual Property 1773 The IETF takes no position regarding the validity or scope of any 1774 Intellectual Property Rights or other rights that might be claimed to 1775 pertain to the implementation or use of the technology described in 1776 this document or the extent to which any license under such rights 1777 might or might not be available; nor does it represent that it has 1778 made any independent effort to identify any such rights. Information 1779 on the procedures with respect to rights in RFC documents can be 1780 found in BCP 78 and BCP 79. 1782 Copies of IPR disclosures made to the IETF Secretariat and any 1783 assurances of licenses to be made available, or the result of an 1784 attempt made to obtain a general license or permission for the use of 1785 such proprietary rights by implementers or users of this 1786 specification can be obtained from the IETF on-line IPR repository at 1787 http://www.ietf.org/ipr. 1789 The IETF invites any interested party to bring to its attention any 1790 copyrights, patents or patent applications, or other proprietary 1791 rights that may cover technology that may be required to implement 1792 this standard. Please address the information to the IETF at 1793 ietf-ipr@ietf.org. 1795 Acknowledgment 1797 Funding for the RFC Editor function is provided by the IETF 1798 Administrative Support Activity (IASA).