idnits 2.17.1 draft-ietf-nsis-ext-07.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 13, 2010) is 5125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-24 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-21 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-02) exists of draft-bless-nsis-est-mrm-01 == Outdated reference: A later version (-15) exists of draft-ietf-nsis-ntlp-sctp-09 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-11 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft TKK 4 Intended status: Informational R. Bless 5 Expires: October 15, 2010 KIT 6 J. Loughney 7 Nokia 8 E B. Davies, Ed. 9 Folly Consulting 10 April 13, 2010 12 Using and Extending the NSIS Protocol Family 13 draft-ietf-nsis-ext-07.txt 15 Abstract 17 This document gives an overview of the Next Steps in Signaling (NSIS) 18 framework and protocol suite created by the NSIS working group during 19 the period 2001-2009 together with suggestions on how the industry 20 can make use of the new protocols, and how the community can exploit 21 the extensibility of both the framework and existing protocols to 22 address future signaling needs. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 15, 2010. 41 Copyright Notice 43 Copyright (c) 2010 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. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3 60 3. The General Internet Signaling Transport . . . . . . . . . . . 6 61 4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 10 62 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12 63 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13 64 6.1. Deployment Issues Due to Use of RAO . . . . . . . . . . . 14 65 6.2. Deployment Issues with NATs and Firewalls . . . . . . . . 15 66 6.3. Incremental Deployment and Workarounds . . . . . . . . . . 15 67 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 16 69 8.1. Overview of Administrative Actions Needed When 70 Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 17 71 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 8.2.1. Use of Different Message Routing Methods . . . . . . . 17 73 8.2.2. Use of Different Transport Protocols or Security 74 Capabilities . . . . . . . . . . . . . . . . . . . . . 18 75 8.2.3. Use of Alternative Security Services . . . . . . . . . 18 76 8.2.4. Query Mode Packet Interception Schemes . . . . . . . . 18 77 8.2.5. Use of Alternative NAT Traversal Mechanisms . . . . . 20 78 8.2.6. Additional Error Identifiers . . . . . . . . . . . . . 20 79 8.2.7. Defining New Objects to be Carried in GIST . . . . . . 20 80 8.2.8. Adding New Message Types . . . . . . . . . . . . . . . 21 81 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 21 83 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 23 84 8.6. New NSLP Protocols . . . . . . . . . . . . . . . . . . . . 23 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 93 1. Introduction 95 The Next Steps in Signaling (NSIS) Working Group was formed in 96 November 2001 to develop an Internet signaling protocol suite that 97 would attempt to remedy some of the perceived shortcomings of 98 solutions based on the Resource ReSerVation Protocol (RSVP), e.g., 99 with respect to mobility and Quality of Service (QoS) 100 interoperability. The initial charter was focused on QoS signaling 101 as the first use case, taking as the background for the work RSVP. 102 In May 2003, middlebox traversal was added as an explicit second use 103 case. The requirements for the new generation of signaling protocols 104 are documented in [RFC3726] and an analysis of existing signaling 105 protocols can be found in [RFC4094]. 107 The design of NSIS is based on a two-layer model, where a general 108 signaling transport layer provides services to an upper signaling 109 application layer. The design was influenced by Bob Braden's 110 Internet Draft entitled "A Two-Level Architecture for Internet 111 Signaling" [I-D.braden-2level-signal-arch]. 113 This document gives an overview of the NSIS framework and protocol 114 suite at the time of writing (2009), providing an introduction to the 115 use cases for which the current version of NSIS was designed, notes 116 on how to deploy NSIS in existing networks and summarizing how the 117 protocol suite can be enhanced to satisfy new use cases. 119 2. The NSIS Architecture 121 The design of the NSIS protocol suite reuses ideas and concepts from 122 RSVP but essentially divides the functionality into two layers. The 123 lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge 124 of transporting the higher layer protocol messages to the next 125 signaling node on the path. This includes discovery of the next hop 126 NSIS node, which may not be the next routing hop, and different 127 transport and security services depending on the signaling 128 application requirements. The General Internet Signaling Transport 129 (GIST) [I-D.ietf-nsis-ntlp] has been developed as the protocol that 130 fulfills the role of the NTLP. The NSIS protocol suite supports both 131 IP protocol versions, IPv4 and IPv6. 133 The actual signaling application logic is implemented in the higher 134 layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). 135 While GIST is only concerned with transporting NSLP messages hop-by- 136 hop between pairs of signaling nodes, the end-to-end signaling 137 functionality is provided by the NSLP protocols if needed. Not all 138 NSLP protocols need to perform end-to-end signaling. The current 139 protocols have features to confine the signaling to a limited part of 140 the path (such as the interior of a domain). Messages transmitted by 141 GIST on behalf of an NSLP are identified by a unique NSLP identifier 142 (NSLPID) associated with the NSLP. Two NSLP protocols are currently 143 specified: one concerning Quality of Service signaling 144 [I-D.ietf-nsis-qos-nslp]and one to enable NAT/Firewall traversal 145 [I-D.ietf-nsis-nslp-natfw]. 147 NSIS is primarily designed to provide the signaling needed to install 148 state on nodes that lie on the path that will be taken by some end- 149 to-end flow of data packets; the state installed should facilitate or 150 enhance some characteristic of the data flow. This is typically 151 achieved by routing signaling messages along the same path (known as 152 "path-coupled signaling") and intercepting the signaling message at 153 NSIS capable nodes. However, the NSIS architecture is designed to be 154 flexible, and the routing of signaling messages is controlled by the 155 Message Routing Method (MRM) that is applied to the signaling 156 messages. The initial specifications define two MRMs: 157 o the basic Path-Coupled MRM designed to drive signaling along the 158 path that will be followed by the data flow, and 159 o an alternative Loose End MRM which is applicable for 160 preconditioning the state in firewalls and Network Address 161 Translation (NAT) middleboxes when data flow destinations lie 162 behind this sort of middlebox. Without preconditioning these 163 middleboxes will generally reject signaling messages originating 164 outside the region 'protected' by the middlebox and where the 165 destination is located. 167 Parameters carried by each signaling message drive the operation of 168 the relevant transport or signaling application. In particular, the 169 messages will carry Message Routing Information (MRI) that will allow 170 the NSIS nodes to identify the data flow to which the signaling 171 applies. Generally, the intercepted messages will be reinjected into 172 the network after processing by the NSIS entities and routed further 173 towards the destination, possibly being intercepted by additional 174 NSIS capable nodes before arriving at the flow endpoint. 176 As with RSVP, it is expected that the signaling message will make a 177 complete round trip either along the whole end-to-end path or a part 178 of it if the scope of the signaling is limited. This implements a 179 two-phase strategy in which capabilities are assessed and provisional 180 reservations are made on the outbound leg; these provisional 181 reservations are then confirmed and operational state installed on 182 the return leg. Unlike RSVP, signaling is normally initiated at the 183 source of the data flow making it easier to ensure that the signaling 184 follows the expected path of the data flow, but can also be receiver 185 initiated as in RSVP. 187 A central concept of NSIS is the Session Identifier (SID). Signaling 188 application states are indexed and referred to through the SID in all 189 the NSLPs. This decouples the state information from IP addresses, 190 allowing dynamic IP address changes for signaling flows, e.g., due to 191 mobility: changes in IP addresses do not force complete tear down and 192 re-initiation of a signaling application state, merely an update of 193 the state parameters in the NSLP(s), especially the MRI. 195 At the NTLP (GIST) layer the SID is not meaningful by itself, but is 196 rather used together with the NSLP identifier (NSLPID) and the 197 Message Routing Information (MRI). This 3-tuple is used by GIST to 198 index and manage the signaling flows. Changes of routing or dynamic 199 IP address changes, e.g., due to mobility, will require GIST to 200 modify the Messaging Associations (MAs) that are used to channel NSLP 201 messages between adjacent GIST peers in order to satisfy the NSLP MRI 202 for each SID. 204 The following design restrictions were imposed for the first phase of 205 the protocol suite. They may be lifted in future and new 206 functionality may be added into the protocols at some later stage. 208 o Initial focus on MRMs for path-coupled signaling: GIST transports 209 messages towards an identified unicast data flow destination based 210 on the signaling application request, and does not directly 211 support path-decoupled signaling, e.g., QoS signaling to a 212 bandwidth broker or other off-path resource manager. The 213 framework also supports a "Loose-End" message routing method used 214 to discover GIST nodes with particular properties in the direction 215 of a given address, for example the NAT/FW NSLP uses this method 216 to discover a NAT along the upstream data path. 217 o No multicast support: Introducing support for multicast was deemed 218 too much overhead, considering the currently limited support for 219 global IP multicast. Thus, the current GIST and the NSLP 220 specifications consider unicast flows only. 222 The key documents specifying the NSIS framework are: 224 o Requirements for Signaling Protocols [RFC3726] 225 o Next Steps in Signaling: Framework [RFC4080] 226 o Security Threats for NSIS [RFC4081] 228 The protocols making up the suite specified by the NSIS working group 229 are documented in: 230 o The General Internet Signaling Transport protocol 231 [I-D.ietf-nsis-ntlp] 232 o Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp] 233 o The QoS specification template [I-D.ietf-nsis-qspec] 234 o NAT/Firewall traversal NSLP [I-D.ietf-nsis-nslp-natfw] 236 The next three sections provide a brief survey of GIST, the QoS NSLP, 237 and the NAT/Firewall NSLP. 239 3. The General Internet Signaling Transport 241 The General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] 242 provides a signaling transport and security services to NSIS 243 Signaling Layer Protocols (NSLP) and the associated signaling 244 applications. GIST does not define new IP transport protocols or 245 security mechanisms but rather makes use of existing protocols, such 246 as TCP, UDP, TLS and IPsec. Applications can indicate the desired 247 transport attributes for the signaling flow, e.g., unreliable or 248 reliable, and GIST then chooses the most appropriate transport 249 protocol(s) to achieve the goals of the flow. GIST will normally use 250 UDP if unreliable signaling is adequate, TCP if reliability is 251 required and TLS over TCP for secure (and reliable) signaling flows 252 but there extensibility provisions within GIST that will allow 253 alternatives to be specified in future. The GIST layered protocol 254 stack is shown in Figure 1. 256 +-----+ +--------+ +-------+ 257 | | | | | | 258 | QoS | | NAT/FW | | ... | NSLP 259 | | | | | | 260 +-----+ +--------+ +-------+ 262 ---------------------------------------------------------------------- 263 +--------------------------+ 264 | | 265 | GIST | NTLP 266 | | 267 +--------------------------+ 269 ---------------------------------------------------------------------- 270 +------------+-------------+ 271 | TLS | DTLS | Security Support* 272 +------------+-------------+ 273 | TCP | SCTP | UDP | DCCP | Transport Protocol* 274 +--------------------------+ 275 +--------------------------+ 276 | IPsec | 277 +--------------------------+ 278 +--------------------------+ 279 | IPv4 | IPv6 | 280 +--------------------------+ 282 * The Security Support and Transport Protocol layers show some 283 possible protocols that could be used to transport NSIS messages. To 284 provide authentication and/or integrity protection support the 285 transport protocol has to be paired with a suitable security 286 mechanism, e.g., TCP with TLS or DCCP with DTLS. 288 Figure 1: The NSIS protocol stack 290 GIST divides up the end-to-end path to be taken by the data flow into 291 a number of segments between pairs of NSIS aware peer nodes located 292 along the path. Not every router or other middlebox on the path 293 needs to be NSIS aware: each segment of the signaling path may 294 incorporate several routing hops. Also not every NSIS aware node 295 necessarily implements every possible signaling application. If the 296 signaling for a flow requests services from a subset of the 297 applications, then only nodes that implement those services are 298 expected to participate as peers, and even some of these nodes can 299 decline to operate on a particular flow if, for example, the 300 additional load might overload the processing capability of the node. 301 These characteristics mean that incremental deployment of NSIS 302 capabilities is possible both with the initial protocol suite, and 303 for any future NSLP applications that might be developed. The 304 following paragraphs describe how a signaling segment is setup 305 offering the transport and security characteristics needed by a 306 single NSLP. 308 When an NSLP application wants to send a message towards a flow 309 endpoint, GIST starts the process of discovering the next signaling 310 node by sending a Query message towards the destination of the 311 related data flow. This Query carries the NSLP identifier (NSLPID) 312 and Message Routing Information (MRI) among others. The MRI contains 313 enough information to control the routing of the signaling message 314 and identify the associated data flow. The next GIST node on the 315 path receives the message and if it is running the same NSLP, it 316 provides the MRI to the NSLP application and requests it to make a 317 decision on whether to peer with the querying node. If the NSLP 318 application chooses to peer, GIST sets up a Message Routing State 319 (MRS) between the two nodes for the future exchange of NSLP data. 320 State setup is performed by a three-way handshake that allows for 321 negotiation of signaling flow parameters and provides counter- 322 measures against several attacks like denial-of-service by using 323 cookie mechanisms and a late state installation option. 325 If a transport connection is required and needs to provide for 326 reliable or secure signaling, like TCP or TLS/TCP, a Messaging 327 Association (MA) is established between the two peers. An MA can be 328 re-used for signaling messages concerning several different data 329 flows, i.e., signaling messages between two nodes are multiplexed 330 over the same transport connection. This can be done when the 331 transport requirements (reliability, security) of a new flow can be 332 met with an existing MA, i.e., the security and transport properties 333 of an existing MA are equivalent or better than what is requested for 334 a potential new MA. 336 For path-coupled signaling, we need to find the nodes on the data 337 path that should take part in the signaling of an NSLP and invoke 338 them to act on the arrival of such NSLP signaling messages. The 339 basic concept is that such nodes along a flow's data path intercept 340 the corresponding signaling packets and are thus discovered 341 automatically. GIST places a Router Alert Option (RAO) in Query 342 message packets to ensure that they are intercepted by relevant NSIS 343 aware nodes as in RSVP. 345 Late in the development of GIST serious concerns were raised in the 346 IETF about the security risks and performance implications of 347 extensive usage of the RAO [I-D.rahman-rtg-router-alert-dangerous]. 348 Additionally evidence was discovered indicating that several existing 349 implementations of RAO were inconsistent with the (intention of the) 350 standards and would not support the NSIS usage. There were also 351 concerns that extending the need for RAO recognition in the fast path 352 of routers that are frequently implemented in hardware would delay or 353 deter implementation and deployment of NSIS. Eventually it was 354 decided that NSIS would continue to specify RAO as its primary means 355 for triggering interception of signaling messages in intermediate 356 nodes on the data path, but the protocol suite would be published 357 with Experimental status rather than on the Standards Track while 358 deployment experience was gathered. More information about the use 359 of RAO in GIST can be found in [I-D.hancock-nsis-gist-rao]. Also the 360 deployment issues that arise from the use of RAO are discussed in 361 Section 6.1. 363 Alternative mechanisms have been considered to allow nodes to 364 recognize NSIS signaling packets that should be intercepted. For 365 example NSIS nodes could recognize UDP packets directed to a specific 366 destination port as Query messages that need to be intercepted even 367 though they are not addressed to the intercepting node. GIST 368 provides for the use of such alternatives as a part of its 369 extensibility design. NSIS recognizes that the workload imposed by 370 intercepting signaling packets could be considerable relative to the 371 work needed just to forward such packets. To keep the necessary load 372 to a minimum NSIS provides mechanisms to limit the number of 373 interceptions needed by constraining the rate of generation and 374 allowing for intentional bypassing of signaling nodes that are not 375 affected by particular signaling requests. This can be accomplished 376 either in GIST or in the NSLP. 378 Since GIST carries information about the data flow inside its 379 messages (in the MRI), NAT gateways must be aware of GIST in order to 380 let it work correctly. GIST provides a special object for NAT 381 traversal so that the actual translation is disclosed if a GIST-aware 382 NAT gateway provides this object. 384 As with RSVP, all the state installed by NSIS protocols is "soft- 385 state" that will expire and be automatically removed unless it is 386 periodically refreshed. NSIS state is held both at the signaling 387 application layer and in the signaling transport layer, and is 388 maintained separately. NSLPs control the lifetime of the state in 389 the signaling application layer by setting a timeout and sending 390 periodic "keep alive" messages along the signaling path if no other 391 messages are required. The MAs and the routing state are maintained 392 semi-independently by the transport layer, because MAs may be used by 393 multiple NSLP sessions, and can also be recreated "on demand" if the 394 node needs to reclaim resources. The transport layer can send its 395 own "keep alive" messages across a MA if no NSLP messages have been 396 sent, for example if the transport layer decides to maintain a 397 heavily used MA even though there is no current NSLP session using 398 it. State can also be deleted explicitly when no longer needed. 400 If there is a change in the route used by a flow for which NSIS has 401 created state, NSIS needs to detect the change in order to determine 402 if the new path contains additional NSIS nodes that should have state 403 installed. GIST may use a range of triggers in order to detect a 404 route change. It probes periodically for the next peer by sending a 405 GIST Query, thereby detecting a changed route and GIST peer. GIST 406 monitors routing tables, the GIST peer states, and notifies NSLPs of 407 any routing changes. It is then up to the NSLPs to act 408 appropriately, if needed, e.g., by issuing a refresh message. The 409 periodic queries also serve to maintain the soft-state in nodes as 410 long as the route is unchanged. 412 In summary, GIST provides several services in one package to the 413 upper layer signaling protocols: 415 o Signaling peer discovery: GIST is able to find the next hop node 416 that runs the NSLP being signaled for. 417 o Multiplexing: GIST reuses already established signaling 418 relationships and messaging associations to next hop peers if the 419 signaling flows require the same transport attributes. 420 o Transport: GIST provides transport with different attributes, 421 namely reliable/unreliable and secure/unsecure. 422 o Confidentiality: If security is requested, GIST uses TLS to 423 provide an encrypted and integrity protected message transport to 424 the next signaling peer. 425 o Routing changes: GIST detects routing changes, but instead of 426 acting on its own, it merely sends a notification to the local 427 NSLP. It is then up to the NSLP to act. 428 o Fragmentation: GIST uses either a known Path MTU for the next hop 429 or limits its message size to 576 bytes when using UDP, and 430 especially for Query mode messages. If fragmentation is required 431 it automatically establishes an MA and sends the signaling traffic 432 over a reliable protocol, e.g., TCP. 433 o State maintenance: GIST establishes and then maintains the soft- 434 state that controls communications through MAs between GIST peers 435 along the signaling path, according to usage parameters supplied 436 by NSLPs and local policies. 438 4. Quality of Service NSLP 440 The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) 441 establishes and maintains state at nodes along the path of a data 442 flow for the purpose of providing some forwarding resources for that 443 flow. It is intended to satisfy the QoS-related requirements of RFC 444 3726 [RFC3726]. No support for QoS architectures based on bandwidth 445 brokers or other off-path resource managers is currently included. 447 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 448 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 449 primary state management mechanism (i.e., state installation/refresh 450 is performed between pairs of adjacent NSLP nodes, rather than in an 451 end-to-end fashion along the complete signaling path). The QoS NSLP 452 extends the set of reservation mechanisms to meet the requirements of 453 RFC 3726 [RFC3726], in particular support of sender or receiver- 454 initiated reservations, as well as, a type of bi-directional 455 reservation and support of reservations between arbitrary nodes, 456 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 457 currently no support for IP multicast. 459 A distinction is made between the operation of the signaling protocol 460 and the information required for the operation of the Resource 461 Management Function (RMF). RMF-related information is carried in the 462 QSpec (QoS Specification) object in QoS NSLP messages. This is 463 similar to the decoupling between RSVP and the IntServ architecture, 464 RFC 1633 [RFC1633]. The QSpec carries information on resources 465 available, resources required, traffic descriptions and other 466 information required by the RMF. A template for QSpec objects is 467 defined in [I-D.ietf-nsis-qspec]. This provides a number of basic 468 parameter objects that can be used as a common language to specify 469 components of concrete QoS models. The objects defined in 470 [I-D.ietf-nsis-qspec] provide the building blocks for many existing 471 QoS models such as those associated with RSVP and Differentiated 472 Services. The extensibility of the template allows new QoS model 473 specifications to extend the template language as necessary to 474 support these specifications. 476 The QoS NSLP supports different QoS models, because it does not 477 define the QoS mechanisms and RMF that have to be used in a domain. 478 As long as a domain knows how to perform admission control for a 479 given QSpec, QoS NSLP actually does not care how the specified 480 constraints are enforced and met, e.g., by putting the related data 481 flow in the topmost of four DiffServ classes, or by putting it into 482 the third highest of twelve DiffServ classes. The particular QoS 483 configuration used is up to the network provider of the domain. The 484 QSpec can be seen as a common language to express QoS requirements 485 between different domains and QoS models. 487 In short, the functionality of the QoS NSLP includes: 488 o Conveying resource requests for unicast flows 489 o Resource requests (QSpec) that are decoupled from the signaling 490 protocol (QoS NSLP) 491 o Sender- and receiver-initiated reservations, as well as, bi- 492 directional 494 o Soft-state and reduced refresh (keep-alive) signaling 495 o Session binding, session X can be valid only if session Y is also 496 valid 497 o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy 498 mode) 499 o Protection against message re-ordering and duplication 500 o Group tear, tearing down several session with a single message 501 o Support for re-routing, e.g., due to mobility 502 o Support for request priorities and preemption 503 o Stateful and stateless nodes: stateless operation is particularly 504 relevant in core networks where large amounts of QoS state could 505 easily overwhelm a node 506 o Reservation aggregation 508 The protocol also provides for a proxy mode to allow the QoS 509 signaling to be implemented without needing all end hosts to be 510 capable of handling NSIS signaling. 512 The QSpec Template supports situations where the QoS parameters need 513 to be fine-grained, specifically targeted to an individual flow in 514 one part of the network (typically the edge or access part) but might 515 need to be more coarse-grained, where the flow is part of an 516 aggregate (typically in the core of the network). 518 5. NAT/Firewall Traversal NSLP 520 The NAT/Firewall Traversal NSLP [I-D.ietf-nsis-nslp-natfw] lets end- 521 hosts interact with NAT and firewall devices in the data path. 522 Basically it allows for a dynamic configuration of NATs and/or 523 firewalls along the data path in order to enable data flows to 524 traverse these devices without being obstructed. For instance, 525 firewall pinholes could be opened on demand by authorized hosts. 526 Furthermore, it is possible to block unwanted incoming traffic on 527 demand, e.g., if an end-host is under attack. 529 Configurations to be implemented in NAT and firewall devices signaled 530 by the NAT/Firewall NSLP take the form of a (Pattern, Action) pair, 531 where the pattern specifies a template for packet header fields to be 532 matched. The device is then expected to apply the specified action 533 to any passing packet that matches the template. Actions are 534 currently limited to ALLOW (forward the packet) and DENY (drop the 535 packet). The template specification allows for a greater range of 536 packet fields to be matched than those allowed for in the GIST MRI. 538 Basically NAT/Firewall signaling starts at the data sender (NSIS 539 Initiator) before any actual application data packets are sent. 540 Signaling messages may pass several NAT/Firewall NSLP-aware 541 middleboxes (NSIS Forwarder) on their way downstream and usually hit 542 the receiver (being the NSIS Responder). A proxy mode is also 543 available for cases where the NAT/Firewall NSLP is not fully 544 supported along the complete data path. NAT/Firewall NSLP is based 545 on a soft-state concept, i.e., the sender must periodically repeat 546 its request in order to keep it active. 548 Additionally, the protocol also provides functions for receivers 549 behind NATs. The receiver may request an external address that is 550 reachable from outside. The reserved external address must, however, 551 be communicated to the sender out-of-band by other means, e.g., by 552 application level signaling. After this step the data sender may 553 initiate a normal NAT/Firewall signaling in order to create firewall 554 pinholes. 556 The protocol also provides for a proxy mode to allow the NAT/Firewall 557 signaling to be implemented without needing all end hosts to be 558 capable of handling NSIS signaling. 560 6. Deploying the Protocols 562 The initial version of the NSIS protocol suite is being published 563 with the status of Experimental Protocols in order to gain deployment 564 experience. Concerns over the security, implementation and 565 administrative issues surrounding the use of RAO are likely to mean 566 that initial deployments occur in 'walled gardens' where the 567 characteristics of hardware in use are well known and there is a high 568 level of trust and control over the end nodes that use the protocols. 569 This section addresses issues that need to be considered in a 570 deployment of the NSIS protocol suite. 572 First of all, NSIS implementations must be available in at least some 573 of the corresponding network nodes (i.e., routers, firewalls, or NAT 574 gateways) and end-hosts. That means not only GIST support, but also 575 the NSLPs and their respective control functions (such as a resource 576 management function for QoS admission control etc.) must be 577 implemented. NSIS is capable of incremental deployment and an 578 initial deployment does not need to involve every node in a network 579 domain. This is discussed further in Section 6.3. There are a 580 number of obstacles that may be encountered due to broken 581 implementations of RAO (see Section 6.1) and firewalls or NATs 582 dropping NSIS signaling packets (see Section 6.2). 584 Another important issue is that applications may need to be made 585 NSIS-aware, thereby requiring some effort on the applications 586 programmer's behalf. Alternatively, it may be possible to implement 587 separate applications to control, e.g., the network QoS requests or 588 firewall pinholes, without needing to update the actual applications 589 that will take advantage of NSIS capabilities. 591 6.1. Deployment Issues Due to Use of RAO 593 The standardized version of GIST depends on routers and other 594 middleboxes correctly recognizing and acting on packets containing 595 RAO. There are a number of problems related to RAO that can obstruct 596 a deployment of NSIS: 597 o Some implementations do not respond to RAO at all. 598 o Some implementations respond but do not distinguish between the 599 RAO parameter values in IP version 4 (IPv4) packets or reject 600 anything except 0 (in which case only the value 0 can be used) 601 o The response to RAO in a GIST Query mode packet, which is sent 602 using the UDP transport, is to dispatch the packet to the UDP 603 stack in the intercepting node rather than a function associated 604 with the RAO parameter. Since the node will not normally have a 605 normal UDP receiver for these packets they are dropped 606 o The major security concern with RAO in NSIS is that it provides a 607 new vector for hosts to mount a (Distributed) Denial of Service 608 (DDOS) attack on the control plane of routers on the data path. 609 Such attacks have occurred and it is therefore normal for service 610 providers to prohibit "host-to-router" signaling packets such as 611 RSVP or NSIS from entering their networks from customer networks. 612 This will tend to limit the deployment of NSIS to "walled gardens" 613 unless a suitable mitigation of the DDOS threat can be found and 614 deployed. 616 In order to deploy NSIS effectively routers and other hardware needs 617 to be selected and correctly configured to respond to RAO and 618 dispatch intercepted packets to the NSIS function. 620 A further obstacle results from likelihood that IPv4 packets with IP 621 options of any kind will be filtered and dropped by firewalls and 622 NATs. In many cases this is the default behavior so that explicit 623 configuration is needed to allow packets carrying the RAO to pass 624 through. The general inclination of domain administrators is to deny 625 access to packets carrying IP options because of the security risks 626 and the additional load on the routers in the domain. The situation 627 with IPv6 may be easier as the RAO option in IPv6 is better defined 628 but the security concerns remain. 630 Deployment issues are discussed at more length in Appendix C of the 631 GIST specification [I-D.ietf-nsis-ntlp]. 633 6.2. Deployment Issues with NATs and Firewalls 635 NAT gateways and firewalls may also hinder initial deployment of NSIS 636 protocols for several reasons: 637 o They may filter and drop signaling traffic as described in 638 Section 6.1 to deny access to packets containing IP options. 639 o They may not permit "unsolicited" incoming GIST Query mode 640 packets. This behavior has been anticipated in the design of the 641 protocols but requires additional support to ensure that the 642 middleboxes are primed to accept the incoming queries (see 643 [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-nslp-natfw]). 644 o NATs that are not aware of the NSIS protocols will generally 645 perform address translations that are not coordinated with the 646 NSIS protocols. Since NSIS signaling messages may be carrying 647 embedded IP addresses affected by these translations, it may not 648 be possible to operate NSIS through such legacy NATs. The 649 situation and workarounds are discussed in Section 7.2.1 of 650 [I-D.ietf-nsis-ntlp]. 652 6.3. Incremental Deployment and Workarounds 654 NSIS is specifically designed to be incrementally deployable. It is 655 not required that all nodes on the signaling and data path are NSIS 656 aware. To make any use of NSIS at least two nodes on the path need 657 to be NSIS aware. However, it is not essential that the initiator 658 and receiver of the data flow are NSIS aware. Both the QoS and NAT/ 659 Firewall NSLPs provide "proxy modes" in which nodes adjacent to the 660 initiator and/or receiver can act as proxy signaling initiator or 661 receiver. An initiator proxy can monitor traffic and, hopefully, 662 detect when a data flow of a type needing NSIS support is being 663 initiated. The proxies can act more or less transparently on behalf 664 of the data flow initiator and/or receiver to set up the required 665 NSIS state and maintain it while the data flow continues. This 666 capability reduces the immediate need to modify all the data flow end 667 points before NSIS is viable. 669 7. Security Features 671 Basic security functions are provided at the GIST layer, e.g., 672 protection against some blind or denial-of-service attacks, but note 673 that introduction of alternative MRMs may provide attack avenues that 674 are not present with the current emphasis on the path-coupled MRM. 675 Conceptually it is difficult to protect against on-path attacker and 676 man-in-the-middle attacks when using path-coupled MRMs, because a 677 basic functionality of GIST is to discover yet unknown signaling 678 peers. Transport security can be requested by signaling applications 679 and is realized by using TLS between signaling peers, i.e., 680 authenticity and confidentiality of signaling messages can be assured 681 between peers. GIST allows for mutual authentication of the 682 signaling peers (using TLS means like certificates) and can verify 683 the authenticated identity against a database of nodes authorized to 684 take part in GIST signaling. It is, however, a matter of policy that 685 the identity of peers is verified and accepted upon establishment of 686 the secure TLS connection. 688 While GIST is handling authentication of peer nodes, more fine 689 grained authorization may be required in the NSLP protocols. There 690 is currently an ongoing work to specify common authorization 691 mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], 692 thus allowing, e.g., per-user and per-service authorization. 694 8. Extending the Protocols 696 This section discusses the ways that are available to extend the NSIS 697 protocol suite. The Next Steps in Signaling (NSIS) Framework 698 [RFC4080] describes a two-layer framework for signaling on the 699 Internet, comprising a generic transport layer with specific 700 signaling layer protocols to address particular applications running 701 over this transport layer. The model is designed to be highly 702 extensible so that it can be adapted for different signaling needs. 704 It is expected that additional signaling requirements will be 705 identified in future. The two layer approach allows for NSLP 706 signaling applications to be developed independently of the transport 707 protocol. Further NSLPs can therefore be developed and deployed to 708 meet these new needs using the same GIST infrastructure thereby 709 providing a level of macro-extensibility. However, the GIST protocol 710 and the two signaling applications have been designed so that 711 additional capabilities can be incorporated into the design should 712 additional requirements within the general scope of these protocols 713 need to be accommodated. 715 The NSIS framework is also highly supportive of incremental 716 deployment. A new NSLP need not be available on every NSIS aware 717 node in a network or along a signaling path in order to start using 718 it. Nodes that do not (yet) support the application will forward its 719 signaling messages without complaint until it reaches a node where 720 the new NSLP application is deployed. 722 One key functionality of parameter objects carried in NSIS protocols 723 is the so-called "Extensibility flags (AB)". All the existing 724 protocols (and any future ones conforming to the standards) can carry 725 new experimental objects, where the AB-flags can indicate whether a 726 receiving node must interpret the object, or whether it can just drop 727 them or pass them along in subsequent messages sent out further on 728 the path. This functionality allows defining new objects without 729 forcing all network entities to understand them. 731 8.1. Overview of Administrative Actions Needed When Extending NSIS 733 Generally, NSIS protocols can be extended in multiple ways, many of 734 which require the allocation of unique code point values in 735 registries maintained by IANA on behalf of the IETF. This section is 736 an overview of the administrative mechanisms that might apply. The 737 extensibility rules are based upon the procedures by which IANA 738 assigns values: "Standards Action" (as defined in [RFC5226]), "IETF 739 Action", "Expert Review", and "Organization/Vendor Private", defined 740 below. The appropriate procedure for a particular type of code point 741 is defined in one or other of the NSIS protocol documents, mostly 742 [I-D.ietf-nsis-ntlp]. 744 In addition to registered code points, all NSIS protocols provide 745 code points that can be used for experimentation, usually within 746 closed networks, as explained in [RFC3692]. There is no guarantee 747 that independent experiments will not be using the same code point! 749 8.2. GIST 751 GIST is extensible in several aspects covered in the subsections 752 below. In these subsections, there are references to document 753 sections in the GIST specification [I-D.ietf-nsis-ntlp] where more 754 information can be found. The bullet points at the end of each 755 subsection specify the formal administrative actions that would need 756 to carried out when a new extension is standardized. 758 More generally, as asserted in Section 1 of the GIST specification, 759 the GIST design could be extended to cater for multicast flows and 760 for situations where the signaling is not tied to an end-to-end data 761 flow. However it is not clear whether this could be done in a 762 totally backwards compatible way, and is not considered within the 763 extensibility model of NSIS. 765 8.2.1. Use of Different Message Routing Methods 767 Currently only two message routing methods are supported (Path- 768 coupled MRM and Loose-End MRM), but further MRMs may be defined in 769 the future. See Sections 3.3 and 5.8 of the GIST specification 770 [I-D.ietf-nsis-ntlp]. One possible additional MRM under development 771 is documented in [I-D.bless-nsis-est-mrm]. This MRM would direct 772 signaling towards an explicit target address other than the (current) 773 data flow destination and is intended to assist setting up of state 774 on a new path during "make-before-break" handover sequences in mobile 775 operations. Note that alternative routing methods may require 776 modifications to the firewall traversal techniques used by GIST and 777 NSLPs. 779 o New MRMs require allocation of a new MRM-ID either by IETF review 780 of a specification or expert review [I-D.ietf-nsis-ntlp]. 782 8.2.2. Use of Different Transport Protocols or Security Capabilities 784 The initial handshake between GIST peers allows a negotiation of the 785 transport protocols to be used. Currently, proposals exist to add 786 the Datagram Congestion Control Protocol (DCCP) 787 [I-D.manner-nsis-gist-dccp] and the Stream Control Transport Protocol 788 (SCTP) [I-D.ietf-nsis-ntlp-sctp] transports to GIST, in each case 789 using Datagram TLS (DTLS) to provide security. See Sections 3.2 and 790 5.7 of the GIST specification [I-D.ietf-nsis-ntlp]. GIST expects 791 alternative capabilities to be treated as selection of an alternative 792 protocol stack. Within the protocol stack, the individual protocols 793 used are specified by MA Protocol IDs which are allocated from an 794 IANA registry if new protocols are to be used. See Sections 5.7 and 795 9 of the GIST specification [I-D.ietf-nsis-ntlp]. 797 o Use of an alternative transport protocol or security capability 798 requires allocation of a new MA-Protocol-ID either by IETF review 799 of a specification or expert review [I-D.ietf-nsis-ntlp]. 801 8.2.3. Use of Alternative Security Services 803 Currently only TLS is specified for providing secure channels with 804 MAs. Section 3.9 of the GIST specification 805 [I-D.ietf-nsis-ntlp]suggests that alternative protocols could be 806 used, but the interactions with GIST functions would need to be 807 carefully specified. See also Section 4.4.2 of the GIST 808 specification [I-D.ietf-nsis-ntlp]. 810 o Use of an alternative security service requires allocation of a 811 new MA-Protocol-ID either by IETF review of a specification or 812 expert review [I-D.ietf-nsis-ntlp]. 814 8.2.4. Query Mode Packet Interception Schemes 816 GIST has standardized a scheme using RAO 817 mechanisms[I-D.hancock-nsis-gist-rao] with UDP packets. If the 818 difficulties of deploying the RAO scheme prove insuperable in 819 particular circumstances, alternative interception schemes can be 820 specified. One proposal that was explored for GIST used UDP port 821 recognition in routers rather than RAO mechanisms to drive the 822 interception of packets. See Section 5.3.2 of the GIST specification 824 [I-D.ietf-nsis-ntlp]. Each NSLP needs to specify membership of an 825 "interception class" whenever it sends a message through GIST. A 826 packet interception scheme can support one or more interception 827 classes. In principle, a GIST instance can support multiple packet 828 interception schemes, but each interception class needs to be 829 associated with exactly one interception scheme in a GIST instance 830 and GIST instances that use different packet interception schemes for 831 the same interception class will not be interoperable. 833 Defining an alternative interception class mechanism for 834 incorporation into GIST should be considered as a very radical step 835 and all alternatives should be considered before taking this path. 836 The main reason for this is that the mechanism will necessarily 837 require additional operations on every packet passing through the 838 affected router interfaces. A number of considerations should be 839 taken into account: 840 o Although the interception mechanism need only be deployed on 841 routers that actually need it (probably for a new NSLP), 842 deployment may be constrained if the mechanism requires 843 modification to the hardware of relevant routers and/or needs to 844 await modification of the software by the router vendor. 845 o Any packet fields to be examined should be normally close to the 846 start of the packet so that additional memory accesses are not 847 needed to retrieve the values needed for examination. 848 o The logic required to determine if a packet should be intercepted 849 needs to be kept simple to minimise the extra per-packet 850 processing. 851 o The mechanism should be applicable to both IPv4 and IPv6 packets. 852 o Packet interception mechanisms potentially provide an attack path 853 for Denial of Service attacks on routers, in that packets are 854 diverted into the "slow path" and hence can significantly increase 855 the load on the general processing capability of the router. Any 856 new interception mechanism needs to be carefully designed to 857 minimize the attack surface. 859 Packet interception mechanisms are identified by an "interception 860 class" which is supplied to GIST through the Application Programming 861 Interface for each message sent. 863 o New packet interception mechanisms will generally require 864 allocation of one or more new Interception-class-IDs. This does 865 not necessarily need to be placed in an IANA registry as it is 866 primarily used as a parameter in the API between the NSLPs and 867 GIST and may never appear on the wire, depending on the mechanism 868 employed; all that is required is consistent interpretation 869 between the NSLPs and GIST in each applicable node. However, if, 870 as is the case with the current RAO mechanism 871 [I-D.hancock-nsis-gist-rao], the scheme distinguishes between 872 multiple packet interception classes by a value carried on the 873 wire (different values of RAO parameter for the RAO mechanism in 874 GIST), an IANA registry may be required to provide a mapping 875 between interception classes and on-the-wire values as discussed 876 in Section 6 of [I-D.hancock-nsis-gist-rao]. 878 8.2.5. Use of Alternative NAT Traversal Mechanisms 880 The mechanisms proposed for both legacy NAT traversal (Section 7.2.1 881 of the GIST specification [I-D.ietf-nsis-ntlp]) and GIST-aware NAT 882 traversal (Section 7.2.2 of the GIST specification 883 [I-D.ietf-nsis-ntlp]) can be extended or replaced. As discussed 884 above, extension of NAT traversal may be needed if a new MRM is 885 deployed. Note that there is extensive discussion of NAT traversal 886 in the NAT/Firewall NSLP specification [I-D.ietf-nsis-nslp-natfw]. 888 8.2.6. Additional Error Identifiers 890 Making extensions to any of the above items may result in new error 891 modes having to be catered for. See Section 9 and Appendix A 892 Sections A.4.1 - A.4.3 of the GIST specification 893 [I-D.ietf-nsis-ntlp]. 895 o Additional error identifiers require allocation of new error 896 code(s) and/or subcode(s), and may also require allocation of 897 Additional Information types. These are all allocated on a first- 898 come, first-served basis by IANA [I-D.ietf-nsis-ntlp]. 900 8.2.7. Defining New Objects to be Carried in GIST 902 The AB-flags in each signaling object carried in NSIS protocols 903 enable the community to specify new objects applicable to GIST, that 904 can be carried inside a signaling session without breaking existing 905 implementations. The AB-flags can also be used to indicate in a 906 controlled fashion that a certain object must be understood by all 907 GIST nodes, which makes it possible to probe for the support of an 908 extension. One such object already designed is the "Peering 909 Information Object (PIO)" [I-D.manner-nsis-peering-data] that allows 910 a QUERY message to carry additional peering data for the recipient 911 for making the peering decision. 913 o New objects require allocation of a new Object Type ID either by 914 IETF review of a specification or through another acceptable 915 published specification [I-D.ietf-nsis-ntlp]. 917 8.2.8. Adding New Message Types 919 Major modifications could be made by adding additional GIST message 920 types and defining appropriate processing. It might be necessary to 921 define this as a new version of the protocol. A field is provided in 922 the GIST Common Header containing the version number. GIST currently 923 has no provision for version or capability negotiation that might be 924 needed if a new version was defined. 926 o New GIST Message Types require allocation of a new GIST Message 927 Type ID either by IETF review of a specification or expert review 928 [I-D.ietf-nsis-ntlp]. 930 8.3. QoS NSLP 932 The QoS NSLP provides signaling for QoS reservations on the Internet. 933 The QoS NSLP decouples the resource reservation model or architecture 934 (QoS model) from the signaling. The signaling protocol is defined in 935 Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp]. The QoS 936 models are defined in separate specifications and the QoS NSLP can 937 operate with one or more of these models as required by the 938 environment where it is used. It is anticipated that additional QoS 939 models will be developed to address various Internet scenarios in the 940 future. Extensibility of QoS models is considered in Section 8.4. 942 The QoS NSLP specifically mentions the possibility of using 943 alternative Message Routing Methods (MRMs), apart from the general 944 ability to extend NSLPs using new objects with the standard "AB" 945 extensibility flags to allow them to be used in new and old 946 implementations. 948 There is already work to extend the base QoS NSLP and GIST to enable 949 new QoS signaling scenarios. One such proposal is the Inter-Domain 950 Reservation Aggregation aiming to support large-scale deployment of 951 the QoS NSLP [I-D.bless-nsis-resv-aggr]. Another current proposal 952 seeks to extend the whole NSIS framework towards path-decoupled 953 signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. 955 8.4. QoS Specifications 957 The QoS Specification template (QSpec) is defined in 958 [I-D.ietf-nsis-qspec]. This provides the language in which the 959 requirements of specific QoS models are described. Introduction of a 960 new QoS model involves defining a new QSpec. In order to have a new 961 QSpec allocated by IANA there must an acceptable published 962 specification that defines the specific elements within the QSpec 963 used in the new model. See [I-D.ietf-nsis-qspec] for details. 965 The introduction of new QoS models is designed to enable deployment 966 of NSIS-based QoS control in specific scenarios. One such example is 967 the Integrated Services Controlled Load Service for NSIS 968 [I-D.kappler-nsis-qosmodel-controlledload]. 970 A key feature provided by defining the QSpec template is support of a 971 common language for describing QoS requirements and capabilities, 972 which can be reused by any QoS models intending to use the QoS NSLP 973 to signal their requirements for traffic flows. The commonality of 974 the QSpec parameters ensures a certain level of interoperability of 975 QoS models and reduces the demands on hardware that has to implement 976 the QoS control. Optional QSpec parameters support the extensibility 977 of the QoS NSLP to other QoS models in the future; new QSpec 978 parameters can be defined in the document that defines a new QoS 979 model. See Sections 4.4 and 7 of [I-D.ietf-nsis-qspec]. 981 The QSpec consists of a QSpec version number, QSpec objects plus 982 specification of processing and procedures that can be used to build 983 many QoS models. The definition of a QSpec can be revised without 984 necessarily changing the version if the changes are functionally 985 backwards compatible. If changes are made that are not backwards 986 compatible then a new QSpec version number has to be assigned. Note 987 that a new QSpec version number is not needed just because new 988 additional QSpec parameters are specified; new versions will be 989 needed only if the existing functionality is modified. The template 990 includes version negotiation procedures that allow the originator of 991 an NSLP message to retry with a lower QSpec version if the receiver 992 rejects a message because it does not support the QSpec version 993 signaled in the message. See Section 3.2 of [I-D.ietf-nsis-qspec]. 995 o Creation of a new, incompatible version of an existing QSpec 996 requires allocation of a new QSpec version number that is 997 documented in a permanent and readily available public 998 specification. See [I-D.ietf-nsis-qspec]. 1000 o Completely new QSpecs can also be created. Such new QSpecs 1001 require allocation of a QSpec type that is documented in a 1002 permanent and readily available public specification. Values are 1003 also available for local or experimental use during development. 1004 See [I-D.ietf-nsis-qspec]. 1006 o Additional QSpec procedures can be defined requiring allocation of 1007 a new QSpec procedure number that is documented in a permanent and 1008 readily available public specification. Values are also available 1009 for local or experimental use during development. See 1010 [I-D.ietf-nsis-qspec]. 1012 o Additional QSpec parameters and associated error codes can be 1013 defined requiring a permanent and readily available public 1014 specification document. Values are also available for local or 1015 experimental use during development. See [I-D.ietf-nsis-qspec]. 1017 8.5. NAT/Firewall NSLP 1019 The NAT/Firewall signaling can be extended broadly in the same way as 1020 the QoS NSLP by defining new parameters to be carried in NAT/Firewall 1021 NSLP messages. See Section 7 of [I-D.ietf-nsis-nslp-natfw]. No 1022 proposals currently exist to fulfill new use cases for the protocol. 1024 8.6. New NSLP Protocols 1026 Designing a new NSLP is both challenging and easy. 1028 New signaling applications with associated NSLPs can be defined to 1029 work in parallel or replace the applications already defined by the 1030 NSIS working group. Applications that fit into the NSIS framework 1031 will be expected to use GIST to provide transport of signaling 1032 messages and appropriate security facilities which relieves the 1033 application designer of many "lower level" problems. GIST provides 1034 many important functions through the API that it exposes to the 1035 signaling application layer code, and allows the signaling 1036 application programmer to offload, e.g., the channel security, 1037 transport characteristics and signaling node discovery to GIST. 1039 Yet, on the other hand, the signaling application designer must take 1040 into account that the network environment can be dynamic, both in 1041 terms of routing and node availability. The new NSLP designer must 1042 take into account at least the following issues: 1044 o Routing changes, e.g., due to mobility: GIST sends Network 1045 Notifications when something happens in the network, e.g., peers 1046 or routing paths change. All signaling applications must be able 1047 to handle these notifications and act appropriately. GIST does 1048 not include logic to figure out what the NSLP would want to do due 1049 to a certain network event. Therefore, GIST gives the 1050 notification to the application, and lets it make the right 1051 decision. 1053 o GIST indications: GIST will also send other notifications, e.g., 1054 if a signaling peer does not reply to refresh messages, or a 1055 certain NSLP message was not successfully delivered to the 1056 recipient. NSLP applications must also be able to handle these 1057 events. Appendix B in the GIST specification discusses the GIST- 1058 NSLP API and the various functionality required, but implementing 1059 this interface can be quite challenging; the multitude of 1060 asynchronous notifications that can arrive from GIST increases the 1061 implementation complexity of the NSLP. 1063 o Lifetime of the signaling flow: NSLPs should inform GIST when a 1064 flow is no longer needed using the SetStateLifetime primitive. 1065 This reduces bandwidth demands in the network. 1067 o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new 1068 NSLP needs to use a unique NSLPID to ensure that its messages are 1069 delivered to the correct application by GIST. A single NSLP could 1070 use multiple NSLPIDs, for example to distinguish different classes 1071 of signaling nodes that might handle different levels of 1072 aggregation of requests or alternative processing paths. Note 1073 that unlike GIST, the NSLPs do not provide a protocol versioning 1074 mechanism. If the new NSLP is an upgraded version of an existing 1075 NSLP, then it should be distinguished by a different NSLPID. 1077 * A new generally available NSLP requires IESG approval for the 1078 allocation of a new NSLP ID [I-D.ietf-nsis-ntlp] 1080 o Incremental deployment: It would generally be unrealistic to 1081 expect every node on the signaling path to have a new NSLP 1082 implemented immediately. New NSLPs need to allow for this. The 1083 QoS and NATFW NSLPs provide examples of techniques such as proxy 1084 modes that cater for cases where the data flow originator and/or 1085 receiver does not implement the NSLP. 1086 o Signaling Message Source IP Address: It is sometimes challenging 1087 for an NSLP originating a signaling message to determine the 1088 source IP address that should be used in the signaling messages, 1089 which may be different from the data flow source address used in 1090 the MRI. This challenge occurs either when a node has multiple 1091 interfaces or is acting as a proxy for the data flow originator 1092 (typically expected to occur during the introduction of NSIS when 1093 not all nodes are NSIS enabled). A proxy signaling flow 1094 originator generally needs to know and use the correct data flow 1095 source IP address at least initially. As discussed in Section 1096 5.8.1.2 of [I-D.ietf-nsis-ntlp], the signaling flow originator may 1097 choose to alter the source IP address after the initial Query 1098 message has established the flow path in order that ICMP messages 1099 are directed to the most appropriate node; in the proxy case, the 1100 data flow originator would be unaware of the signaling flow and 1101 ICMP messages relating to the signaling would be meaningless if 1102 passed on to the data flow originator. Hence it is essential that 1103 an NSLP is aware of the position and role of the node on which it 1104 is instantiated, and has means of determining the appropriate 1105 source address to be used and ensuring that this is used on 1106 signaling packets. 1108 o New MRMs: GIST currently defines two Message Routing Methods, and 1109 leave the door open for new ideas. Thus, it is possible that a 1110 new NSLP also requires a new MRM, path-decoupled routing being one 1111 example. 1113 o Cooperation with other NSLPs: Some applications might need 1114 resources from two or more different classes in order to operate 1115 successfully. The NSLPs managing these resources could operate 1116 cooperatively to ensure that such requests were coordinated to 1117 avoid wasting signaling bandwidth and prevent race conditions. 1119 It is essential that the security considerations of a new NSLP are 1120 carefully analyzed. NSIS NSLPs are deployed in routers as well as 1121 host systems; a poorly designed NSLP could therefore provide an 1122 attack vector for network resources as well as end systems. The NSLP 1123 must also support authorization of users and must allow the use of 1124 the GIST authentication and integrity protection mechanisms where 1125 users deem them to be necessary. 1127 The API between GIST and NSLPs (see Appendix B in 1128 [I-D.ietf-nsis-ntlp]) is very important to understand. The abstract 1129 design in the GIST specification does not specify the exact messaging 1130 between GIST and the NSLPs but gives an understanding of the 1131 interactions, especially what kinds of asynchronous notifications 1132 from GIST the NSLP must be prepared to handle: the actual interface 1133 will be dependent on each implementation of GIST. 1135 Messages transmitted by GIST on behalf of an NSLP are identified by a 1136 unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers 1137 taken from a registry managed by IANA and defined in Section 9 of the 1138 GIST specification [I-D.ietf-nsis-ntlp]. 1140 A range of values (32704-32767) is available for Private and 1141 Experimental use during development, but any new signaling 1142 application that expects to be deployed generally on the Internet 1143 needs to be defined either in a standards track RFC or, possibly, an 1144 experimental RFC. Such an RFC would request allocation of unique 1145 NSLPID value(s) from the IANA registry. There is additional 1146 discussion of NSLPIDs in Section 3.8 of the GIST specification. 1148 9. Security Considerations 1150 This document provides information to the community. It does not 1151 itself raise new security concerns. 1153 However, any extensions that are made to the NSIS protocol suite will 1154 need to be carefully assessed for any security implications. This is 1155 particularly important because NSIS messages are intended to be 1156 actively processed by NSIS-capable routers that they pass through, 1157 rather than simply forwarded as is the case with most IP packets. It 1158 is essential that extensions provide means to authorize usage of 1159 capabilities that might allocate resources and recommend the use of 1160 appropriate authentication and integrity protection measures in order 1161 to exclude or adequately mitigate any security issues that are 1162 identified. 1164 Authors of new extensions for NSIS should review the analysis of 1165 security threats to NSIS documented in [RFC4081] as well as 1166 considering whether the new extension opens any new attack paths that 1167 need to mitigated. 1169 GIST offers facilities to authenticate NSIS messages and to ensure 1170 that they are delivered reliably. Extensions must allow these 1171 capabilities to be used in an appropriate manner to minimize the 1172 risks of NSIS messages being misused, and must recommend their 1173 appropriate usage. 1175 If additional transport protocols are proposed for use in association 1176 with GIST, an appropriate set of compatible security functions must 1177 be made available in conjunction with the transport protocol to 1178 support the authentication and integrity functions expected to be 1179 available through GIST. 1181 10. IANA Considerations 1183 This memo includes no request to IANA. 1185 11. Acknowledgements 1187 This document combines work previously published as two separate 1188 drafts: "What is Next Steps in Signaling anyway - A User's Guide to 1189 the NSIS Protocol Family" written by Roland Bless and Jukka Manner, 1190 and "NSIS Extensibility Model" written by John Loughney. 1192 Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of 1193 "User's Guide" draft and valuable input. Teemu Huovila also provided 1194 valuable input on the later versions. 1196 The "Extensibility Model" borrowed some ideas and some text from 1197 RFC3936 [RFC3936], Procedures for Modifying the Resource ReSerVation 1198 Protocol (RSVP); Robert Hancock provided text for the original GIST 1199 section, since much modified and Claudia Keppler have provided 1200 feedback on this draft, while Allison Mankin and Bob Braden suggested 1201 that this draft be worked on. 1203 12. References 1205 12.1. Normative References 1207 [I-D.ietf-nsis-nslp-natfw] 1208 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1209 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1210 draft-ietf-nsis-nslp-natfw-24 (work in progress), 1211 April 2010. 1213 [I-D.ietf-nsis-ntlp] 1214 Schulzrinne, H. and M. Stiemerling, "GIST: General 1215 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1216 (work in progress), June 2009. 1218 [I-D.ietf-nsis-qos-nslp] 1219 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1220 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1221 (work in progress), January 2010. 1223 [I-D.ietf-nsis-qspec] 1224 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 1225 QSPEC Template", draft-ietf-nsis-qspec-21 (work in 1226 progress), November 2008. 1228 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 1229 RFC 3726, April 2004. 1231 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1232 Bosch, "Next Steps in Signaling (NSIS): Framework", 1233 RFC 4080, June 2005. 1235 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1236 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1240 May 2008. 1242 12.2. Informative References 1244 [I-D.bless-nsis-est-mrm] 1245 Bless, R., "An Explicit Signaling Target Message Routing 1246 Method (EST-MRM) for the General Internet Signaling 1247 Transport (GIST) Protocol", draft-bless-nsis-est-mrm-01 1248 (work in progress), July 2008. 1250 [I-D.bless-nsis-resv-aggr] 1251 Doll, M. and R. Bless, "Inter-Domain Reservation 1252 Aggregation for QoS NSLP", draft-bless-nsis-resv-aggr-01 1253 (work in progress), July 2007. 1255 [I-D.braden-2level-signal-arch] 1256 Braden, R. and B. Lindell, "A Two-Level Architecture for 1257 Internet Signaling", draft-braden-2level-signal-arch-01 1258 (work in progress), November 2002. 1260 [I-D.cordeiro-nsis-hypath] 1261 Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., 1262 Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST 1263 Extension for Hybrid On-path Off-path Signaling (HyPath)", 1264 draft-cordeiro-nsis-hypath-05 (work in progress), 1265 February 2008. 1267 [I-D.hancock-nsis-gist-rao] 1268 Hancock, R., "Using the Router Alert Option for Packet 1269 Interception in GIST", draft-hancock-nsis-gist-rao-00 1270 (work in progress), November 2008. 1272 [I-D.ietf-nsis-ntlp-sctp] 1273 Fu, X., Dickmann, C., and J. Crowcroft, "General Internet 1274 Signaling Transport (GIST) over SCTP and Datagram TLS", 1275 draft-ietf-nsis-ntlp-sctp-09 (work in progress), 1276 February 2010. 1278 [I-D.kappler-nsis-qosmodel-controlledload] 1279 Kappler, C., Fu, X., and B. Schloer, "A QoS Model for 1280 Signaling IntServ Controlled-Load Service with NSIS", 1281 draft-kappler-nsis-qosmodel-controlledload-11 (work in 1282 progress), April 2010. 1284 [I-D.manner-nsis-gist-dccp] 1285 Manner, J., "Generic Internet Signaling Transport over 1286 DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in 1287 progress), June 2007. 1289 [I-D.manner-nsis-nslp-auth] 1290 Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 1291 "Authorization for NSIS Signaling Layer Protocols", 1292 draft-manner-nsis-nslp-auth-04 (work in progress), 1293 July 2008. 1295 [I-D.manner-nsis-peering-data] 1296 Manner, J., Liuhto, L., Varis, N., and T. Huovila, 1297 "Peering Data for NSIS Signaling Layer Protocols", 1298 draft-manner-nsis-peering-data-01 (work in progress), 1299 February 2008. 1301 [I-D.rahman-rtg-router-alert-dangerous] 1302 Rahman, R. and D. Ward, "Use of IP Router Alert Considered 1303 Dangerous", draft-rahman-rtg-router-alert-dangerous-00 1304 (work in progress), October 2008. 1306 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1307 Services in the Internet Architecture: an Overview", 1308 RFC 1633, June 1994. 1310 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1311 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1312 Functional Specification", RFC 2205, September 1997. 1314 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1315 Considered Useful", BCP 82, RFC 3692, January 2004. 1317 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1318 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1319 October 2004. 1321 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 1322 Service Signaling Protocols", RFC 4094, May 2005. 1324 Authors' Addresses 1326 Jukka Manner 1327 Helsinki University of Technology (TKK) 1328 P.O. Box 3000 1329 Espoo FIN-02015 TKK 1330 Finland 1332 Phone: +358 9 451 2481 1333 Email: jukka.manner@tkk.fi 1334 URI: http://www.netlab.tkk.fi/~jmanner/ 1335 Roland Bless 1336 Institute of Telematics, Karlsruhe Institute of Technology (KIT) 1337 Zirkel 2, Building 20.20 1338 Karlsruhe 76131 1339 Germany 1341 Phone: +49 721 608 6413 1342 Email: bless@kit.edu 1343 URI: http://tm.kit.edu/~bless 1345 John Loughney 1346 Nokia 1347 955 Page Mill Road 1348 Palo Alto 94303 1349 USA 1351 Phone: +1 650 283 8068 1352 Email: john.loughney@nokia.com 1354 Elwyn Davies (editor) 1355 Folly Consulting 1356 Soham, 1357 UK 1359 Email: elwynd@folly.org.uk 1360 URI: http://www.folly.org.uk