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