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