idnits 2.17.1 draft-ietf-nsis-ext-01.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 4, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IANA' is mentioned on line 628, 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 5, 2009 Univ. of Karlsruhe 6 J. Loughney 7 Nokia 8 E B. Davies, Ed. 9 Folly Consulting 10 March 4, 2009 12 Using and Extending the NSIS Protocol Family 13 draft-ietf-nsis-ext-01.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 5, 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 . . . . . . . . . . . . . . . . . 11 74 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 12 75 6.1. Obstacles . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.2. Incremental Deployment and Workarounds . . . . . . . . . . 13 77 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 13 78 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 14 79 8.1. Overview of Administrative Actions Needed When 80 Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 15 81 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 19 84 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 19 85 8.6. New NSLP protocols . . . . . . . . . . . . . . . . . . . . 19 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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) [I-D.ietf-nsis-qspec] object in QoS NSLP 430 messages. This is similar to the decoupling between RSVP and the 431 IntServ architecture, RFC 1633 [RFC1633]. The QSpec carries 432 information on resources available, resources required, traffic 433 descriptions and other information required by the RMF. 435 The QoS NSLP supports different QoS models, because it does not 436 define the QoS mechanisms and RMF that have to be used in a domain. 437 As long as a domain knows how to perform admission control for a 438 given QSpec, QoS NSLP actually does not care how the specified 439 constraints are enforced and met, e.g., by putting the related data 440 flow in the topmost of four DiffServ classes, or by putting it into 441 the third highest of twelve DiffServ classes. The particular QoS 442 configuration used is up to the network provider of the domain. The 443 QSpec can be seen as a common language to express QoS requirements 444 between different domains and QoS models. 446 In short, the functionality of the QoS NSLP includes: 447 o Conveying resource requests for unicast flows 448 o Resource requests (QSpec) that are decoupled from the signaling 449 protocol (QoS NSLP) 450 o Sender- and receiver-initiated reservations, as well as, bi- 451 directional 452 o Soft-state and reduced refresh (keep-alive) signaling 453 o Session binding, session X can be valid only if session Y is too 454 o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy 455 mode) 456 o Protection against message re-ordering and duplication 457 o Group tear, tearing down several session with a single message 458 o Support for re-routing, e.g., due to mobility 459 o Support for request priorities and preemption 460 o Stateful and stateless nodes: stateless operation is particularly 461 relevant in core networks where large amounts of QoS state could 462 easily overwhelm a node 463 o Reservation aggregation 464 The protocol also provides for a proxy mode to allow the QoS 465 signaling to be implemented without needing all end hosts to be 466 capable of handling NSIS signaling. 468 5. NAT/Firewall Traversal NSLP 470 The NAT/Firewall Traversal NSLP [I-D.ietf-nsis-nslp-natfw] lets end- 471 hosts interact with NAT and firewall devices in the data path. 472 Basically it allows for a dynamic configuration of NATs and/or 473 firewalls along the data path in order to enable data flows to 474 traverse these devices without being obstructed. For instance, 475 firewall pinholes could be opened on demand by authorized hosts. 476 Furthermore, it is possible to block unwanted incoming traffic on 477 demand, e.g., if an end-host is under attack. 479 Configurations to be implemented in NAT and firewall devices 480 signalled by the NAT/Firewall NSLP take the form of a (Pattern, 481 Action) pair, where the pattern specifies a template for packet 482 header fields to be matched. The device is then expected to apply 483 the specified action to any passing packet that matches the template. 484 Actions are currently limited to ALLOW (forward the packet) and DENY 485 (drop the packet). The template specification allows for a greater 486 range of packet fields to be matched than those allowed for in the 487 GIST MRI. 489 Basically NAT/Firewall signaling starts at the data sender (NSIS 490 Initiator) before any actual application data packets are sent. 491 Signaling messages may pass several NAT/Firewall NSLP-aware 492 middleboxes (NSIS Forwarder) on their way downstream and usually hit 493 the receiver (being the NSIS Responder). A proxy mode is also 494 available for cases where the NAT/Firewall NSLP is not fully 495 supported along the complete data path. NAT/Firewall NSLP is based 496 on a soft-state concept, i.e., the sender must periodically repeat 497 its request in order to keep it active. 499 Additionally, the protocol also provides functions for receivers 500 behind NATs. The receiver may request an external address that is 501 reachable from outside. The reserved external address must, however, 502 be communicated to the sender out-of-band by other means, e.g., by 503 application level signaling. After this step the data sender may 504 initiate a normal NAT/Firewall signaling in order to create firewall 505 pinholes. 507 The protocol also provides for a proxy mode to allow the NAT/Firewall 508 signaling to be implemented without needing all end hosts to be 509 capable of handling NSIS signaling. 511 6. Deploying the Protocols 513 First of all, NSIS implementations must be available in at least some 514 of the corresponding network nodes (i.e., routers, firewalls, or NAT 515 gateways) and end-hosts. That means not only GIST support, but also 516 the NSLPs and their respective control functions (such as a resource 517 management function for QoS admission control etc.) must be 518 implemented. NSIS is capable of incremental deployment and an 519 initial deployment does not need to involve every node in a network 520 domain. This is discussed further in Section 6.2. 522 Another important issue is that applications may need to be made 523 NSIS-aware, thereby requiring some effort on the applications 524 programmer's behalf. Alternatively, it may be possible to implement 525 separate applications to control, e.g., the network QoS requests or 526 firewall pinholes, without needing to update the actual applications 527 that will take advantage of NSIS capabilities. 529 6.1. Obstacles 531 Although GIST is no longer dependent on RAO (there is known to be 532 network equipment with broken implementations of the RAO deployed), 533 if NSIS is to be deployed in routers with hardware-based forwarding 534 engines it is not guaranteed that the hardware will be able to divert 535 Query packets identified by a well-known UDP port into the slow path, 536 which will make deployment of NSIS dependent on hardware replacement 537 rather than software upgrade. However, the removal of dependence on 538 RAO makes it more likely that NSIS Query packets can be forwarded 539 through nodes that are not NSIS aware. 541 NAT gateways and firewalls may also hinder initial deployment of NSIS 542 protocols as they may either filter signaling traffic or perform 543 NSIS-unaware address translations. 545 6.2. Incremental Deployment and Workarounds 547 NSIS is specifically designed to be incrementally deployable. It is 548 not required that all nodes on the signaling and data path are NSIS 549 aware. To make any use of NSIS at least two nodes on the path need 550 to be NSIS aware. However, it is not essential that the initiator 551 and receiver of the data flow are NSIS aware. Both the QoS and NAT/ 552 Firewall NSLPs provide "proxy modes" in which nodes adjacent to the 553 initiator and/or receiver can act as proxy signaling initiator or 554 receiver. An initiator proxy can monitor traffic and, hopefully, 555 detect when a data flow of a type needing NSIS support is being 556 initiated. The proxies can act more or less transparently on behalf 557 of the data flow initiator and/or receiver to set up the required 558 NSIS state and maintain it while the data flow continues. This 559 capability reduces the immediate need to modify all the data flow end 560 points before NSIS is viable. 562 7. Security Features 564 Basic security functions are provided at the GIST layer, e.g., 565 protection against some blind or denial-of-service attacks. 566 Conceptually it is difficult to protect against on-path attacker and 567 man-in-the-middle attacks, because a basic functionality of GIST is 568 to discover yet unknown signaling peers. Transport security can be 569 requested by signaling applications and is realized by using TLS 570 between signaling peers, i.e., authenticity and confidentiality of 571 signaling messages can be assured between peers. GIST allows for 572 mutual authentication of the signaling peers (using TLS means like 573 certificates) and can verify the authenticated identity against a 574 database of nodes authorized to take part in GIST signaling. It is, 575 however, a matter of policy that the identity of peers is verified 576 and accepted upon establishment of the secure TLS connection. 578 While GIST is handling authentication of peer nodes, more fine 579 grained authentication may be required in the NSLP protocols. There 580 is currently an ongoing work to specify common authorization 581 mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], 582 thus allowing, e.g., per-user and per-service authorization. 584 8. Extending the Protocols 586 This section discusses the ways that are available to extend the NSIS 587 protocol suite. The Next Steps in Signaling (NSIS) Framework 588 [RFC4080] describes a two-layer framework for signaling on the 589 Internet, comprising a generic transport layer with specific 590 signaling layers to address particular applications running over this 591 transport layer. The model is designed to be highly extensible so 592 that it can be adapted for different signaling needs. 594 It is expected that additional signaling requirements will be 595 identified in future. The two layer approach allows for NSLP 596 signaling applications to be developed independently of the transport 597 protocol. Further NSLPs can therefore be developed and deployed to 598 meet these new needs using the same GIST infrastructure thereby 599 providing a level of macro-extensibility. However, the GIST protocol 600 and the two signaling applications have been designed so that 601 additional capabilities can be incorporated into the design should 602 additional requirements within the general scope of these protocols 603 need to be accommodated. 605 The NSIS framework is also highly supportive of incremental 606 deployment. A new NSLP need not be available on every NSIS aware 607 node in a network or along a signaling path in order to start using 608 it. Nodes that do not (yet) support the application will forward it 609 without complaint until it reaches a node where the new NSLP 610 application is deployed. 612 One key functionality of parameter objects carried in NSIS protocols 613 is the so-called "Extensibility flags (AB)". All the existing 614 protocols (and any future ones conforming to the standards) can carry 615 new experimental objects, where the AB-flags can indicate whether a 616 receiving node must interpret the object, or whether it can just drop 617 them or pass them along in subsequent messages sent out further on 618 the path. This functionality allows defining new objects without 619 forcing all network entities to understand them. 621 8.1. Overview of Administrative Actions Needed When Extending NSIS 623 Generally, NSIS protocols can be extended in multiple ways, many of 624 which require the allocation of unique code point values in 625 registries maintained by IANA on behalf of the IETF. This section is 626 an overview of the administrative mechanisms that might apply. The 627 extensibility rules are based upon the procedures by which IANA 628 assigns values: "Standards Action" (as defined in [IANA]), "IETF 629 Action", "Expert Review", and "Organization/Vendor Private", defined 630 below. The appropriate procedure for a particular type of code point 631 is defined in one or other of the NSIS protocol documents, mostly 632 [I-D.ietf-nsis-ntlp]. 634 In addition to registered code points, all NSIS protocols provide 635 code points that can be used for experimentation, usually within 636 closed networks, as explained in [RFC3692]. There is no guarantee 637 that independent experiments will not be using the same code point! 639 8.2. GIST 641 GIST is extensible in several aspects. In this list, references to 642 document sections refer to the GIST specification 643 [I-D.ietf-nsis-ntlp]. 644 o Use of different Message Routing Methods: currently only two 645 message routing methods are supported (Path-coupled MRM and Loose- 646 End MRM), but further MRMs may be defined in the future. See 647 Section 3.8. One possible additional MRM under development is 648 documented in [I-D.bless-nsis-est-mrm]. This MRM would direct 649 signaling towards an explicit target address other than the 650 (current) data flow destination and is intended to assist setting 651 up of state on a new path during 'make-before-break' handover 652 sequences in mobile operations. Note that alternative routing 653 methods may require modifications to the firewall traversal 654 techniques used by GIST and NSLPs. 655 * New MRMs require allocation of a new MRM-ID either by standards 656 action or expert review[I-D.ietf-nsis-ntlp]. 657 o Use of different transport protocols or security capabilities: the 658 initial handshake allows a negotiation of the transport protocols 659 to be used. Currently, a proposal to add DCCP and DTLS to GIST 660 exists [I-D.manner-nsis-gist-dccp]. See Sections 3.2 and 5.7. 661 GIST expects alternative capabilities to be treated as selection 662 of an alternative protocol stack. Within the protocol stack, the 663 individual protocols used are specified by MA Protocol IDs which 664 are allocated from an IANA registry if new protocols are to be 665 used. See Sections 5.7 and 9. 666 * Use of an alternative transport protocol or security capability 667 requires allocation of a new MA-Protocol-ID either by standards 668 action or expert review[I-D.ietf-nsis-ntlp]. 669 o Use of alternative security services: Currently only TLS is 670 specified for providing secure channels with MAs. Section 3.9 671 suggests that alternative protocols could be used, but the 672 interactions with GIST functions would need to be carefully 673 specified. See also Section 4.4.2. 674 * Use of an alternative security service requires allocation of a 675 new MA-Protocol-ID either by standards action or expert 676 review[I-D.ietf-nsis-ntlp]. 677 o Query mode packet interception schemes: GIST has standardized a 678 simple scheme using a well-known UDP port number plus a "magic 679 number" at the start of the UDP payload. Alternative schemes, 680 possibly including a reversion to the original proposal to use RAO 681 mechanisms[I-D.hancock-nsis-gist-rao], can be specified as 682 extensions. See Sections 5.3.2 and 5.3.2.5. Each NSLP needs to 683 specify membership of an "interception class" whenever it sends a 684 message through GIST. A packet interception scheme can support 685 one or more interception classes. In principle, a GIST instance 686 can support multiple packet interception schemes, but each 687 interception class needs to be associated with exactly one 688 interception scheme in a GIST instance and GIST instances that use 689 different packet interception schemes for the same interception 690 class will not be interoperable. 692 Defining an alternative interception class mechanism for 693 incorporation into GIST should be considered as a very radical 694 step and all alternatives should be considered before taking this 695 path. The main reason for this is that the mechanism will 696 necessarily require additional operations on every packet passing 697 through the affected router interfaces. A number of 698 considerations should be taken into account: 699 * Although the interception mechanism need only be deployed on 700 routers that actually need it (probably for a new NSLP), 701 deployment may be constrained if the mechanism requires 702 modification to the hardware of relevant routers and/or needs 703 to await modification of the software by the router vendor. 704 * Any packet fields to be examined should be normally close to 705 the start of the packet so that additional memory accesses are 706 not needed to retrieve the values needed for examination. 708 * The logic required to determine if a packet should be 709 intercepted needs to be kept simple to minimise the extra per- 710 packet processing. 711 * The mechanism should be applicable to both IPv4 and IPv6 712 packets. 713 * Packet interception mechanisms potentially provide an attack 714 path for Denial of Service attacks on routers, in that packets 715 are diverted into the "slow path" and hence can significantly 716 increase the load on the general processing capability of the 717 router. Any new interception mechanism needs to be carefully 718 designed to minimize the attack surface. 719 Packet interception mechanisms are identified by an "interception 720 class" which is supplied to GIST through the Application 721 Programming Interface for each message sent. 722 * New packet interception mechanisms will generally require 723 allocation of one or more new Interception-class-IDs. This 724 does not necessarily need to be placed in an IANA registry as 725 it is primarily used as a parameter in the API between the 726 NSLPs and GIST and may never appear on the wire, depending on 727 the mechanism employed; all that is required is consistent 728 interpretation between the NSLPs and GIST in each applicable 729 node. However, if, as is the case in the RAO proposal 730 [I-D.hancock-nsis-gist-rao], the scheme distinguishes between 731 multiple packet interception classes by a value carried on the 732 wire (different values of RAO parameter for the RAO proposal), 733 an IANA registry may be required to provide a mapping between 734 interception classes and on-the-wire values as discussed in 735 Section 6 of [I-D.hancock-nsis-gist-rao]. 736 o Use of alternative NAT traversal mechanisms: the mechanisms 737 proposed for both legacy NAT traversal (Section 7.2.1) and GIST- 738 aware NAT traversal (Section 7.2.2) can be extended or replaced. 739 As discussed above, extension of NAT traversal may be needed if a 740 new MRM is deployed. Note that there is extensive discussion of 741 NAT traversal in the NAT/Firewall NSLP specification 742 [I-D.ietf-nsis-nslp-natfw]. 743 o Additional error identifiers: Making extensions to any of the 744 above items may result in new error modes having to be catered 745 for. See Section 9 and Appendix A Sections A.4.1 - A.4.3. 746 * Additional error identifiers require allocation of new error 747 code(s) and/or subcode(s), and may also require allocation of 748 Additional Information types. These are all allocated on a 749 first-come, first-served basis by IANA [I-D.ietf-nsis-ntlp]. 750 o Generally: the AB-flags enable the community to specify new 751 objects applicable to GIST, that can be carried inside a signaling 752 session without breaking existing implementations. The AB-flags 753 can also be used to indicate in a controlled fashion that a 754 certain object must be understood by all GIST nodes, which makes 755 it possible to probe for the support of an extension. One such 756 object already designed is the "Peering Information Object (PIO)" 757 [I-D.manner-nsis-peering-data] that allows a QUERY message to 758 carry additional peering data for the recipient for making the 759 peering decision. 760 * New objects require allocation of a new Object Type ID either 761 by standards action or provision of another type of 762 specification [I-D.ietf-nsis-ntlp]. 763 o Major modifications could be made by adding additional GIST 764 message types and defining appropriate processing. It might be 765 necessary to define this as a new version of the protocol. A 766 field is provided in the GIST Common Header containing the version 767 number. GIST currently has no provision for version or capability 768 negotiation that might be needed if a new version was defined. 769 * New GIST Message Types require allocation of a new GIST Message 770 Type ID either by standards action or expert review 771 [I-D.ietf-nsis-ntlp]. 772 Finally, and more generally, as asserted in Section 1 of the GIST 773 specification, the GIST design could be extended to cater for 774 multicast flows and for situations where the signaling is not tied to 775 an end-to-end data flow, but it is not clear whether this could be 776 done in a totally backwards compatible way, and is not considered 777 within the extensibility model of NSIS. 779 8.3. QoS NSLP 781 The QoS NSLP provides signaling for QoS reservations on the Internet. 782 The QoS NSLP decouples the resource reservation model or architecture 783 (QoS model) from the signaling. The signaling protocol is defined in 784 Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp]. The QoS 785 models are defined in separate specifications and the QoS NSLP can 786 operate with one or more of these models as required by the 787 environment where it is used. It is anticipated that additional QoS 788 models will be developed to address various Internet scenarios in the 789 future. Extensibility of QoS models is considered in Section 8.4. 791 The QoS NSLP specifically mentions the possibility of using 792 alternative Message Routing Methods (MRMs), apart from the general 793 ability to extend NSLPs using new objects with the standard "AB" 794 extensibility flags to allow them to be used in new and old 795 implementations. 797 There is already work to extend the base QoS NSLP and GIST to enable 798 new QoS signaling scenarios. One such proposal is the Inter-Domain 799 Reservation Aggregation aiming to support large-scale deployment of 800 the QoS NSLP [I-D.bless-nsis-resv-aggr]. Another current proposal 801 seeks to extend the whole NSIS framework towards path-decoupled 802 signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. 804 8.4. QoS Specifications 806 The QoS Specification template (QSpec) is defined in 807 [I-D.ietf-nsis-qspec]. This provides the language in which the 808 requirements of specific QoS models are described. Introduction of 809 new QoS models requires IETF action, with the published document 810 defining the specific elements within the QSpec used in the new 811 model. See [I-D.ietf-nsis-qspec] for details. 813 The introduction of new QoS models is designed to enable deployment 814 of NSIS-based QoS control in specific scenarios. One such example is 815 the Integrated Services Controlled Load Service for NSIS 816 [I-D.kappler-nsis-qosmodel-controlledload]. 818 A key feature provided by defining the QSpec template is support of a 819 common language for describing QoS requirements and capabilities, 820 which can be reused by any QoS models intending to use the QoS NSLP 821 to signal their requirements for traffic flows. The commonality of 822 the QSpec parameters ensures a certain level of interoperability of 823 QoS models and reduces the demands on hardware that has to implement 824 the QoS control. Optional QSpec parameters support the extensibility 825 of the QoS NSLP to other QoS models in the future; new QSpec 826 parameters can be defined in the document that defines a new QoS 827 model. See Sections 4.4 and 7 of [I-D.ietf-nsis-qspec]. 829 The QSpec Template supports situations where the QoS parameters need 830 to be fine-grained, specifically targeted to an individual flow in 831 one part of the network (typically the edge or access part) but might 832 need to be more coarse-grained, where the flow is part of an 833 aggregate (typically in the core of the network). 835 8.5. NAT/Firewall NSLP 837 The NAT/Firewall signaling can be extended broadly in the same way as 838 the QoS NSLP by defining new parameters to be carried in NAT/Firewall 839 NSLP messages. See Section 7 of [I-D.ietf-nsis-nslp-natfw]. No 840 proposals currently exist to fulfill new use cases for the protocol. 842 8.6. New NSLP protocols 844 Designing a new NSLP is both challenging and easy. 846 New signaling applications with associated NSLPs can be defined to 847 work in parallel or replace the applications already defined by the 848 NSIS working group. Applications that fit into the NSIS framework 849 will be expected to use GIST to provide transport of signaling 850 messages and appropriate security facilities which relieves the 851 application designer of many "lower level" problems. GIST provides 852 many important functions through its service layer API, and allows 853 the signaling application programmer to offload, e.g., the channel 854 security, transport characteristics and signaling node discovery to 855 GIST. 857 Yet, on the other hand, the signaling application designer must take 858 into account that the network environment can be dynamic, both in 859 terms of routing and node availability. The new NSLP designer must 860 take into account at least the following issues: 862 o Routing changes, e.g., due to mobility: GIST sends Network 863 Notifications when something happens in the network, e.g., peers 864 or routing paths change. All signaling applications must be able 865 to handle these notifications and act appropriately. GIST does 866 not include logic to figure out what the NSLP would want to do due 867 to a certain network event. Therefore, GIST gives the 868 notification to the application, and lets it make the right 869 decision. 870 o GIST indications: GIST will also send other notifications, e.g., 871 if a signaling peer does not reply to refresh messages, or a 872 certain NSLP message was not successfully delivered to the 873 recipient. Again, NSLP applications must be able to handle these 874 events, too. Appendix B in the GIST specification discusses the 875 GIST-NSLP API and the various functionality required, but 876 implementing this interface can be quite challenging; the 877 multitude of asynchronous notifications than can from GIST 878 increases the implementation complexity of the NSLP. 879 o Lifetime of the signaling flow: NSLPs should inform GIST when a 880 flow is no longer needed using the SetStateLifetime primitive. 881 This reduces bandwidth demands in the network. 882 o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new 883 NSLP needs to use a unique NSLPID to ensure that its messages are 884 delivered to the correct application by GIST. A single NSLP could 885 use multiple NSLPIDs, for example to distinguish different classes 886 of signaling nodes that might handle different levels of 887 aggregation of requests or alternative processing paths. Note 888 that unlike GIST, the NSLPs do not provide a protocol versioning 889 mechanism. If the new NSLP is an upgraded version of an existing 890 NSLP, then it should be distinguished by a different NSLPID. 891 * A new generally available NSLP requires IESG approval for the 892 allocation of a new NSLP ID [I-D.ietf-nsis-ntlp]. 893 o Source IP address: It is sometimes challenging to find out at the 894 NSLP, what will the source IP address be, especially when a node 895 has multiple interfaces. Moreover, the logic in specifying the 896 source IP address may differ if the node processing an NSLP 897 message is the source of the signaling flow, or an intermediate 898 node on the signaling. Thus, the NSLP must be able to find out 899 the right source IP address from its internal interfaces, and its 900 location on the signaling. 901 o New MRMs: GIST defines currently two Message Routing Methods, and 902 leave the door open for new ideas. Thus, it is possible that a 903 new NSLP also requires a new MRM, path-decoupled routing being one 904 example. 905 o Cooperation with other NSLPs: Some applications might need 906 resources from two or more different classes in order to operate 907 successfully. The NSLPs managing these resources could operate 908 cooperatively to ensure that such requests were coordinated to 909 avoid wasting signaling bandwidth and prevent race conditions. 911 The API between GIST and NSLPs (see Appendix B in 912 [I-D.ietf-nsis-ntlp]) is very important to understand. The abstract 913 design in the GIST specification does not specify the exact messaging 914 between GIST and the NSLPs but gives an understanding of the 915 interactions, especially what kinds of asynchronous notifications 916 from GIST the NSLP must be prepared to handle: the actual interface 917 will be dependent on each implementation of GIST. 919 Messages transmitted by GIST on behalf of an NSLP are identified by a 920 unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers 921 taken from a registry managed by IANA and defined in Section 9 of the 922 GIST specification [I-D.ietf-nsis-ntlp]. 924 A range of values (32704-32767) is available for Private and 925 Experimental use during development, but any new signaling 926 application that expects to be deployed generally on the Internet 927 needs to be defined either in a standards track RFC or, possibly, an 928 experimental RFC. Such an RFC would request allocation of unique 929 NSLPID value(s) from the IANA registry. There is additional 930 discussion of NSLPIDs in Section 3.8 of the GIST specification. 932 9. Security Considerations 934 This document provides information to the community. It does not 935 raise new security concerns. 937 10. IANA Considerations 939 This memo includes no request to IANA. 941 11. Acknowledgements 943 This document combines work previously published as two separate 944 drafts: "What is Next Steps in Signaling anyway - A User's Guide to 945 the NSIS Protocol Family" written by Roland Bless and Jukka Manner, 946 and "NSIS Extensibility Model" written by John Loughney. 948 Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of 949 "User's Guide" draft and valuable input. 951 The "Extensibility Model" borrowed some ideas and some text from 952 RFC3936 [RFC3936], Procedures for Modifying the Resource ReSerVation 953 Protocol (RSVP); Robert Hancock provided text for the original GIST 954 section, since much modified and Claudia Keppler have provided 955 feedback on this draft, while Allison Mankin and Bob Braden suggested 956 that this draft be worked on. 958 12. References 960 12.1. Normative References 962 [I-D.ietf-nsis-nslp-natfw] 963 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 964 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 965 draft-ietf-nsis-nslp-natfw-20 (work in progress), 966 November 2008. 968 [I-D.ietf-nsis-ntlp] 969 Schulzrinne, H. and R. Hancock, "GIST: General Internet 970 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 971 progress), October 2008. 973 [I-D.ietf-nsis-qos-nslp] 974 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 975 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 976 (work in progress), February 2008. 978 [I-D.ietf-nsis-qspec] 979 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 980 Template", draft-ietf-nsis-qspec-21 (work in progress), 981 November 2008. 983 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 984 RFC 3726, April 2004. 986 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 987 Bosch, "Next Steps in Signaling (NSIS): Framework", 988 RFC 4080, June 2005. 990 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 991 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 993 12.2. Informative References 995 [I-D.bless-nsis-est-mrm] 996 Bless, R., "An Explicit Signaling Target Message Routing 997 Method (EST-MRM) for the General Internet Signaling 998 Transport (GIST) Protocol", draft-bless-nsis-est-mrm-01 999 (work in progress), July 2008. 1001 [I-D.bless-nsis-resv-aggr] 1002 Doll, M. and R. Bless, "Inter-Domain Reservation 1003 Aggregation for QoS NSLP", draft-bless-nsis-resv-aggr-01 1004 (work in progress), July 2007. 1006 [I-D.braden-2level-signal-arch] 1007 Braden, R. and B. Lindell, "A Two-Level Architecture for 1008 Internet Signaling", draft-braden-2level-signal-arch-01 1009 (work in progress), November 2002. 1011 [I-D.cordeiro-nsis-hypath] 1012 Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., 1013 Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST 1014 Extension for Hybrid On-path Off-path Signaling (HyPath)", 1015 draft-cordeiro-nsis-hypath-05 (work in progress), 1016 February 2008. 1018 [I-D.hancock-nsis-gist-rao] 1019 Hancock, R., "Using the Router Alert Option for Packet 1020 Interception in GIST", draft-hancock-nsis-gist-rao-00 1021 (work in progress), November 2008. 1023 [I-D.kappler-nsis-qosmodel-controlledload] 1024 Kappler, C., Fu, X., and B. Schloer, "A QoS Model for 1025 Signaling IntServ Controlled-Load Service with NSIS", 1026 draft-kappler-nsis-qosmodel-controlledload-08 (work in 1027 progress), August 2008. 1029 [I-D.manner-nsis-gist-dccp] 1030 Manner, J., "Generic Internet Signaling Transport over 1031 DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in 1032 progress), June 2007. 1034 [I-D.manner-nsis-nslp-auth] 1035 Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 1036 "Authorization for NSIS Signaling Layer Protocols", 1037 draft-manner-nsis-nslp-auth-04 (work in progress), 1038 July 2008. 1040 [I-D.manner-nsis-peering-data] 1041 Manner, J., Liuhto, L., Varis, N., and T. Huovila, 1042 "Peering Data for NSIS Signaling Layer Protocols", 1043 draft-manner-nsis-peering-data-01 (work in progress), 1044 February 2008. 1046 [I-D.rahman-rtg-router-alert-dangerous] 1047 Rahman, R. and D. Ward, "Use of IP Router Alert Considered 1048 Dangerous", draft-rahman-rtg-router-alert-dangerous-00 1049 (work in progress), October 2008. 1051 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 1052 Services in the Internet Architecture: an Overview", 1053 RFC 1633, June 1994. 1055 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 1056 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1057 Functional Specification", RFC 2205, September 1997. 1059 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1060 Considered Useful", BCP 82, RFC 3692, January 2004. 1062 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 1063 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 1064 October 2004. 1066 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 1067 Service Signaling Protocols", RFC 4094, May 2005. 1069 Authors' Addresses 1071 Jukka Manner 1072 Helsinki University of Technology (TKK) 1073 P.O. Box 3000 1074 Espoo FIN-02015 TKK 1075 Finland 1077 Phone: +358 9 451 2481 1078 Email: jukka.manner@tkk.fi 1079 URI: http://www.netlab.tkk.fi/~jmanner/ 1080 Roland Bless 1081 Institute of Telematics, Universitaet Karlsruhe (TH) 1082 Zirkel 2 1083 Karlsruhe 76128 1084 Germany 1086 Phone: +49 721 608 6413 1087 Email: bless@tm.uka.de 1088 URI: http://www.tm.uka.de/~bless 1090 John Loughney 1091 Nokia 1092 955 Page Mill Road 1093 Palo Alto 94303 1094 USA 1096 Phone: +1 650 283 8068 1097 Email: john.loughney@nokia.com 1099 Elwyn Davies (editor) 1100 Folly Consulting 1101 Soham, 1102 UK 1104 Phone: 1105 Fax: 1106 Email: elwynd@folly.org.uk 1107 URI: http://www.folly.org.uk