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