idnits 2.17.1 draft-ietf-nsis-ext-02.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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document 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 (March 9, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IANA' is mentioned on line 646, but not defined == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-20 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-17 == 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 == Outdated reference: A later version (-02) exists of draft-bless-nsis-est-mrm-01 == Outdated reference: A later version (-14) exists of draft-kappler-nsis-qosmodel-controlledload-08 Summary: 1 error (**), 0 flaws (~~), 10 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 10, 2009 Univ. of Karlsruhe 6 J. Loughney 7 Nokia 8 E B. Davies, Ed. 9 Folly Consulting 10 March 9, 2009 12 Using and Extending the NSIS Protocol Family 13 draft-ietf-nsis-ext-02.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 September 10, 2009. 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 and History . . . . . . . . . . . . . . . . . . . 4 70 2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 4 71 3. The General Internet Signaling Transport . . . . . . . . . . . 6 72 4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 10 73 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 12 74 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 13 75 6.1. Obstacles . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.2. Incremental Deployment and Workarounds . . . . . . . . . . 13 77 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 14 78 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 14 79 8.1. Overview of Administrative Actions Needed When 80 Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 15 81 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 19 84 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 20 85 8.6. New NSLP protocols . . . . . . . . . . . . . . . . . . . . 20 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 94 1. Introduction and History 96 The Transport Area Directors held a Next Steps in Signaling (NSIS) 97 birds of a feather session on Wednesday 21st March 2001 at the 50th 98 IETF meeting in Minneapolis. The goal of the session was to discuss 99 and gather an initial set of requirements for a next generation 100 Internet signaling protocol suite as it was felt that the current 101 RSVP-based solutions have short-comings, e.g., with respect to 102 mobility or QoS interoperability. The NSIS Working Group was 103 officially formed later that year, in November 2001 and had its first 104 meeting at the IETF 52 in Salt Lake City in December 2001. 106 The initial charter of NSIS was focused on QoS signaling as the first 107 use case, taking the Resource ReSerVation Protocol (RSVP) as the 108 background for the work. In May 2003, middlebox traversal was added 109 as an explicit second use case. The requirements for the new 110 generation of signaling protocols are documented in [RFC3726] and an 111 analysis of existing signaling protocols can be found in [RFC4094]. 113 The design of NSIS is based on a two-layer model, where a general 114 signaling transport layer provides services to an upper signaling 115 layer. The design was influenced by Bob Braden's Internet Draft 116 entitled "A Two-Level Architecture for Internet Signaling" 117 [I-D.braden-2level-signal-arch]. 119 This document gives an overview of what the NSIS framework and 120 protocol suite is at the time of writing (2008), provides help and 121 guidelines to the reader as to how NSIS can be used in an IP network, 122 and how 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 suite supports both IP 136 protocol versions, IPv4 and IPv6. 138 The actual signaling application logic is implemented in the higher 139 layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). 140 While GIST is only concerned with transporting NSLP messages hop-by- 141 hop between pairs of signalling nodes, the end-to-end signaling 142 functionality is provided by the NSLP protocols if needed - not all 143 NSLP protocols need to perform end-to-end signaling, even the current 144 protocols have features to confine the signaling to a limited path. 145 Messages transmitted by GIST on behalf of an NSLP are identified by a 146 unique NSLP identifier (NSLPID) associated with the NSLP. Two NSLP 147 protocols are currently standardized: one concerning Quality of 148 Service signaling and one to enable NAT/Firewall traversal. 150 NSIS is primarily designed to provide the signaling needed to install 151 state on nodes that lie on the path that will be taken by some end- 152 to-end flow of data packets in order to facilitate or enhance some 153 characteristic of the data flow. This is achieved by routing 154 signaling messages along the same path (known as "path-coupled 155 signaling") and intercepting the signaling message at NSIS capable 156 nodes. Parameters carried by the signaling message drive the 157 operation of the relevant transport or signaling application. In 158 particular, the messages will carry Message Routing Information (MRI) 159 that will allow the NSIS nodes to identify the data flow to which the 160 signaling applies. Generally, the intercepted messages will be 161 reinjected into the network after processing by the NSIS entities and 162 routed further towards the destination, possibly being intercepted by 163 additional NSIS nodes before arriving at the flow endpoint. 165 As with RSVP, it is expected that the signaling message will make a 166 complete round trip either along the whole end-to-end path or a part 167 of it if the scope of the signaling is limited. This implements a 168 two-phase strategy in which capabilities are assessed and provisional 169 reservations are made on the outbound leg; these provisional 170 reservations are then confirmed and operational state installed on 171 the return leg. Unlike RSVP, signaling is normally initiated at the 172 source of the data flow making it easier to ensure that the signaling 173 follows the expected path of the data flow, but can also be receiver 174 initiated as in RSVP. 176 A central concept of NSIS is the Session Identifier (SID). Signaling 177 application states are indexed and referred to through the SID within 178 the NSLP layer. This decouples the state information from IP 179 addresses, allowing dynamic IP address changes for signaling flows, 180 e.g., due to mobility: changes in IP addresses do not force complete 181 tear down and re-initiation of a signaling application state, merely 182 an update of the state parameters in the NSLP(s), especially the MRI. 184 At the NTLP (GIST) layer the SID is not meaningful by itself, but is 185 rather used together with the NSLP identifier (NSLPID) and the 186 Message Routing Information (MRI). This 3-tuple is used by GIST to 187 index and manage the signaling flows. Changes of routing or dynamic 188 IP address changes, e.g., due to mobility, will require GIST to 189 modify the Messaging Associations (MAs) that are used to channel NSLP 190 messages between adjacent GIST peers in order to satisfy the NSLP MRI 191 for each SID. 193 The following design restrictions were imposed for the first phase of 194 the protocol suite. They may be lifted in future and new 195 functionality may be added into the protocols at some later stage. 197 o Initial focus on MRMs for path-coupled signaling: GIST transports 198 messages towards an identified unicast data flow destination based 199 on the signaling application request, and does not directly 200 support path-decoupled signaling, e.g., QoS signaling to a 201 bandwidth broker or other off-path resource manager. The 202 framework also supports a "Loose-End" message routing method used 203 to discover GIST nodes with particular properties in the direction 204 of a given address, for example the NAT/FW NSLP uses this method 205 to discover a NAT along the upstream data path. 206 o No multicast support: Introducing support for multicast was deemed 207 too much overhead, considering the currently limited support for 208 global IP multicast. Thus, the current GIST and the NSLP 209 specifications consider unicast flows only. 211 The key documents specifying the NSIS framework are: 213 o Requirements for Signaling Protocols [RFC3726] 214 o Next Steps in Signaling: Framework [RFC4080] 215 o Security Threats for NSIS [RFC4081] 217 The protocols making up the suite specified by the NSIS working group 218 are documented in: 219 o The General Internet Signaling Transport protocol 220 [I-D.ietf-nsis-ntlp] 221 o Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp] 222 o The QoS specification template [I-D.ietf-nsis-qspec] 223 o NAT/Firewall traversal NSLP [I-D.ietf-nsis-nslp-natfw] 224 The next three sections provide a brief survey of GIST, the QoS NSLP, 225 and the NAT/Firewall NSLP. 227 3. The General Internet Signaling Transport 229 The General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] 230 provides a signaling transport and security services to NSIS 231 Signaling Layer Protocols (NSLP) and the associated signaling 232 applications. GIST does not define new IP transport protocols or 233 security mechanisms but rather makes use of existing protocols, such 234 as TCP, UDP, TLS and IPsec. Applications can indicate the desired 235 reliability, e.g., unreliable or reliable, and GIST then uses the 236 most appropriate transport protocol to achieve the goal. If 237 applications request also security, GIST uses TLS. The GIST layered 238 protocol stack is shown in Figure 1. 240 +-----+ +--------+ +-------+ 241 | | | | | | 242 | QoS | | NAT/FW | | ... | NSLP 243 | | | | | | 244 +-----+ +--------+ +-------+ 246 ---------------------------------------------------------------------- 247 +--------------------------+ 248 | | 249 | GIST | NTLP 250 | | 251 +--------------------------+ 253 ---------------------------------------------------------------------- 254 +--------------------------+ 255 | TLS | 256 +--------------------------+ 257 +--------------------------+ 258 | TCP | UDP | SCTP | DCCP | 259 +--------------------------+ 260 +--------------------------+ 261 | IPsec | 262 +--------------------------+ 263 +--------------------------+ 264 | IPv4 | IPv6 | 265 +--------------------------+ 267 Figure 1: The NSIS protocol stack 269 GIST divides up the end-to-end path to be taken by the data flow into 270 a number of segments between pairs of NSIS aware peer nodes located 271 along the path. Not every router or other middlebox on the path 272 needs to be NSIS aware: each segment of the signaling path may 273 incorporate several routing hops. Also not every NSIS aware node 274 necessarily implements every possible signaling application. If the 275 signaling for a flow requests services from a subset of the 276 applications, then only nodes that implement those services are 277 expected to participate as peers, and even some of these nodes can 278 decline to operate on a particular flow if, for example, the 279 additional load might overload the processing capability of the node. 281 These characteristics mean that incremental deployment of NSIS 282 capabilities is possible both with the initial protocol suite, and 283 for any future NSLP applications that might be developed. The 284 following paragraphs describe how a signaling segment is setup 285 offering the transport and security characteristics needed by a 286 single NSLP. 288 When an NSLP application wants to send a message to its next peer, 289 GIST starts the process of discovering the next signaling node by 290 sending a Query message towards the destination of the related data 291 flow. This Query carries the NSLP identifier (NSLPID) and Message 292 Routing Information (MRI) among others. The MRI contains enough 293 information to control the routing of the signaling message and 294 identify the associated data flow. The next GIST node on the path 295 receives the message and if it is running the same NSLP, it provides 296 the MRI to the NSLP application and requests it to make a decision on 297 whether to peer with the querying node. If the NSLP application 298 chooses to peer, GIST sets up a Message Routing State (MRS) between 299 the two nodes for the future exchange of NSLP data. State setup is 300 performed by a three-way handshake that allows for negotiation of 301 signaling flow parameters and provides counter-measures against 302 several attacks like denial-of-service by using cookie mechanisms and 303 a late state installation option. 305 If a transport connection is required and needs to provide for 306 reliable or secure signaling, like TCP or TLS/TCP, a Messaging 307 Association (MA) is established between the two peers. An MA can be 308 re-used for signaling messages concerning several different data 309 flows, i.e., signaling messages between two nodes are multiplexed 310 over the same transport connection. This can be done when the 311 transport requirements (reliability, security) of a new flow can be 312 met with an existing MA, i.e., the security and transport properties 313 of an existing MA are equivalent or better than what is requested by 314 the new MA. 316 For path-coupled signaling, we need to find the nodes on the data 317 path that should take part in the signaling of an NSLP and invoke 318 them to act on the arrival of such NSLP signaling messages. The 319 basic concept is that such nodes along a flow's data path intercept 320 the corresponding signaling packets and are thus discovered 321 automatically. It was originally envisaged that GIST would place a 322 Router Alert Option (RAO) in Query message packets to ensure that 323 they are intercepted by NSIS aware nodes as in RSVP. 325 Late in the development of GIST serious concerns were raised in the 326 IETF about the security risks and performance implications of 327 extensive usage of the RAO [I-D.rahman-rtg-router-alert-dangerous], 328 as well as discovery of evidence that several existing 329 implementations of RAO were inconsistent with the standards and would 330 not support the NSIS usage. There were also concerns that extending 331 the need for RAO recognition in the fast path of routers that are 332 frequently implemented in hardware would delay or deter 333 implementation and deployment of NSIS. An alternative mechanism was 334 therefore standardized. 336 The approved version of GIST specifies that NSIS nodes recognise UDP 337 packets directed to a specific destination port and containing a GIST 338 specific "magic number" as the first 32 bits of the UDP payload as 339 Query messages that need to be intercepted. It is recognised that 340 this interception method is not the most efficient possible and GIST 341 provides for the use of alternatives, such as the RAO, for specific 342 NSLPs as a part of its extensibility design. Further intentional 343 bypassing of signaling nodes can be accomplished either in GIST or in 344 the NSLP. 346 Since GIST carries information about the data flow inside its 347 messages (in the MRI), NAT gateways must be aware of GIST in order to 348 let it work correctly. GIST provides a special object for NAT 349 traversal so that the actual translation is disclosed if a GIST-aware 350 NAT gateway provides this object. 352 As with RSVP, all the state installed by NSIS protocols is "soft- 353 state" that will expire and be automatically removed unless it is 354 periodically refreshed. NSIS state is held both at the signaling 355 application layer and in the transport layer, and is maintained 356 separately. NSLPs control the lifetime of the state in the 357 application layer by setting a timeout and sending periodic "keep 358 alive" messages along the signaling path if no other messages are 359 required. The MAs and the routing state are maintained semi- 360 independently by the transport layer, because MAs may be used by 361 multiple NSLP sessions, and can also be recreated "on demand" if the 362 node needs to reclaim resources. The transport layer can send its 363 own "keep alive" messages across a MA if no NSLP messages have been 364 sent, for example if the transport layer decides to maintain a 365 heavily used MA even though there is no current NSLP session using 366 it. State can also be deleted explicitly when no longer needed. 368 If there is a change in the route used by a flow for which NSIS has 369 created state, NSIS needs to detect the change in order to determine 370 if the new path contains additional NSIS nodes that should have state 371 installed. GIST may use a range of triggers in order to detect a 372 route change. It probes periodically for the next peer by sending a 373 GIST Query, thereby detecting a changed route and GIST peer. GIST 374 monitors routing tables, the GIST peer states, and notifies NSLPs of 375 any routing changes. It is then up to the NSLPs to act 376 appropriately, if needed, e.g., by issuing a refresh message. The 377 periodic queries also serve to maintain the soft-state in nodes as 378 long as the route is unchanged. 380 In summary, GIST provides several services in one package to the 381 upper layer signaling protocols: 383 o Signaling peer discovery: GIST is able to find the next hop node 384 that runs the NSLP being signaled for. 385 o Multiplexing: GIST reuses already established signaling 386 relationships and messaging associations to peers if the signaling 387 flows traverse the same next signaling hop. 388 o Transport: GIST provides transport with different attributes, 389 namely reliable/unreliable and secure/unsecure. 390 o Confidentiality: If security is requested, GIST uses TLS to 391 provide an encrypted and integrity protected message transport to 392 the next signaling peer. 393 o Routing changes: GIST detects routing changes, but instead of 394 acting on its own, it merely sends a notification to the local 395 NSLP. It is then up to the NSLP to act. 396 o Fragmentation: GIST uses either a known Path MTU for the next hop 397 or limits its message size to 576 bytes. If fragmentation is 398 required it automatically establishes an MA and sends the 399 signaling traffic over a reliable protocol, e.g., TCP. 400 o State maintenance: GIST establishes and then maintains the soft- 401 state that controls communications through MAs between GIST peers 402 along the signaling path, according to usage parameters supplied 403 by NSLPs and local policies. 405 4. Quality of Service NSLP 407 The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) 408 establishes and maintains state at nodes along the path of a data 409 flow for the purpose of providing some forwarding resources for that 410 flow. It is intended to satisfy the QoS-related requirements of RFC 411 3726 [RFC3726]. No support for QoS architectures based on bandwidth 412 brokers or other off-path resource managers is currently included. 414 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 415 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 416 primary state management mechanism (i.e., state installation/refresh 417 is performed between pairs of adjacent NSLP nodes, rather than in an 418 end-to-end fashion along the complete signaling path). The QoS NSLP 419 extends the set of reservation mechanisms to meet the requirements of 420 RFC 3726 [RFC3726], in particular support of sender or receiver- 421 initiated reservations, as well as, a type of bi-directional 422 reservation and support of reservations between arbitrary nodes, 423 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 424 currently no support for IP multicast. 426 A distinction is made between the operation of the signaling protocol 427 and the information required for the operation of the Resource 428 Management Function (RMF). RMF-related information is carried in the 429 QSpec (QoS Specification) object in QoS NSLP messages. This is 430 similar to the decoupling between RSVP and the IntServ architecture, 431 RFC 1633 [RFC1633]. The QSpec carries information on resources 432 available, resources required, traffic descriptions and other 433 information required by the RMF. A template for Qspec objects is 434 defined in [I-D.ietf-nsis-qspec]. This provides a number of basic 435 parameter objects that can be used as a common language to specify 436 components of concrete QoS models. The objects defined in 437 [I-D.ietf-nsis-qspec] provide the building blocks for many existing 438 QoS models such as those associated with RSVP and Differentiated 439 Services. The extensibility of the template allows new QoS model 440 specifications to extend the template language as necessary to 441 support these specifications. 443 The QoS NSLP supports different QoS models, because it does not 444 define the QoS mechanisms and RMF that have to be used in a domain. 445 As long as a domain knows how to perform admission control for a 446 given QSpec, QoS NSLP actually does not care how the specified 447 constraints are enforced and met, e.g., by putting the related data 448 flow in the topmost of four DiffServ classes, or by putting it into 449 the third highest of twelve DiffServ classes. The particular QoS 450 configuration used is up to the network provider of the domain. The 451 QSpec can be seen as a common language to express QoS requirements 452 between different domains and QoS models. 454 In short, the functionality of the QoS NSLP includes: 455 o Conveying resource requests for unicast flows 456 o Resource requests (QSpec) that are decoupled from the signaling 457 protocol (QoS NSLP) 458 o Sender- and receiver-initiated reservations, as well as, bi- 459 directional 460 o Soft-state and reduced refresh (keep-alive) signaling 461 o Session binding, session X can be valid only if session Y is too 462 o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy 463 mode) 464 o Protection against message re-ordering and duplication 465 o Group tear, tearing down several session with a single message 466 o Support for re-routing, e.g., due to mobility 467 o Support for request priorities and preemption 468 o Stateful and stateless nodes: stateless operation is particularly 469 relevant in core networks where large amounts of QoS state could 470 easily overwhelm a node 472 o Reservation aggregation 473 The protocol also provides for a proxy mode to allow the QoS 474 signaling to be implemented without needing all end hosts to be 475 capable of handling NSIS signaling. 477 The QSpec Template supports situations where the QoS parameters need 478 to be fine-grained, specifically targeted to an individual flow in 479 one part of the network (typically the edge or access part) but might 480 need to be more coarse-grained, where the flow is part of an 481 aggregate (typically in the core of the network). 483 5. NAT/Firewall Traversal NSLP 485 The NAT/Firewall Traversal NSLP [I-D.ietf-nsis-nslp-natfw] lets end- 486 hosts interact with NAT and firewall devices in the data path. 487 Basically it allows for a dynamic configuration of NATs and/or 488 firewalls along the data path in order to enable data flows to 489 traverse these devices without being obstructed. For instance, 490 firewall pinholes could be opened on demand by authorized hosts. 491 Furthermore, it is possible to block unwanted incoming traffic on 492 demand, e.g., if an end-host is under attack. 494 Configurations to be implemented in NAT and firewall devices 495 signalled by the NAT/Firewall NSLP take the form of a (Pattern, 496 Action) pair, where the pattern specifies a template for packet 497 header fields to be matched. The device is then expected to apply 498 the specified action to any passing packet that matches the template. 499 Actions are currently limited to ALLOW (forward the packet) and DENY 500 (drop the packet). The template specification allows for a greater 501 range of packet fields to be matched than those allowed for in the 502 GIST MRI. 504 Basically NAT/Firewall signaling starts at the data sender (NSIS 505 Initiator) before any actual application data packets are sent. 506 Signaling messages may pass several NAT/Firewall NSLP-aware 507 middleboxes (NSIS Forwarder) on their way downstream and usually hit 508 the receiver (being the NSIS Responder). A proxy mode is also 509 available for cases where the NAT/Firewall NSLP is not fully 510 supported along the complete data path. NAT/Firewall NSLP is based 511 on a soft-state concept, i.e., the sender must periodically repeat 512 its request in order to keep it active. 514 Additionally, the protocol also provides functions for receivers 515 behind NATs. The receiver may request an external address that is 516 reachable from outside. The reserved external address must, however, 517 be communicated to the sender out-of-band by other means, e.g., by 518 application level signaling. After this step the data sender may 519 initiate a normal NAT/Firewall signaling in order to create firewall 520 pinholes. 522 The protocol also provides for a proxy mode to allow the NAT/Firewall 523 signaling to be implemented without needing all end hosts to be 524 capable of handling NSIS signaling. 526 6. Deploying the Protocols 528 First of all, NSIS implementations must be available in at least some 529 of the corresponding network nodes (i.e., routers, firewalls, or NAT 530 gateways) and end-hosts. That means not only GIST support, but also 531 the NSLPs and their respective control functions (such as a resource 532 management function for QoS admission control etc.) must be 533 implemented. NSIS is capable of incremental deployment and an 534 initial deployment does not need to involve every node in a network 535 domain. This is discussed further in Section 6.2. 537 Another important issue is that applications may need to be made 538 NSIS-aware, thereby requiring some effort on the applications 539 programmer's behalf. Alternatively, it may be possible to implement 540 separate applications to control, e.g., the network QoS requests or 541 firewall pinholes, without needing to update the actual applications 542 that will take advantage of NSIS capabilities. 544 6.1. Obstacles 546 Although GIST is no longer dependent on RAO (there is known to be 547 network equipment with broken implementations of the RAO deployed), 548 if NSIS is to be deployed in routers with hardware-based forwarding 549 engines it is not guaranteed that the hardware will be able to divert 550 Query packets identified by a well-known UDP port into the slow path, 551 which will make deployment of NSIS dependent on hardware replacement 552 rather than software upgrade. However, the removal of dependence on 553 RAO makes it more likely that NSIS Query packets can be forwarded 554 through nodes that are not NSIS aware. 556 NAT gateways and firewalls may also hinder initial deployment of NSIS 557 protocols as they may either filter signaling traffic or perform 558 NSIS-unaware address translations. 560 6.2. Incremental Deployment and Workarounds 562 NSIS is specifically designed to be incrementally deployable. It is 563 not required that all nodes on the signaling and data path are NSIS 564 aware. To make any use of NSIS at least two nodes on the path need 565 to be NSIS aware. However, it is not essential that the initiator 566 and receiver of the data flow are NSIS aware. Both the QoS and NAT/ 567 Firewall NSLPs provide "proxy modes" in which nodes adjacent to the 568 initiator and/or receiver can act as proxy signaling initiator or 569 receiver. An initiator proxy can monitor traffic and, hopefully, 570 detect when a data flow of a type needing NSIS support is being 571 initiated. The proxies can act more or less transparently on behalf 572 of the data flow initiator and/or receiver to set up the required 573 NSIS state and maintain it while the data flow continues. This 574 capability reduces the immediate need to modify all the data flow end 575 points before NSIS is viable. 577 7. Security Features 579 Basic security functions are provided at the GIST layer, e.g., 580 protection against some blind or denial-of-service attacks, but note 581 that introduction of alternative MRMs may provide attack avenues that 582 are not present with the current emphasis on the path-coupled MRM. 583 Conceptually it is difficult to protect against on-path attacker and 584 man-in-the-middle attacks when using path-coupled MRMs, because a 585 basic functionality of GIST is to discover yet unknown signaling 586 peers. Transport security can be requested by signaling applications 587 and is realized by using TLS between signaling peers, i.e., 588 authenticity and confidentiality of signaling messages can be assured 589 between peers. GIST allows for mutual authentication of the 590 signaling peers (using TLS means like certificates) and can verify 591 the authenticated identity against a database of nodes authorized to 592 take part in GIST signaling. It is, however, a matter of policy that 593 the identity of peers is verified and accepted upon establishment of 594 the secure TLS connection. 596 While GIST is handling authentication of peer nodes, more fine 597 grained authorization may be required in the NSLP protocols. There 598 is currently an ongoing work to specify common authorization 599 mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], 600 thus allowing, e.g., per-user and per-service authorization. 602 8. Extending the Protocols 604 This section discusses the ways that are available to extend the NSIS 605 protocol suite. The Next Steps in Signaling (NSIS) Framework 606 [RFC4080] describes a two-layer framework for signaling on the 607 Internet, comprising a generic transport layer with specific 608 signaling layers to address particular applications running over this 609 transport layer. The model is designed to be highly extensible so 610 that it can be adapted for different signaling needs. 612 It is expected that additional signaling requirements will be 613 identified in future. The two layer approach allows for NSLP 614 signaling applications to be developed independently of the transport 615 protocol. Further NSLPs can therefore be developed and deployed to 616 meet these new needs using the same GIST infrastructure thereby 617 providing a level of macro-extensibility. However, the GIST protocol 618 and the two signaling applications have been designed so that 619 additional capabilities can be incorporated into the design should 620 additional requirements within the general scope of these protocols 621 need to be accommodated. 623 The NSIS framework is also highly supportive of incremental 624 deployment. A new NSLP need not be available on every NSIS aware 625 node in a network or along a signaling path in order to start using 626 it. Nodes that do not (yet) support the application will forward it 627 without complaint until it reaches a node where the new NSLP 628 application is deployed. 630 One key functionality of parameter objects carried in NSIS protocols 631 is the so-called "Extensibility flags (AB)". All the existing 632 protocols (and any future ones conforming to the standards) can carry 633 new experimental objects, where the AB-flags can indicate whether a 634 receiving node must interpret the object, or whether it can just drop 635 them or pass them along in subsequent messages sent out further on 636 the path. This functionality allows defining new objects without 637 forcing all network entities to understand them. 639 8.1. Overview of Administrative Actions Needed When Extending NSIS 641 Generally, NSIS protocols can be extended in multiple ways, many of 642 which require the allocation of unique code point values in 643 registries maintained by IANA on behalf of the IETF. This section is 644 an overview of the administrative mechanisms that might apply. The 645 extensibility rules are based upon the procedures by which IANA 646 assigns values: "Standards Action" (as defined in [IANA]), "IETF 647 Action", "Expert Review", and "Organization/Vendor Private", defined 648 below. The appropriate procedure for a particular type of code point 649 is defined in one or other of the NSIS protocol documents, mostly 650 [I-D.ietf-nsis-ntlp]. 652 In addition to registered code points, all NSIS protocols provide 653 code points that can be used for experimentation, usually within 654 closed networks, as explained in [RFC3692]. There is no guarantee 655 that independent experiments will not be using the same code point! 657 8.2. GIST 659 GIST is extensible in several aspects. In this list, references to 660 document sections refer to the GIST specification 661 [I-D.ietf-nsis-ntlp]. 662 o Use of different Message Routing Methods: currently only two 663 message routing methods are supported (Path-coupled MRM and Loose- 664 End MRM), but further MRMs may be defined in the future. See 665 Section 3.8. One possible additional MRM under development is 666 documented in [I-D.bless-nsis-est-mrm]. This MRM would direct 667 signaling towards an explicit target address other than the 668 (current) data flow destination and is intended to assist setting 669 up of state on a new path during 'make-before-break' handover 670 sequences in mobile operations. Note that alternative routing 671 methods may require modifications to the firewall traversal 672 techniques used by GIST and NSLPs. 673 * New MRMs require allocation of a new MRM-ID either by standards 674 action or expert review[I-D.ietf-nsis-ntlp]. 675 o Use of different transport protocols or security capabilities: the 676 initial handshake allows a negotiation of the transport protocols 677 to be used. Currently, a proposal to add DCCP and DTLS to GIST 678 exists [I-D.manner-nsis-gist-dccp]. See Sections 3.2 and 5.7. 679 GIST expects alternative capabilities to be treated as selection 680 of an alternative protocol stack. Within the protocol stack, the 681 individual protocols used are specified by MA Protocol IDs which 682 are allocated from an IANA registry if new protocols are to be 683 used. See Sections 5.7 and 9. 684 * Use of an alternative transport protocol or security capability 685 requires allocation of a new MA-Protocol-ID either by standards 686 action or expert review[I-D.ietf-nsis-ntlp]. 687 o Use of alternative security services: Currently only TLS is 688 specified for providing secure channels with MAs. Section 3.9 689 suggests that alternative protocols could be used, but the 690 interactions with GIST functions would need to be carefully 691 specified. See also Section 4.4.2. 692 * Use of an alternative security service requires allocation of a 693 new MA-Protocol-ID either by standards action or expert 694 review[I-D.ietf-nsis-ntlp]. 695 o Query mode packet interception schemes: GIST has standardized a 696 simple scheme using a well-known UDP port number plus a "magic 697 number" at the start of the UDP payload. Alternative schemes, 698 possibly including a reversion to the original proposal to use RAO 699 mechanisms[I-D.hancock-nsis-gist-rao], can be specified as 700 extensions. See Sections 5.3.2 and 5.3.2.5. Each NSLP needs to 701 specify membership of an "interception class" whenever it sends a 702 message through GIST. A packet interception scheme can support 703 one or more interception classes. In principle, a GIST instance 704 can support multiple packet interception schemes, but each 705 interception class needs to be associated with exactly one 706 interception scheme in a GIST instance and GIST instances that use 707 different packet interception schemes for the same interception 708 class will not be interoperable. 710 Defining an alternative interception class mechanism for 711 incorporation into GIST should be considered as a very radical 712 step and all alternatives should be considered before taking this 713 path. The main reason for this is that the mechanism will 714 necessarily require additional operations on every packet passing 715 through the affected router interfaces. A number of 716 considerations should be taken into account: 717 * Although the interception mechanism need only be deployed on 718 routers that actually need it (probably for a new NSLP), 719 deployment may be constrained if the mechanism requires 720 modification to the hardware of relevant routers and/or needs 721 to await modification of the software by the router vendor. 722 * Any packet fields to be examined should be normally close to 723 the start of the packet so that additional memory accesses are 724 not needed to retrieve the values needed for examination. 725 * The logic required to determine if a packet should be 726 intercepted needs to be kept simple to minimise the extra per- 727 packet processing. 728 * The mechanism should be applicable to both IPv4 and IPv6 729 packets. 730 * Packet interception mechanisms potentially provide an attack 731 path for Denial of Service attacks on routers, in that packets 732 are diverted into the "slow path" and hence can significantly 733 increase the load on the general processing capability of the 734 router. Any new interception mechanism needs to be carefully 735 designed to minimize the attack surface. 736 Packet interception mechanisms are identified by an "interception 737 class" which is supplied to GIST through the Application 738 Programming Interface for each message sent. 739 * New packet interception mechanisms will generally require 740 allocation of one or more new Interception-class-IDs. This 741 does not necessarily need to be placed in an IANA registry as 742 it is primarily used as a parameter in the API between the 743 NSLPs and GIST and may never appear on the wire, depending on 744 the mechanism employed; all that is required is consistent 745 interpretation between the NSLPs and GIST in each applicable 746 node. However, if, as is the case in the RAO proposal 747 [I-D.hancock-nsis-gist-rao], the scheme distinguishes between 748 multiple packet interception classes by a value carried on the 749 wire (different values of RAO parameter for the RAO proposal), 750 an IANA registry may be required to provide a mapping between 751 interception classes and on-the-wire values as discussed in 752 Section 6 of [I-D.hancock-nsis-gist-rao]. 754 o Use of alternative NAT traversal mechanisms: the mechanisms 755 proposed for both legacy NAT traversal (Section 7.2.1) and GIST- 756 aware NAT traversal (Section 7.2.2) can be extended or replaced. 757 As discussed above, extension of NAT traversal may be needed if a 758 new MRM is deployed. Note that there is extensive discussion of 759 NAT traversal in the NAT/Firewall NSLP specification 760 [I-D.ietf-nsis-nslp-natfw]. 761 o Additional error identifiers: Making extensions to any of the 762 above items may result in new error modes having to be catered 763 for. See Section 9 and Appendix A Sections A.4.1 - A.4.3. 764 * Additional error identifiers require allocation of new error 765 code(s) and/or subcode(s), and may also require allocation of 766 Additional Information types. These are all allocated on a 767 first-come, first-served basis by IANA [I-D.ietf-nsis-ntlp]. 768 o Generally: the AB-flags enable the community to specify new 769 objects applicable to GIST, that can be carried inside a signaling 770 session without breaking existing implementations. The AB-flags 771 can also be used to indicate in a controlled fashion that a 772 certain object must be understood by all GIST nodes, which makes 773 it possible to probe for the support of an extension. One such 774 object already designed is the "Peering Information Object (PIO)" 775 [I-D.manner-nsis-peering-data] that allows a QUERY message to 776 carry additional peering data for the recipient for making the 777 peering decision. 778 * New objects require allocation of a new Object Type ID either 779 by standards action or provision of another type of 780 specification [I-D.ietf-nsis-ntlp]. 781 o Major modifications could be made by adding additional GIST 782 message types and defining appropriate processing. It might be 783 necessary to define this as a new version of the protocol. A 784 field is provided in the GIST Common Header containing the version 785 number. GIST currently has no provision for version or capability 786 negotiation that might be needed if a new version was defined. 787 * New GIST Message Types require allocation of a new GIST Message 788 Type ID either by standards action or expert review 789 [I-D.ietf-nsis-ntlp]. 790 Finally, and more generally, as asserted in Section 1 of the GIST 791 specification, the GIST design could be extended to cater for 792 multicast flows and for situations where the signaling is not tied to 793 an end-to-end data flow, but it is not clear whether this could be 794 done in a totally backwards compatible way, and is not considered 795 within the extensibility model of NSIS. 797 8.3. QoS NSLP 799 The QoS NSLP provides signaling for QoS reservations on the Internet. 800 The QoS NSLP decouples the resource reservation model or architecture 801 (QoS model) from the signaling. The signaling protocol is defined in 802 Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp]. The QoS 803 models are defined in separate specifications and the QoS NSLP can 804 operate with one or more of these models as required by the 805 environment where it is used. It is anticipated that additional QoS 806 models will be developed to address various Internet scenarios in the 807 future. Extensibility of QoS models is considered in Section 8.4. 809 The QoS NSLP specifically mentions the possibility of using 810 alternative Message Routing Methods (MRMs), apart from the general 811 ability to extend NSLPs using new objects with the standard "AB" 812 extensibility flags to allow them to be used in new and old 813 implementations. 815 There is already work to extend the base QoS NSLP and GIST to enable 816 new QoS signaling scenarios. One such proposal is the Inter-Domain 817 Reservation Aggregation aiming to support large-scale deployment of 818 the QoS NSLP [I-D.bless-nsis-resv-aggr]. Another current proposal 819 seeks to extend the whole NSIS framework towards path-decoupled 820 signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. 822 8.4. QoS Specifications 824 The QoS Specification template (QSpec) is defined in 825 [I-D.ietf-nsis-qspec]. This provides the language in which the 826 requirements of specific QoS models are described. Introduction of 827 new QoS models requires IETF action, with the published document 828 defining the specific elements within the QSpec used in the new 829 model. See [I-D.ietf-nsis-qspec] for details. 831 The introduction of new QoS models is designed to enable deployment 832 of NSIS-based QoS control in specific scenarios. One such example is 833 the Integrated Services Controlled Load Service for NSIS 834 [I-D.kappler-nsis-qosmodel-controlledload]. 836 A key feature provided by defining the QSpec template is support of a 837 common language for describing QoS requirements and capabilities, 838 which can be reused by any QoS models intending to use the QoS NSLP 839 to signal their requirements for traffic flows. The commonality of 840 the QSpec parameters ensures a certain level of interoperability of 841 QoS models and reduces the demands on hardware that has to implement 842 the QoS control. Optional QSpec parameters support the extensibility 843 of the QoS NSLP to other QoS models in the future; new QSpec 844 parameters can be defined in the document that defines a new QoS 845 model. See Sections 4.4 and 7 of [I-D.ietf-nsis-qspec]. 847 The QSPEC consists of a QSPEC version number, QSPEC objects plus 848 specification of processing and procedures that can be used to build 849 many QoS models. If changes are made to the QSPEC that are not 850 backwards compatible, a new QSPEC version number has to be assigned. 851 Note that a new QSPEC version number is not needed just because new 852 additional QSPEC parameters are specified; new versions will be 853 needed only if the existing functionality is modified. It is 854 required that later QSPEC versions be backward compatible with 855 earlier QSPEC versions. The template includes version negotiation 856 procedures that allow the originator of an NSLP message to retry with 857 a lower QSPEC version if the receiver rejects a message because it 858 does not support the QSPEC version signaled in the message. 859 o Creation of a new, incompatible version of an existing Qspec 860 requires allocation of a new QSPEC version number by standards 861 action. See [I-D.ietf-nsis-qspec]. 862 o Completely new QSPECs can also be created. Such new QSPECs 863 require allocation of a QSPEC type by standards action. Values 864 are also available for local or experimental use during 865 development. See [I-D.ietf-nsis-qspec]. 866 o Additional QSPEC procedures can be defined requiring allocation of 867 a new QSPEC procedure number by standards action or through a 868 another specification document. Values are also available for 869 local or experimental use during development. See 870 [I-D.ietf-nsis-qspec]. 871 o Additional QSPEC parameters and associated error codes can be 872 defined requiring a specification document. Values are also 873 available for local or experimental use during development. See 874 [I-D.ietf-nsis-qspec]. 876 8.5. NAT/Firewall NSLP 878 The NAT/Firewall signaling can be extended broadly in the same way as 879 the QoS NSLP by defining new parameters to be carried in NAT/Firewall 880 NSLP messages. See Section 7 of [I-D.ietf-nsis-nslp-natfw]. No 881 proposals currently exist to fulfill new use cases for the protocol. 883 8.6. New NSLP protocols 885 Designing a new NSLP is both challenging and easy. 887 New signaling applications with associated NSLPs can be defined to 888 work in parallel or replace the applications already defined by the 889 NSIS working group. Applications that fit into the NSIS framework 890 will be expected to use GIST to provide transport of signaling 891 messages and appropriate security facilities which relieves the 892 application designer of many "lower level" problems. GIST provides 893 many important functions through its service layer API, and allows 894 the signaling application programmer to offload, e.g., the channel 895 security, transport characteristics and signaling node discovery to 896 GIST. 898 Yet, on the other hand, the signaling application designer must take 899 into account that the network environment can be dynamic, both in 900 terms of routing and node availability. The new NSLP designer must 901 take into account at least the following issues: 903 o Routing changes, e.g., due to mobility: GIST sends Network 904 Notifications when something happens in the network, e.g., peers 905 or routing paths change. All signaling applications must be able 906 to handle these notifications and act appropriately. GIST does 907 not include logic to figure out what the NSLP would want to do due 908 to a certain network event. Therefore, GIST gives the 909 notification to the application, and lets it make the right 910 decision. 911 o GIST indications: GIST will also send other notifications, e.g., 912 if a signaling peer does not reply to refresh messages, or a 913 certain NSLP message was not successfully delivered to the 914 recipient. Again, NSLP applications must be able to handle these 915 events, too. Appendix B in the GIST specification discusses the 916 GIST-NSLP API and the various functionality required, but 917 implementing this interface can be quite challenging; the 918 multitude of asynchronous notifications than can from GIST 919 increases the implementation complexity of the NSLP. 920 o Lifetime of the signaling flow: NSLPs should inform GIST when a 921 flow is no longer needed using the SetStateLifetime primitive. 922 This reduces bandwidth demands in the network. 923 o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new 924 NSLP needs to use a unique NSLPID to ensure that its messages are 925 delivered to the correct application by GIST. A single NSLP could 926 use multiple NSLPIDs, for example to distinguish different classes 927 of signaling nodes that might handle different levels of 928 aggregation of requests or alternative processing paths. Note 929 that unlike GIST, the NSLPs do not provide a protocol versioning 930 mechanism. If the new NSLP is an upgraded version of an existing 931 NSLP, then it should be distinguished by a different NSLPID. 932 * A new generally available NSLP requires IESG approval for the 933 allocation of a new NSLP ID [I-D.ietf-nsis-ntlp]. 934 o Source IP address: It is sometimes challenging to find out at the 935 NSLP, what will the source IP address be, especially when a node 936 has multiple interfaces. Moreover, the logic in specifying the 937 source IP address may differ if the node processing an NSLP 938 message is the source of the signaling flow, or an intermediate 939 node on the signaling. Thus, the NSLP must be able to find out 940 the right source IP address from its internal interfaces, and its 941 location on the signaling. 942 o New MRMs: GIST defines currently two Message Routing Methods, and 943 leave the door open for new ideas. Thus, it is possible that a 944 new NSLP also requires a new MRM, path-decoupled routing being one 945 example. 947 o Cooperation with other NSLPs: Some applications might need 948 resources from two or more different classes in order to operate 949 successfully. The NSLPs managing these resources could operate 950 cooperatively to ensure that such requests were coordinated to 951 avoid wasting signaling bandwidth and prevent race conditions. 953 The API between GIST and NSLPs (see Appendix B in 954 [I-D.ietf-nsis-ntlp]) is very important to understand. The abstract 955 design in the GIST specification does not specify the exact messaging 956 between GIST and the NSLPs but gives an understanding of the 957 interactions, especially what kinds of asynchronous notifications 958 from GIST the NSLP must be prepared to handle: the actual interface 959 will be dependent on each implementation of GIST. 961 Messages transmitted by GIST on behalf of an NSLP are identified by a 962 unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers 963 taken from a registry managed by IANA and defined in Section 9 of the 964 GIST specification [I-D.ietf-nsis-ntlp]. 966 A range of values (32704-32767) is available for Private and 967 Experimental use during development, but any new signaling 968 application that expects to be deployed generally on the Internet 969 needs to be defined either in a standards track RFC or, possibly, an 970 experimental RFC. Such an RFC would request allocation of unique 971 NSLPID value(s) from the IANA registry. There is additional 972 discussion of NSLPIDs in Section 3.8 of the GIST specification. 974 9. Security Considerations 976 This document provides information to the community. It does not 977 raise new security concerns. 979 10. IANA Considerations 981 This memo includes no request to IANA. 983 11. Acknowledgements 985 This document combines work previously published as two separate 986 drafts: "What is Next Steps in Signaling anyway - A User's Guide to 987 the NSIS Protocol Family" written by Roland Bless and Jukka Manner, 988 and "NSIS Extensibility Model" written by John Loughney. 990 Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of 991 "User's Guide" draft and valuable input. 993 The "Extensibility Model" borrowed some ideas and some text from 994 RFC3936 [RFC3936], Procedures for Modifying the Resource ReSerVation 995 Protocol (RSVP); Robert Hancock provided text for the original GIST 996 section, since much modified and Claudia Keppler have provided 997 feedback on this draft, while Allison Mankin and Bob Braden suggested 998 that this draft be worked on. 1000 12. References 1002 12.1. Normative References 1004 [I-D.ietf-nsis-nslp-natfw] 1005 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1006 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1007 draft-ietf-nsis-nslp-natfw-20 (work in progress), 1008 November 2008. 1010 [I-D.ietf-nsis-ntlp] 1011 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1012 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 1013 progress), October 2008. 1015 [I-D.ietf-nsis-qos-nslp] 1016 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1017 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 1018 (work in progress), February 2008. 1020 [I-D.ietf-nsis-qspec] 1021 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 1022 QSPEC Template", draft-ietf-nsis-qspec-21 (work in 1023 progress), November 2008. 1025 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 1026 RFC 3726, April 2004. 1028 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1029 Bosch, "Next Steps in Signaling (NSIS): Framework", 1030 RFC 4080, June 2005. 1032 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1033 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1035 12.2. Informative References 1037 [I-D.bless-nsis-est-mrm] 1038 Bless, R., "An Explicit Signaling Target Message Routing 1039 Method (EST-MRM) for the General Internet Signaling 1040 Transport (GIST) Protocol", draft-bless-nsis-est-mrm-01 1041 (work in progress), July 2008. 1043 [I-D.bless-nsis-resv-aggr] 1044 Doll, M. and R. Bless, "Inter-Domain Reservation 1045 Aggregation for QoS NSLP", draft-bless-nsis-resv-aggr-01 1046 (work in progress), July 2007. 1048 [I-D.braden-2level-signal-arch] 1049 Braden, R. and B. Lindell, "A Two-Level Architecture for 1050 Internet Signaling", draft-braden-2level-signal-arch-01 1051 (work in progress), November 2002. 1053 [I-D.cordeiro-nsis-hypath] 1054 Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., 1055 Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST 1056 Extension for Hybrid On-path Off-path Signaling (HyPath)", 1057 draft-cordeiro-nsis-hypath-05 (work in progress), 1058 February 2008. 1060 [I-D.hancock-nsis-gist-rao] 1061 Hancock, R., "Using the Router Alert Option for Packet 1062 Interception in GIST", draft-hancock-nsis-gist-rao-00 1063 (work in progress), November 2008. 1065 [I-D.kappler-nsis-qosmodel-controlledload] 1066 Kappler, C., Fu, X., and B. Schloer, "A QoS Model for 1067 Signaling IntServ Controlled-Load Service with NSIS", 1068 draft-kappler-nsis-qosmodel-controlledload-08 (work in 1069 progress), August 2008. 1071 [I-D.manner-nsis-gist-dccp] 1072 Manner, J., "Generic Internet Signaling Transport over 1073 DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in 1074 progress), June 2007. 1076 [I-D.manner-nsis-nslp-auth] 1077 Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 1078 "Authorization for NSIS Signaling Layer Protocols", 1079 draft-manner-nsis-nslp-auth-04 (work in progress), 1080 July 2008. 1082 [I-D.manner-nsis-peering-data] 1083 Manner, J., Liuhto, L., Varis, N., and T. Huovila, 1084 "Peering Data for NSIS Signaling Layer Protocols", 1085 draft-manner-nsis-peering-data-01 (work in progress), 1086 February 2008. 1088 [I-D.rahman-rtg-router-alert-dangerous] 1089 Rahman, R. and D. Ward, "Use of IP Router Alert Considered 1090 Dangerous", draft-rahman-rtg-router-alert-dangerous-00 1091 (work in progress), October 2008. 1093 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1094 Services in the Internet Architecture: an Overview", 1095 RFC 1633, June 1994. 1097 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1098 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1099 Functional Specification", RFC 2205, September 1997. 1101 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1102 Considered Useful", BCP 82, RFC 3692, January 2004. 1104 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1105 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1106 October 2004. 1108 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 1109 Service Signaling Protocols", RFC 4094, May 2005. 1111 Authors' Addresses 1113 Jukka Manner 1114 Helsinki University of Technology (TKK) 1115 P.O. Box 3000 1116 Espoo FIN-02015 TKK 1117 Finland 1119 Phone: +358 9 451 2481 1120 Email: jukka.manner@tkk.fi 1121 URI: http://www.netlab.tkk.fi/~jmanner/ 1123 Roland Bless 1124 Institute of Telematics, Universitaet Karlsruhe (TH) 1125 Zirkel 2 1126 Karlsruhe 76128 1127 Germany 1129 Phone: +49 721 608 6413 1130 Email: bless@tm.uka.de 1131 URI: http://www.tm.uka.de/~bless 1132 John Loughney 1133 Nokia 1134 955 Page Mill Road 1135 Palo Alto 94303 1136 USA 1138 Phone: +1 650 283 8068 1139 Email: john.loughney@nokia.com 1141 Elwyn Davies (editor) 1142 Folly Consulting 1143 Soham, 1144 UK 1146 Phone: 1147 Fax: 1148 Email: elwynd@folly.org.uk 1149 URI: http://www.folly.org.uk