idnits 2.17.1 draft-nsis-ext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1037. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1061. 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 622: '... assignments MUST be requested by ei...' RFC 2119 keyword, line 625: '...t Review" ranges MUST be registered wi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 3, 2008) is 5643 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IANA' is mentioned on line 605, 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-20 == 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: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). 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: May 7, 2009 Univ. of Karlsruhe 6 J. Loughney 7 Nokia 8 E B. Davies, Ed. 9 Folly Consulting 10 November 3, 2008 12 Using and Extending the NSIS Protocol Family 13 draft-nsis-ext-02.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 7, 2009. 40 Abstract 42 This document gives an overview of the Next Steps in Signaling (NSIS) 43 framework and protocol suite created by the NSIS working group during 44 the period 2001-2008 together with suggestions on how the industry 45 can make use of the new protocols, and how the community can exploit 46 the extensibility of both the framework and existing protocols to 47 address future signaling needs. 49 Table of Contents 51 1. Introduction and History . . . . . . . . . . . . . . . . . . . 3 52 2. The NSIS Architecture . . . . . . . . . . . . . . . . . . . . 3 53 3. The General Internet Signaling Transport . . . . . . . . . . . 5 54 4. Quality of Service NSLP . . . . . . . . . . . . . . . . . . . 9 55 5. NAT/Firewall Traversal NSLP . . . . . . . . . . . . . . . . . 10 56 6. Deploying the Protocols . . . . . . . . . . . . . . . . . . . 11 57 6.1. Obstacles . . . . . . . . . . . . . . . . . . . . . . . . 12 58 6.2. Incremental Deployment and Workarounds . . . . . . . . . . 12 59 7. Security Features . . . . . . . . . . . . . . . . . . . . . . 12 60 8. Extending the Protocols . . . . . . . . . . . . . . . . . . . 13 61 8.1. Overview of Administrative Actions Needed When 62 Extending NSIS . . . . . . . . . . . . . . . . . . . . . . 14 63 8.2. GIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 8.3. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 8.4. QoS Specifications . . . . . . . . . . . . . . . . . . . . 16 66 8.5. NAT/Firewall NSLP . . . . . . . . . . . . . . . . . . . . 17 67 8.6. New NSLP protocols . . . . . . . . . . . . . . . . . . . . 17 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 73 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 75 Intellectual Property and Copyright Statements . . . . . . . . . . 24 77 1. Introduction and History 79 The Transport Area Directors held a Next Steps in Signaling (NSIS) 80 birds of a feather session on Wednesday 21st March 2001 at the 50th 81 IETF meeting in Minneapolis. The goal of the session was to discuss 82 and gather an initial set of requirements for a next generation 83 Internet signaling protocol suite as it was felt that the current 84 RSVP-based solutions have short-comings, e.g., with respect to 85 mobility or QoS interoperability. The NSIS Working Group was 86 officially formed later that year, in November 2001 and had its first 87 meeting at the IETF 52 in Salt Lake City in December 2001. 89 The initial charter of NSIS was focused on QoS signaling as the first 90 use case, taking the Resource ReSerVation Protocol (RSVP) as the 91 background for the work. In May 2003, middlebox traversal was added 92 as an explicit second use case. The requirements for the new 93 generation of signaling protocols are documented in [RFC3726] and an 94 analysis of existing signaling protocols can be found in [RFC4094]. 96 The design of NSIS is based on a two-layer model, where a general 97 signaling transport layer provides services to an upper signaling 98 layer. The design was influenced by Bob Braden's Internet Draft 99 entitled "A Two-Level Architecture for Internet Signaling" 100 [I-D.braden-2level-signal-arch]. 102 This document gives an overview of what the NSIS framework and 103 protocol suite is at the time of writing (2008), provides help and 104 guidelines to the reader as to how NSIS can be used in an IP network, 105 and how the protocol suite can be enhanced to satisfy new use cases. 107 2. The NSIS Architecture 109 The design of the NSIS protocol suite reuses ideas and concepts from 110 RSVP but essentially divides the functionality into two layers. The 111 lower layer, the NSIS Transport Layer Protocol (NTLP), is in charge 112 of transporting the higher layer protocol messages to the next 113 signaling node on the path. This includes discovery of the next hop 114 NSIS node, which may not be the next routing hop, and different 115 transport and security services depending on the signaling 116 application requirements. The General Internet Signaling Transport 117 (GIST) [I-D.ietf-nsis-ntlp] has been developed as the protocol that 118 fulfills the role of the NTLP. The NSIS suite supports both IP 119 protocol versions, IPv4 and IPv6. 121 The actual signaling application logic is implemented in the higher 122 layer of the NSIS stack, the NSIS Signaling Layer Protocol (NSLP). 123 While GIST is only concerned in transporting NSLP messages between 124 two end-points, the end-to-end signaling functionality is provided by 125 the NSLP protocols if needed - not all NSLP protocols need to perform 126 end-to-end signaling, even the current protocols have features to 127 confine the signaling to a limited path. Messages transmitted by 128 GIST on behalf of an NSLP are identified by a unique NSLP identifier 129 (NSLPID) associated with the NSLP. Two NSLP protocols are currently 130 standardized: one concerning Quality of Service signaling and one to 131 enable NAT/Firewall traversal. 133 NSIS is primarily designed to provide the signaling needed to install 134 state on nodes that lie on the path that will be taken by some end- 135 to-end flow of data packets in order to facilitate or enhance some 136 characteristic of the data flow. This is achieved by routing 137 signaling messages along the same path (known as "path-coupled 138 signaling") and intercepting the signaling message at NSIS capable 139 nodes. Parameters carried by the signaling message drive the 140 operation of the relevant transport or signaling application. In 141 particular, the messages will carry Message Routing Information (MRI) 142 that will allow the NSIS nodes to identify the data flow to which the 143 signaling applies. Generally, the intercepted messages will be 144 reinjected into the network after processing by the NSIS entities and 145 routed further towards the destination, possibly being intercepted by 146 additional NSIS nodes before arriving at the flow endpoint. 148 As with RSVP, it is expected that the signaling message will make a 149 complete round trip either along the whole end-to-end path or a part 150 of it if the scope of the signaling is limited. This implements a 151 two-phase strategy in which capabilities are assessed and provisional 152 reservations are made on the outbound leg; these provisional 153 reservations are then confirmed and operational state installed on 154 the return leg. Unlike RSVP, signaling is normally initiated at the 155 source of the data flow making it easier to ensure that the signaling 156 follows the expected path of the data flow, but can also be receiver 157 initiated as in RSVP. 159 A central concept of NSIS is the Session Identifier (SID). Signaling 160 application states are indexed and referred to through the SID. This 161 decouples the state information from IP addresses, allowing dynamic 162 IP address changes for signaling flows, e.g., due to mobility: 163 changes in IP addresses do not force complete tear down and re- 164 initiation of a signaling application state, merely an update of the 165 state parameters. 167 The SID is not meaningful by itself, but is rather used together with 168 the NSLP identifier (NSLPID) and the Message Routing Information 169 (MRI). This 3-tuple is used by GIST to index and manage the 170 signaling flows. 172 The following design restrictions were imposed for the first phase of 173 the protocol suite. They may be lifted in future and new 174 functionality may be added into the protocols at some later stage. 176 o Path-coupled signaling only: GIST transports messages towards an 177 identified unicast data flow destination based on the signaling 178 application request, and does not directly support path-decoupled 179 signaling, e.g., QoS signaling to a bandwidth broker. The 180 framework also supports a "Loose-End" message routing method used 181 to discover GIST nodes with particular properties in the direction 182 of a given address, for example the NAT/FW NSLP uses this method 183 to discover a NAT along the upstream data path. 184 o No multicast support: Introducing support for multicast was deemed 185 too much overhead, if considering the currently limited support 186 for global IP multicast. Thus, the current GIST and the NSLP 187 specifications consider unicast flows only. 189 The key documents specifying the NSIS framework are: 191 o Requirements for Signaling Protocols [RFC3726] 192 o Next Steps in Signaling: Framework [RFC4080] 193 o Security Threats for NSIS [RFC4081] 195 The protocols making up the suite specified by the NSIS working group 196 are documented in: 197 o The General Internet Signaling Transport protocol 198 [I-D.ietf-nsis-ntlp] 199 o Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp] 200 o The QoS specification template [I-D.ietf-nsis-qspec] 201 o NAT/Firewall traversal NSLP [I-D.ietf-nsis-nslp-natfw] 202 The next three sections provide a brief survey of GIST, the QoS NSLP, 203 and the NAT/Firewall NSLP. 205 3. The General Internet Signaling Transport 207 The General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp] 208 provides a signaling transport and security services to NSIS 209 Signaling Layer Protocols (NSLP) and the associated signaling 210 applications. GIST does not define new IP transport protocols or 211 security mechanisms but rather makes use of existing protocols, such 212 as TCP, UDP, TLS and IPsec. Applications can indicate the desired 213 reliability, e.g., unreliable or reliable, and GIST then uses the 214 most appropriate transport protocol to achieve the goal. If 215 applications request also security, GIST uses TLS. The GIST layered 216 protocol stack is shown in Figure 1. 218 +-----+ +--------+ +-------+ 219 | | | | | | 220 | QoS | | NAT/FW | | ... | NSLP 221 | | | | | | 222 +-----+ +--------+ +-------+ 224 ---------------------------------------------------------------------- 225 +--------------------------+ 226 | | 227 | GIST | NTLP 228 | | 229 +--------------------------+ 231 ---------------------------------------------------------------------- 232 +--------------------------+ 233 | TLS | 234 +--------------------------+ 235 +--------------------------+ 236 | TCP | UDP | SCTP | DCCP | 237 +--------------------------+ 238 +--------------------------+ 239 | IPsec | 240 +--------------------------+ 241 +--------------------------+ 242 | IPv4 | IPv6 | 243 +--------------------------+ 245 Figure 1: The NSIS protocol stack 247 GIST divides up the end-to-end path to be taken by the data flow into 248 a number of segments between pairs of NSIS aware peer nodes located 249 along the path. Not every router or other middlebox on the path 250 needs to be NSIS aware: each segment of the signaling path may 251 incorporate several routing hops. Also not every NSIS aware node 252 necessarily implements every possible signaling application. If the 253 signaling for a flow requests services from a subset of the 254 applications, then only nodes that implement those services are 255 expected to participate as peers, and even some of these nodes can 256 decline to operate on a particular flow if, for example, the 257 additional load might overload the processing capability of the node. 258 These characteristics mean that incremental deployment of NSIS 259 capabilities is possible both with the initial protocol suite, and 260 for any future NSLP applications that might be developed. The 261 following paragraphs describe how a signaling segment is setup 262 offering the transport and security characteristics needed by a 263 single NSLP. 265 When an NSLP application wants to send a message to its next peer, 266 GIST starts the process of discovering the next signaling node by 267 sending a Query message towards the destination of the related data 268 flow. This Query carries the NSLP identifier (NSLPID) and Message 269 Routing Information (MRI) among others. The MRI contains enough 270 information to control the routing of the signaling message and 271 identify the associated data flow. The next GIST node on the path 272 receives the message and if it is running the same NSLP, it provides 273 the MRI to the NSLP application and requests it to make a decision on 274 whether to peer with the querying node. If the NSLP application 275 chooses to peer, GIST sets up a Message Routing State (MRS) between 276 the two nodes for the future exchange of NSLP data. State setup is 277 performed by a three-way handshake that allows for negotiation of 278 signaling flow parameters and provides counter-measures against 279 several attacks like denial-of-service by using cookie mechanisms and 280 a late state installation option. 282 If a transport connection is required and needs to provide for 283 reliable or secure signaling, like TCP or TLS/TCP, a Messaging 284 Association (MA) is established between the two peers. An MA can be 285 re-used for signaling messages concerning several different data 286 flows, i.e., signaling messages between two nodes are multiplexed 287 over the same transport connection. This can be done when the 288 transport requirements (reliability, security) of a new flow can be 289 met with an existing MA, i.e., the security and transport properties 290 of an existing MA are equivalent or better than what is requested by 291 the new MA. 293 For path-coupled signaling, we need to find the nodes on the data 294 path that should take part in the signaling of an NSLP and invoke 295 them to act on the arrival of such NSLP signaling messages. The 296 basic concept is that such nodes along a flow's data path intercept 297 the corresponding signaling packets and are thus discovered 298 automatically. It was originally envisaged that GIST would place a 299 Router Alert Option (RAO) in Query message packets to ensure that 300 they are intercepted by NSIS aware nodes as in RSVP. 302 Late in the development of GIST serious concerns were raised in the 303 IETF about the security risks and performance implications of 304 extensive usage of the RAO [I-D.rahman-rtg-router-alert-dangerous], 305 as well as discovery of evidence that several existing 306 implementations of RAO were inconsistent with the standards and would 307 not support the NSIS usage. There were also concerns that extending 308 the need for RAO recognition in the fast path of routers that are 309 frequently implemented in hardware would delay or deter 310 implementation and deployment of NSIS. An alternative mechanism was 311 therefore standardized. 313 The approved version of GIST specifies that NSIS nodes recognise UDP 314 packets directed to a specific destination port and containing a GIST 315 specific "magic number" as the first 32 bits of the UDP payload as 316 Query messages that need to be intercepted. It is recognised that 317 this interception method is not the most efficient possible and GIST 318 provides for the use of alternatives, such as the RAO, for specific 319 NSLPs as a part of its extensibility design. Further intentional 320 bypassing of signaling nodes can be accomplished either in GIST or in 321 the NSLP. 323 Since GIST carries information about the data flow inside its 324 messages (in the MRI), NAT gateways must be aware of GIST in order to 325 let it work correctly. GIST provides a special object for NAT 326 traversal so that the actual translation is disclosed if a GIST-aware 327 NAT gateway provides this object. 329 As with RSVP, all the state installed by NSIS protocols is "soft- 330 state" that will expire and be automatically removed unless it is 331 periodically refreshed. NSIS state is held both at the signaling 332 application layer and in the transport layer, and is maintained 333 separately. NSLPs control the lifetime of the state in the 334 application layer by setting a timeout and sending periodic "keep 335 alive" messages along the signaling path if no other messages are 336 required. The MAs and the routing state are maintained semi- 337 independently by the transport layer, because MAs may be used by 338 multiple NSLP sessions, and can also be recreated "on demand" if the 339 node needs to reclaim resources. The transport layer can send its 340 own "keep alive" messages across a MA if no NSLP messages have been 341 sent, for example if the transport layer decides to maintain a 342 heavily used MA even though there is no current NSLP session using 343 it. State can also be deleted explicitly when no longer needed. 345 If there is a change in the route used by a flow for which NSIS has 346 created state, NSIS needs to detect the change in order to determine 347 if the new path contains additional NSIS nodes that should have state 348 installed. GIST may use a range of triggers in order to detect a 349 route change. It probes periodically for the next peer by sending a 350 GIST Query, thereby detecting a changed route and GIST peer. GIST 351 monitors routing tables, the GIST peer states, and notifies NSLPs of 352 any routing changes. It is then up to the NSLPs to act 353 appropriately, if needed, e.g., by issuing a refresh message. The 354 periodic queries also serve to maintain the soft-state in nodes as 355 long as the route is unchanged. 357 In summary, GIST provides several services in one package to the 358 upper layer signaling protocols: 360 o Signaling peer discovery: GIST is able to find the next hop node 361 that runs the NSLP being signaled for. 362 o Multiplexing: GIST reuses already established signaling 363 relationships and messaging associations to peers if the signaling 364 flows traverse the same next signaling hop. 365 o Transport: GIST provides transport with different attributes, 366 namely reliable/unreliable and secure/unsecure. 367 o Confidentiality: If security is requested, GIST uses TLS to 368 provide an encrypted and integrity protected message transport to 369 the next signaling peer. 370 o Routing changes: GIST detects routing changes, but instead of 371 acting on its own, it merely sends a notification to the local 372 NSLP. It is then up to the NSLP to act. 373 o Fragmentation: GIST uses either a known Path MTU for the next hop 374 or limits its message size to 576 bytes. If fragmentation is 375 required it automatically establishes an MA and sends the 376 signaling traffic over a reliable protocol, e.g., TCP. 377 o State maintenance: GIST establishes and then maintains the soft- 378 state that controls communications through MAs between GIST peers 379 along the signaling path, according to usage parameters supplied 380 by NSLPs and local policies. 382 4. Quality of Service NSLP 384 The Quality of Service (QoS) NSIS Signaling Layer Protocol (NSLP) 385 establishes and maintains state at nodes along the path of a data 386 flow for the purpose of providing some forwarding resources for that 387 flow. It is intended to satisfy the QoS-related requirements of RFC 388 3726 [RFC3726]. No support for QoS architectures based on bandwidth 389 brokers is currently included. 391 The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 392 [RFC2205], and uses soft-state peer-to-peer refresh messages as the 393 primary state management mechanism (i.e., state installation/refresh 394 is performed between pairs of adjacent NSLP nodes, rather than in an 395 end-to-end fashion along the complete signaling path). The QoS NSLP 396 extends the set of reservation mechanisms to meet the requirements of 397 RFC 3726 [RFC3726], in particular support of sender or receiver- 398 initiated reservations, as well as, a type of bi-directional 399 reservation and support of reservations between arbitrary nodes, 400 e.g., edge-to-edge, end-to-access, etc. On the other hand, there is 401 currently no support for IP multicast. 403 A distinction is made between the operation of the signaling protocol 404 and the information required for the operation of the Resource 405 Management Function (RMF). RMF-related information is carried in the 406 QSpec (QoS Specification) [I-D.ietf-nsis-qspec] object in QoS NSLP 407 messages. This is similar to the decoupling between RSVP and the 408 IntServ architecture, RFC 1633 [RFC1633]. The QSpec carries 409 information on resources available, resources required, traffic 410 descriptions and other information required by the RMF. 412 The QoS NSLP supports different QoS models, because it does not 413 define the QoS mechanisms and RMF that have to be used in a domain. 414 As long as a domain knows how to perform admission control for a 415 given QSpec, QoS NSLP actually does not care how the specified 416 constraints are enforced and met, e.g., by putting the related data 417 flow in the topmost of four DiffServ classes, or by putting it into 418 the third highest of twelve DiffServ classes. The particular QoS 419 configuration used is up to the network provider of the domain. The 420 QSpec can be seen as a common language to express QoS requirements 421 between different domains and QoS models. 423 In short, the functionality of the QoS NSLP includes: 424 o Conveying resource requests for unicast flows 425 o Resource requests (QSpec) are decoupled from the signaling 426 protocol (QoS NSLP) 427 o Sender- and receiver-initiated reservations, as well as, bi- 428 directional 429 o Soft-state and reduced refresh (keep-alive) signaling 430 o Session binding, session X can be valid only if session Y is too 431 o Message scoping, end-to-end, edge-to-edge or end-to-edge (proxy 432 mode) 433 o Protection against message re-ordering and duplication 434 o Group tear, tearing down several session with a single message 435 o Support for re-routing, e.g., due to mobility 436 o Support for request priorities and preemption 437 o Stateful and stateless nodes: stateless operation is particularly 438 relevant in core networks where large amounts of QoS state could 439 easily overwhelm a node 440 o Reservation aggregation 441 The protocol also provides for a proxy mode to allow the QoS 442 signaling to be implemented without needing all end hosts to be 443 capable of handling NSIS signaling. 445 5. NAT/Firewall Traversal NSLP 447 The NAT/Firewall Traversal NSLP [I-D.ietf-nsis-nslp-natfw] lets end- 448 hosts interact with NAT and firewall devices in the data path. 449 Basically it allows for a dynamic configuration of NATs and/or 450 firewalls along the data path in order to enable data flows to 451 traverse these devices without being obstructed. For instance, 452 firewall pinholes could be opened on demand by authorized hosts. 453 Furthermore, it is possible to block unwanted incoming traffic on 454 demand, e.g., if an end-host is under attack. 456 Configurations to be implemented in NAT and firewall devices 457 signalled by the NAT/Firewall NSLP take the form of a (Pattern, 458 Action) pair, where the pattern specifies a template for packet 459 header fields to be matched. The device is then expected to apply 460 the specified action to any passing packet that matches the template. 461 Actions are currently limited to ALLOW (forward the packet) and DENY 462 (drop the packet). The template specification allows for a greater 463 range of packet fields to be matched than those allowed for in the 464 GIST MRI. 466 Basically NAT/Firewall signaling starts at the data sender (NSIS 467 Initiator) before any actual application data packets are sent. 468 Signaling messages may pass several NAT/Firewall NSLP-aware 469 middleboxes (NSIS Forwarder) on their way downstream and usually hit 470 the receiver (being the NSIS Responder). A proxy mode is also 471 available for cases where the NAT/Firewall NSLP is not fully 472 supported along the complete data path. NAT/Firewall NSLP is based 473 on a soft-state concept, i.e., the sender must periodically repeat 474 its request in order to keep it active. 476 Additionally, the protocol also provides functions for receivers 477 behind NATs. The receiver may request an external address that is 478 reachable from outside. The reserved external address must, however, 479 be communicated to the sender out-of-band by other means, e.g., by 480 application level signaling. After this step the data sender may 481 initiate a normal NAT/Firewall signaling in order to create firewall 482 pinholes. 484 The protocol also provides for a proxy mode to allow the NAT/Firewall 485 signaling to be implemented without needing all end hosts to be 486 capable of handling NSIS signaling. 488 6. Deploying the Protocols 490 First of all, NSIS implementations must be available in at least some 491 of the corresponding network nodes (i.e., routers, firewalls, or NAT 492 gateways) and end-hosts. That means not only GIST support, but also 493 the NSLPs and their respective control functions (such as a resource 494 management function for QoS admission control etc.) must be 495 implemented. NSIS is capable of incremental deployment and an 496 initial deployment does not need to involve every node in a network 497 domain. This is discussed further in Section 6.2. 499 Another important issue is that applications may need to be made 500 NSIS-aware, thereby requiring some effort on the applications 501 programmer's behalf. Alternatively, it may be possible to implement 502 separate applications to control, e.g., the network QoS requests or 503 firewall pinholes, without needing to update the actual applications 504 that will take advantage of NSIS capabilities. 506 6.1. Obstacles 508 Although GIST is no longer dependent on RAO (there is known to be 509 network equipment with broken implementations of the RAO deployed), 510 if NSIS is to be deployed in routers with hardware-based forwarding 511 engines it is not guaranteed that the hardware will be able to divert 512 Query packets identified by a well-known UDP port into the slow path, 513 which will make deployment of NSIS dependent on hardware replacement 514 rather than software upgrade. However, the removal of dependence on 515 RAO makes it more likely that NSIS Query packets can be forwarded 516 through nodes that are not NSIS aware. 518 NAT gateways and firewalls may also hinder initial deployment of NSIS 519 protocols as they may either filter signaling traffic or perform 520 NSIS-unaware address translations. 522 6.2. Incremental Deployment and Workarounds 524 NSIS is specifically designed to be incrementally deployable. It is 525 not required that all nodes on the signaling and data path are NSIS 526 aware. To make any use of NSIS at least two nodes on the path need 527 to be NSIS aware. However, it is not essential that the initiator 528 and receiver of the data flow are NSIS aware. Both the QoS and NAT/ 529 Firewall NSLPs provide "proxy modes" in which nodes adjacent to the 530 initiator and/or receiver can act as proxy signaling initiator or 531 receiver. An initiator proxy can monitor traffic and, hopefully, 532 detect when a data flow of a type needing NSIS support is being 533 initiated. The proxies can act more or less transparently on behalf 534 of the data flow initiator and/or receiver to set up the required 535 NSIS state and maintain it while the data flow continues. This 536 capability reduces the immediate need to modify all the data flow end 537 points before NSIS is viable. 539 7. Security Features 541 Basic security functions are provided at the GIST layer, e.g., 542 protection against some blind or denial-of-service attacks. 543 Conceptually it is difficult to protect against on-path attacker and 544 man-in-the-middle attacks, because a basic functionality of GIST is 545 to discover yet unknown signaling peers. Transport security can be 546 requested by signaling applications and is realized by using TLS 547 between signaling peers, i.e., authenticity and confidentiality of 548 signaling messages can be assured between peers. GIST allows for 549 mutual authentication of the signaling peers (using TLS means like 550 certificates) and can verify the authenticated identity against a 551 database of nodes authorized to take part in GIST signaling. It is, 552 however, a matter of policy that the identity of peers is verified 553 and accepted upon establishment of the secure TLS connection. 555 While GIST is handling authentication of peer nodes, more fine 556 grained authentication may be required in the NSLP protocols. There 557 is currently an ongoing work to specify common authorization 558 mechanisms to be used in NSLP protocols [I-D.manner-nsis-nslp-auth], 559 thus allowing, e.g., per-user and per-service authorization. 561 8. Extending the Protocols 563 This section discusses the ways that are available to extend the NSIS 564 protocol suite. The Next Steps in Signaling (NSIS) Framework NSIS 565 Framework [RFC4080] describes a two-layer framework for signaling on 566 the Internet, comprising a generic transport layer with specific 567 signaling layers to address particular applications running over this 568 transport layer. The model is designed to be highly extensible so 569 that it can be adapted for different signaling needs. 571 It is expected that additional signaling requirements will be 572 identified in future. The two layer approach allows for NSLP 573 signaling applications to be developed independently of the transport 574 protocol. Further NSLPs can therefore be developed and deployed to 575 meet these new needs using the same GIST infrastructure thereby 576 providing a level of macro-extensibility. However, the GIST protocol 577 and the two signaling applications have been designed so that 578 additional capabilities can be incorporated into the design should 579 additional requirements within the general scope of these protocols 580 need to be accommodated. 582 The NSIS framework is also highly supportive of incremental 583 deployment. A new NSLP need not be available on every NSIS aware 584 node in a network or along a signaling path in order to start using 585 it. Nodes that do not (yet) support the application will forward it 586 without complaint until it reaches a node where the new NSLP 587 application is deployed. 589 One key functionality of parameter objects carried in NSIS protocols 590 is the so-called "Extensibility flags (AB)". All the existing 591 protocols (and any future ones conforming to the standards) can carry 592 new experimental objects, where the AB-flags can indicate whether a 593 receiving node must interpret the object, or whether it can just drop 594 them or pass them along in subsequent messages sent out further on 595 the path. This functionality allows defining new objects without 596 forcing all network entities to understand them. 598 8.1. Overview of Administrative Actions Needed When Extending NSIS 600 Generally, NSIS protocols can be extended in multiple ways, many of 601 which require the allocation of unique code point values in 602 registries maintained by IANA on behalf of the IETF. This section is 603 an overview of the administrative mechanisms that might apply. The 604 extensibility rules are based upon the procedures by which IANA 605 assigns values: "Standards Action" (as defined in [IANA]), "IETF 606 Action", "Expert Review", and "Organization/Vendor Private", defined 607 below. The appropriate procedure for a particular type of code point 608 is defined in one or other of the NSIS protocol documents, mostly 609 [I-D.ietf-nsis-ntlp]. 611 Extensions subject to "IETF Action" require publication of either a 612 Standards Track RFC, Experimental RFC or an Informational RFC with 613 details of the required allocation. In particular defining a new 614 signaling application for general deployment requires that it is 615 defined in a published RFC (generally Standards Track but possibly 616 Experimental) that would request the allocation of an NLSPID for the 617 new application. 619 Extensions subject to "Expert Review" refer to values that are to be 620 reviewed by an Expert designated by the IESG. The code points from 621 these ranges are typically used for experimental extensions; such 622 assignments MUST be requested by either Experimental or Information 623 RFCs that document their use and processing, and the actual 624 assignments made during the IANA actions for the document. Values 625 from "Expert Review" ranges MUST be registered with IANA. 627 "Organization/Vendor Private" ranges refer to values that are 628 enterprise-specific. In this way, different enterprises, vendors, or 629 Standards Development Organizations (SDOs) can use the same code 630 point without fear of collision. 632 In the NSIS protocols, experimental code points are allocated for 633 experimentation, usually within closed networks, as explained in 634 [RFC3692]. If these experiments yield useful results, it is assumed 635 that they will be formally allocated by one of the above mechanisms. 636 There is no guarantee that independent experiments will not be using 637 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 644 [I-D.ietf-nsis-ntlp]. 645 o Use of different Message Routing Methods: currently only two 646 message routing methods are supported (Path-coupled MRM and Loose- 647 End MRM), but further MRMs may be defined in the future. See 648 Section 3.8. One possible additional MRM under development is 649 documented in [I-D.bless-nsis-est-mrm]. This MRM would direct 650 signaling towards an explicit target address other than the 651 (current) data flow destination and is intended to assist setting 652 up of state on a new path during 'make-before-break' handover 653 sequences in mobile operations. Note that alternative routing 654 methods may require modifications to the firewall traversal 655 techniques used by GIST and NSLPs. 656 o Use of different transport protocols or security capabilities: the 657 initial handshake allows a negotiation of the transport protocols 658 to be used. Currently, a proposal to add DCCP and DTLS to GIST 659 exists [I-D.manner-nsis-gist-dccp]. See Sections 3.2 and 5.7. 660 GIST expects alternative capabilities to be treated as selection 661 of an alternative protocol stack. Within the protocol stack, the 662 individual protocols used are specified by MA Protocol IDs which 663 are allocated from an IANA registry if new protocols are to be 664 used. See Sections 5.7 and 9. 665 o Use of alternative security services: Currently only TLS is 666 specified for providing secure channels with MAs. Section 3.9 667 suggests that alternative protocols could be used, but the 668 interactions with GIST functions would need to be carefully 669 specified. See also Section 4.4.2. 670 o Query mode packet interception schemes: GIST has standardized a 671 simple scheme using a well-known UDP port number plus a "magic 672 number" at the start of the UDP payload. Alternative schemes, 673 possibly including a reversion to the original proposal to use RAO 674 mechanisms, can be specified as extensions. See Sections 5.3.2 675 and 5.3.2.5. Each NSLP needs to specify which interception 676 mechanisms apply through specifying membership of an "interception 677 class". 678 o Use of alternative NAT traversal mechanisms: the mechanisms 679 proposed for both legacy NAT traversal (Section 7.2.1) and GIST- 680 aware NAT traversal (Section 7.2.2) can be extended or replaced. 681 Note that there is extensive discussion of NAT traversal in the 682 NAT/Firewall NSLP specification [I-D.ietf-nsis-nslp-natfw]. 683 o Additional error identifiers: Making extensions to any of the 684 above items may result in new error modes having to be catered 685 for. See Section 9 and Appendix A Sections A.4.1 - A.4.3. 686 o Generally: the AB-flags enable the community to specify new 687 objects applicable to GIST, that can be carried inside a signaling 688 session without breaking existing implementations. The AB-flags 689 can also be used to indicate in a controlled fashion that a 690 certain object must be understood by all GIST nodes, which makes 691 it possible to probe for the support of an extension. One such 692 object already designed is the "Peering Information Object (PIO)" 693 [I-D.manner-nsis-peering-data] that allows a QUERY message to 694 carry additional peering data for the recipient for making the 695 peering decision. 696 Finally, and more generally, as asserted in Section 1 of the GIST 697 specification, the GIST design could be extended to cater for 698 multicast flows and for situations where the signaling is not tied to 699 an end-to-end data flow, but it is not clear whether this could be 700 done in a totally backwards compatible way, and is not considered 701 within the extensibility model of NSIS. 703 8.3. QoS NSLP 705 The QoS NSLP provides signaling for QoS reservations on the Internet. 706 The QoS NSLP decouples the resource reservation model or architecture 707 (QoS model) from the signaling. The signaling protocol is defined in 708 Quality of Service NSLP (QoS NSLP) [I-D.ietf-nsis-qos-nslp]. The QoS 709 models are defined in separate specifications and the QoS NSLP can 710 operate with one or more of these models as required by the 711 environment where it is used. It is anticipated that additional QoS 712 models will be developed to address various Internet scenarios in the 713 future. Extensibility of QoS models is considered in Section 8.4. 715 The QoS NSLP specifically mentions the possibility of using 716 alternative Message Routing Methods (MRMs), apart from the general 717 ability to extend NSLPs using new objects with the standard "AB" 718 extensibility flags to allow them to be used in new and old 719 implementations. 721 There is already work to extend the base QoS NSLP and GIST to enable 722 new QoS signaling scenarios. One such proposal is the Inter-Domain 723 Reservation Aggregation aiming to support large-scale deployment of 724 the QoS NSLP [I-D.bless-nsis-resv-aggr]. Another current proposal 725 seeks to extend the whole NSIS framework towards path-decoupled 726 signaling and QoS reservations [I-D.cordeiro-nsis-hypath]. 728 8.4. QoS Specifications 730 The QoS Specification template (QSpec) is defined in 731 [I-D.ietf-nsis-qspec]. This provides the language in which the 732 requirements of specific QoS models are described. Introduction of 733 new QoS models requires IETF action, with the published document 734 defining the specific elements within the QSpec used in the new 735 model. See [I-D.ietf-nsis-qspec] for details. 737 The introduction of new QoS models is designed to enable deployment 738 of NSIS-based QoS control in specific scenarios. One such example is 739 the Integrated Services Controlled Load Service for NSIS 741 [I-D.kappler-nsis-qosmodel-controlledload]. 743 A key feature provided by defining the QSpec template is support of a 744 common language for describing QoS requirements and capabilities, 745 which can be reused by any QoS models intending to use the QoS NSLP 746 to signal their requirements for traffic flows. The commonality of 747 the QSpec parameters ensures a certain level of interoperability of 748 QoS models and reduces the demands on hardware that has to implement 749 the QoS control. Optional QSpec parameters support the extensibility 750 of the QoS NSLP to other QoS models in the future; new QSpec 751 parameters can be defined in the document that defines a new QoS 752 model. See Sections 4.4 and 7 of [I-D.ietf-nsis-qspec]. 754 The QSpec Template supports situations where the QoS parameters need 755 to be fine-grained, specifically targeted to an individual flow in 756 one part of the network (typically the edge or access part) but might 757 need to be more coarse-grained, where the flow is part of an 758 aggregate (typically in the core of the network). 760 8.5. NAT/Firewall NSLP 762 The NAT/Firewall signaling can be extended broadly in the same way as 763 the QoS NSLP by defining new parameters to be carried in NAT/Firewall 764 NSLP messages. See Section 7 of [I-D.ietf-nsis-nslp-natfw]. No 765 proposals currently exist to fulfill new use cases for the protocol. 767 8.6. New NSLP protocols 769 Designing a new NSLP is both challenging and easy. 771 New signaling applications with associated NSLPs can be defined to 772 work in parallel or replace the applications already defined by the 773 NSIS working group. Applications that fit into the NSIS framework 774 will be expected to use GIST to provide transport of signaling 775 messages and appropriate security facilities which relieves the 776 application designer of many "lower level" problems. GIST provides 777 many important functions through its service layer API, and allows 778 the signaling application programmer to offload, e.g., the channel 779 security, transport characteristics and signaling node discovery to 780 GIST. 782 Yet, on the other hand, the signaling application designer must take 783 into account that the network environment can be dynamic, both in 784 terms of routing and node availability. The new NSLP designer must 785 take into account at least the following issues: 787 o Routing changes, e.g., due to mobility: GIST sends Network 788 Notifications when something happens in the network, e.g., peers 789 or routing paths change. All signaling applications must be able 790 to handle these notifications and act appropriately. GIST does 791 not include logic to figure out what the NSLP would want to do due 792 to a certain network event. Therefore, GIST gives the 793 notification to the application, and lets it make the right 794 decision. 795 o GIST indications: GIST will also send other notifications, e.g., 796 if a signaling peer does not reply to refresh messages, or a 797 certain NSLP message was not successfully delivered to the 798 recipient. Again, NSLP applications must be able to handle these 799 events, too. Appendix B in the GIST specification discusses the 800 GIST-NSLP API and the various functionality required, but 801 implementing this interface can be quite challenging; the 802 multitude of asynchronous notifications than can from GIST 803 increases the implementation complexity of the NSLP. 804 o Lifetime of the signaling flow: NSLPs should inform GIST when a 805 flow is no longer needed using the SetStateLifetime primitive. 806 This reduces bandwidth demands in the network. 807 o NSLP IDs: NSLP messages may be multiplexed over GIST MAs. The new 808 NSLP needs to use a unique NSLPID to ensure that its messages are 809 delivered to the correct application by GIST. A single NSLP could 810 use multiple NSLPIDs, for example to distinguish different classes 811 of signaling nodes that might handle different levels of 812 aggregation of requests or alternative processing paths. 813 o Source IP address: It is sometimes challenging to find out at the 814 NSLP, what will the source IP address be, especially when a node 815 has multiple interfaces. Moreover, the logic in specifying the 816 source IP address may differ if the node processing an NSLP 817 message is the source of the signaling flow, or an intermediate 818 node on the signaling. Thus, the NSLP must be able to find out 819 the right source IP address from its internal interfaces, and its 820 location on the signaling. 821 o New MRMs: GIST defines currently two Message Routing Methods, and 822 leave the door open for new ideas. Thus, it is possible that a 823 new NSLP also requires a new MRM, path-decoupled routing being one 824 example. 825 o Cooperation with other NSLPs: Some applications might need 826 resources from two or more different classes in order to operate 827 successfully. The NSLPs managing these resources could operate 828 cooperatively to ensure that such requests were coordinated to 829 avoid wasting signaling bandwidth and prevent race conditions. 831 The API between GIST and NSLPs (see Appendix B in 832 [I-D.ietf-nsis-ntlp]) is very important to understand. The abstract 833 design in the GIST specification does not specify the exact messaging 834 between GIST and the NSLPs but gives an understanding of the 835 interactions, especially what kinds of asynchronous notifications 836 from GIST the NSLP must be prepared to handle: the actual interface 837 will be dependent on each implementation of GIST. 839 Messages transmitted by GIST on behalf of an NSLP are identified by a 840 unique NSLP identifier (NSLPID). NSLPIDs are 16 bit unsigned numbers 841 taken from a registry managed by IANA and defined in Section 9 of the 842 GIST specification [I-D.ietf-nsis-ntlp]. 844 A range of values (32704-32767) is available for Private and 845 Experimental use during development, but any new signaling 846 application that expects to be deployed generally on the Internet 847 needs to be defined either in a standards track RFC or, possibly, an 848 experimental RFC. Such an RFC would request allocation of unique 849 NSLPID value(s) from the IANA registry. There is additional 850 discussion of NSLPIDs in Section 3.8 of the GIST specification. 852 9. Security Considerations 854 This document provides information to the community. It does not 855 raise new security concerns. 857 10. IANA Considerations 859 This memo includes no request to IANA. 861 11. Acknowledgements 863 This document combines work previously published as two separate 864 drafts: "What is Next Steps in Signaling anyway - A User's Guide to 865 the NSIS Protocol Family" written by Roland Bless and Jukka Manner, 866 and "NSIS Extensibility Model" written by John Loughney. 868 Max Laier, Nuutti Varis and Lauri Liuhto have provided reviews of 869 "User's Guide" draft and valuable input. 871 The "Extensibility Model" borrowed some ideas and some text from 872 RFC3936 [RFC3936], Procedures for Modifying the Resource ReSerVation 873 Protocol (RSVP); Robert Hancock provided text for the original GIST 874 section, since much modified and Claudia Keppler have provided 875 feedback on this draft, while Allison Mankin and Bob Braden suggested 876 that this draft be worked on. 878 12. References 879 12.1. Normative References 881 [I-D.ietf-nsis-nslp-natfw] 882 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 883 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 884 draft-ietf-nsis-nslp-natfw-20 (work in progress), 885 November 2008. 887 [I-D.ietf-nsis-ntlp] 888 Schulzrinne, H. and R. Hancock, "GIST: General Internet 889 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 890 progress), October 2008. 892 [I-D.ietf-nsis-qos-nslp] 893 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 894 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 895 (work in progress), February 2008. 897 [I-D.ietf-nsis-qspec] 898 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 899 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 900 progress), April 2008. 902 [RFC3726] Brunner, M., "Requirements for Signaling Protocols", 903 RFC 3726, April 2004. 905 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 906 Bosch, "Next Steps in Signaling (NSIS): Framework", 907 RFC 4080, June 2005. 909 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 910 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 912 12.2. Informative References 914 [I-D.bless-nsis-est-mrm] 915 Bless, R., "An Explicit Signaling Target Message Routing 916 Method (EST-MRM) for the General Internet Signaling 917 Transport (GIST) Protocol", draft-bless-nsis-est-mrm-01 918 (work in progress), July 2008. 920 [I-D.bless-nsis-resv-aggr] 921 Doll, M. and R. Bless, "Inter-Domain Reservation 922 Aggregation for QoS NSLP", draft-bless-nsis-resv-aggr-01 923 (work in progress), July 2007. 925 [I-D.braden-2level-signal-arch] 926 Braden, R. and B. Lindell, "A Two-Level Architecture for 927 Internet Signaling", draft-braden-2level-signal-arch-01 928 (work in progress), November 2002. 930 [I-D.cordeiro-nsis-hypath] 931 Cordeiro, L., Curado, M., Monteiro, E., Bernardo, V., 932 Palma, D., Racaru, F., Diaz, M., and C. Chassot, "GIST 933 Extension for Hybrid On-path Off-path Signaling (HyPath)", 934 draft-cordeiro-nsis-hypath-05 (work in progress), 935 February 2008. 937 [I-D.kappler-nsis-qosmodel-controlledload] 938 Kappler, C., Fu, X., and B. Schloer, "A QoS Model for 939 Signaling IntServ Controlled-Load Service with NSIS", 940 draft-kappler-nsis-qosmodel-controlledload-08 (work in 941 progress), August 2008. 943 [I-D.manner-nsis-gist-dccp] 944 Manner, J., "Generic Internet Signaling Transport over 945 DCCP and DTLS", draft-manner-nsis-gist-dccp-00 (work in 946 progress), June 2007. 948 [I-D.manner-nsis-nslp-auth] 949 Manner, J., Stiemerling, M., Tschofenig, H., and R. Bless, 950 "Authorization for NSIS Signaling Layer Protocols", 951 draft-manner-nsis-nslp-auth-04 (work in progress), 952 July 2008. 954 [I-D.manner-nsis-peering-data] 955 Manner, J., Liuhto, L., Varis, N., and T. Huovila, 956 "Peering Data for NSIS Signaling Layer Protocols", 957 draft-manner-nsis-peering-data-01 (work in progress), 958 February 2008. 960 [I-D.rahman-rtg-router-alert-dangerous] 961 Rahman, R. and D. Ward, "Use of IP Router Alert Considered 962 Dangerous", draft-rahman-rtg-router-alert-dangerous-00 963 (work in progress), October 2008. 965 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 966 Services in the Internet Architecture: an Overview", 967 RFC 1633, June 1994. 969 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 970 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 971 Functional Specification", RFC 2205, September 1997. 973 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 974 Considered Useful", BCP 82, RFC 3692, January 2004. 976 [RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the 977 Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, 978 October 2004. 980 [RFC4094] Manner, J. and X. Fu, "Analysis of Existing Quality-of- 981 Service Signaling Protocols", RFC 4094, May 2005. 983 Authors' Addresses 985 Jukka Manner 986 Helsinki University of Technology (TKK) 987 P.O. Box 3000 988 Espoo FIN-02015 TKK 989 Finland 991 Phone: +358 9 451 2481 992 Email: jukka.manner@tkk.fi 993 URI: http://www.netlab.tkk.fi/~jmanner/ 995 Roland Bless 996 Institute of Telematics, Universitaet Karlsruhe (TH) 997 Zirkel 2 998 Karlsruhe 76128 999 Germany 1001 Phone: +49 721 608 6413 1002 Email: bless@tm.uka.de 1003 URI: http://www.tm.uka.de/~bless 1005 John Loughney 1006 Nokia 1007 955 Page Mill Road 1008 Palo Alto 94303 1009 USA 1011 Phone: +1 650 283 8068 1012 Email: john.loughney@nokia.com 1013 Elwyn Davies (editor) 1014 Folly Consulting 1015 Soham, 1016 UK 1018 Phone: 1019 Fax: 1020 Email: elwynd@folly.org.uk 1021 URI: http://www.folly.org.uk 1023 Full Copyright Statement 1025 Copyright (C) The IETF Trust (2008). 1027 This document is subject to the rights, licenses and restrictions 1028 contained in BCP 78, and except as set forth therein, the authors 1029 retain all their rights. 1031 This document and the information contained herein are provided on an 1032 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1033 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1034 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1035 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1036 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1037 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1039 Intellectual Property 1041 The IETF takes no position regarding the validity or scope of any 1042 Intellectual Property Rights or other rights that might be claimed to 1043 pertain to the implementation or use of the technology described in 1044 this document or the extent to which any license under such rights 1045 might or might not be available; nor does it represent that it has 1046 made any independent effort to identify any such rights. Information 1047 on the procedures with respect to rights in RFC documents can be 1048 found in BCP 78 and BCP 79. 1050 Copies of IPR disclosures made to the IETF Secretariat and any 1051 assurances of licenses to be made available, or the result of an 1052 attempt made to obtain a general license or permission for the use of 1053 such proprietary rights by implementers or users of this 1054 specification can be obtained from the IETF on-line IPR repository at 1055 http://www.ietf.org/ipr. 1057 The IETF invites any interested party to bring to its attention any 1058 copyrights, patents or patent applications, or other proprietary 1059 rights that may cover technology that may be required to implement 1060 this standard. Please address the information to the IETF at 1061 ietf-ipr@ietf.org.