idnits 2.17.1 draft-mcdonald-nsis-ntlp-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 738 has weird spacing: '...ons for modif...' -- 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 (January 23, 2003) is 7736 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 708, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-nsis-fw-01 == Outdated reference: A later version (-09) exists of draft-ietf-nsis-req-06 -- Obsolete informational reference (is this intentional?): RFC 896 (ref. '3') (Obsoleted by RFC 7805) == Outdated reference: A later version (-01) exists of draft-schulzrinne-nsis-casp-00 == Outdated reference: A later version (-01) exists of draft-westberg-nsis-rsvp-as-ntlp-00 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. McDonald 3 Internet-Draft R. Hancock 4 Expires: July 24, 2003 E. Hepworth 5 Siemens/Roke Manor Research 6 January 23, 2003 8 Design Considerations for an NSIS Transport Layer Protocol 9 draft-mcdonald-nsis-ntlp-considerations-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 24, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 A framework for NSIS is in preparation, and will identify a split 40 into two layers. The lower layer, referred to as the NSIS Transport 41 Layer Protocol (NTLP) provides generic support for different types of 42 path coupled signalling, including QoS signalling. This document 43 discusses issues to be considered in the design of an NSIS Transport 44 Layer Protocol (NTLP). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Transport Functionality Issues . . . . . . . . . . . . . . . 3 50 2.1 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . 4 51 2.2 Message Bundling . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3 Message vs. Stream based transports . . . . . . . . . . . . 5 53 2.4 Message fragmentation . . . . . . . . . . . . . . . . . . . 5 54 2.5 Message reordering and Head of line blocking . . . . . . . . 6 55 2.6 Duplicate Message Detection . . . . . . . . . . . . . . . . 6 56 2.7 Lossless Transport and Loss Detection . . . . . . . . . . . 6 57 2.8 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Routing and Discovery . . . . . . . . . . . . . . . . . . . 7 59 3.1 Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.2 Path Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.3 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8 62 3.4 Path Divergence . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4.1 Signalling/Data Path Divergence . . . . . . . . . . . . . . 8 64 3.4.2 Path Divergence Through Rerouting . . . . . . . . . . . . . 9 65 4. NAT and Firewall Traversal . . . . . . . . . . . . . . . . . 10 66 5. State Location . . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Overload Protection . . . . . . . . . . . . . . . . . . . . 12 68 7. Failure detection and Failover . . . . . . . . . . . . . . . 12 69 8. Feedback/Error Messages . . . . . . . . . . . . . . . . . . 12 70 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 9.1 Message Protection . . . . . . . . . . . . . . . . . . . . . 14 72 9.2 Denial of Service Protection . . . . . . . . . . . . . . . . 14 73 10. Message Objects and Extensibility . . . . . . . . . . . . . 14 74 11. Other Functionality . . . . . . . . . . . . . . . . . . . . 15 75 11.1 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 11.2 Inter/Intra Domain Use . . . . . . . . . . . . . . . . . . . 15 77 11.3 Mobility Support . . . . . . . . . . . . . . . . . . . . . . 15 78 11.4 Session/State Identification . . . . . . . . . . . . . . . . 15 79 12. Security Considerations . . . . . . . . . . . . . . . . . . 15 80 Informative References . . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 82 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 This document assumes the framework as discussed in [1]. In 87 particular, the NSIS framework defines high level issues of how the 88 NTLP overall interacts with other protocols (e.g. routing and 89 mobility issues) and how it is used to support signalling 90 applications, and defines the overall functionality that the NTLP 91 should support. (The precise functionality required of the NTLP has 92 not been finally defined, and might be impacted by some of the design 93 considerations given here. It is always possible to argue that a 94 particular design question is irrelevant since the corresponding 95 function is not necessary in the first place.) The focus for this 96 document is primarily internal aspects of the NTLP design, although 97 these can be strongly influenced by usage scenarios (especially in 98 performance aspects). Overall requirements for signalling protocols 99 are given in [2]. 101 The original proposal for a split layer signalling protocol has been 102 given in [9], which also contains extensive discussion of the design 103 rationale for CSTP, which is the proposed NTLP there. There are 104 additional proposals for the NTLP with accompanying design rationale, 105 e.g. CASP [11] and direct re-use of RSVP [12]. 107 The purpose of this document is not to analyse all the design options 108 and fix a particular approach for the NTLP, but initially simply to 109 consolidate the questions and issues that have to be considered. 111 The pattern for the sections in this document is something like: 113 o Identify issues that the NTLP must address 115 o Identify some of the applicable techniques and their implications 117 o Illustrate how these techniques relate to using existing protocols 118 (especially the case of RSVP) 120 2. Transport Functionality Issues 122 This section considers 'traditional' transport layer functions such 123 as reliability, congestion management and so on. In the NSIS protocol 124 suite, these functions are primarily the responsibility of the NTLP. 126 One overall question when considering transport layer issues is: 127 should we use an already existing, standard transport protocol (e.g. 128 TCP or SCTP) or not? 130 Do different parts of the NTLP behaviour have different requirements? 131 And, consequently do different parts of the NTLP require different 132 choices to be made about whether to use a standard or custom 133 transport protocol? 135 Usability of existing transport layers for AAA traffic is analysed in 136 [14] and some of the same issues may be relevant here. 138 A significant issue for deciding what transport functionality the 139 NTLP should provide is that communication between NSLP peers might be 140 performed over a single NTLP hop, or a series of concatenated NTLP 141 hops (if there are intervening NSIS entities which do not process the 142 relevant signalling application). In the former case, rigorous 143 end-to-end thinking pushes more functionality out of the NTLP and 144 into the NSLP. 146 2.1 Congestion Avoidance 148 The NTLP must provide congestion control mechanisms (e.g. as 149 described in [6]). This might be provided in a specialised way as 150 part of a custom protocol directly over IP. Alternatively, an 151 existing protocol which already provides congestion control, such as 152 TCP or SCTP might be used to carry NTLP. 154 The base RSVP protocol contains no congestion control mechanism. 155 Exponential back-off procedures for RSVP are described in section 6 156 of RFC2961 [7]. 158 If using TCP or SCTP, will the standard transport parameter 159 estimation algorithms function correctly? More generally, does 160 signalling have specialised requirements for congestion handling (and 161 if it does, is it signalling application specific? - in which case, 162 should this reside in the NSLP rather than the NTLP?) 164 2.2 Message Bundling 166 There are two aspects to the possible provision of bundling in 167 relation to the NTLP. Should a single NTLP PDU be able to carry 168 multiple NSLP PDUs (including from different, possibly unrelated, 169 signalling applications)? Should it be possible to bundle multiple 170 NTLP PDUs into a single IP datagram (or TCP segment, or SCTP chunk)? 171 Note that unless bundling is done only for messages relating to flows 172 between the same endpoints (which would be a very restrictive case), 173 bundling almost necessarily involves direct ('peer-to-peer') 174 addressing and hence means additional consideration must be given to 175 prevention of path divergence (see Section 3.4). 177 In order to reduce the per signalling PDU overhead, a message 178 bundling mechanism is provided within RSVP [7]. Because of the 179 divergence issue, the restriction is made that they can only be used 180 between direct RSVP neighbours, in order to avoid unnoticed path 181 divergence as described in Section 3.4. (This suggests the need for 182 an explicit discovery of whether the next node is a direct 183 neighbour.) How likely is it that NSLP peers will be direct NTLP 184 peers (as compared to being separated by more than one NTLP 'hop')? 186 If an existing transport protocol is used under the NTLP, then 187 message bundling may exist as part of that protocol. Both TCP and 188 SCTP support the use of Nagle's algorithm [3] (or a similar 189 technique), which allows pieces of data from higher layers to be 190 'bundled' into a single IP packet. Is such a technique appropriate 191 for NSIS messages? (In particular, are the timing rules implicit in 192 these algorithms appropriate for signalling messages?) 194 2.3 Message vs. Stream based transports 196 The NTLP is message orientated by nature. If it is carried over a 197 stream-based transport such as TCP then the NTLP needs to be able to 198 split it out back into individual messages. If a datagram or 199 message-based transport (such as SCTP, IP or UDP) is used then this 200 provides the necessary message framing already. 202 The separate issue of upper layer multiplexing is covered in Section 203 10. 205 2.4 Message fragmentation 207 The NTLP must be capable of performing message fragmentation when the 208 amount of data in a message to be sent is larger than can fit into a 209 single IP packet (or a single sensibly-sized IP packet). This may 210 occur, for example, where certificates are carried in order to 211 support authentication functions, and also in order to support 212 features of future NSLPs. 214 IP fragmentation might be used to provide the NTLP message 215 fragmentation. In this case the protocol must perform Path MTU 216 Discovery for IPv6 and should support it for IPv4. (If end-to-end 217 addressing was used, it is not clear that Path MTU discovery would 218 function correctly, e.g. if an NSIS entity which was not one of the 219 flow endpoints needed to perform it.) IP fragmentation is only 220 supported end-to-end in IPv6. 222 If TCP or SCTP is used to carry NTLP messages, then fragmentation/ 223 segmentation is provided by these protocols, and PMTU-D can be 224 expected to be supported as standard. 226 2.5 Message reordering and Head of line blocking 228 Can messages arrive out-of-order at the NTLP from lower layers (e.g. 229 if the NTLP is carried directly over IP or UDP)? If so, does it 230 matter at the NTLP? Does the NTLP need to be able to re-order the 231 messages correctly? 233 Does the NTLP have to guarantee to pass messages in order to the 234 local NSLP? Or, should it be left to the NSLP to decide whether to 235 process, re-order or drop messages? How generic to signalling 236 applications is the requirement for in-order delivery? 238 In addition, would head-of-line blocking be a problem for the NSIS 239 protocols? 241 TCP could used to carry NTLP messages. One way to use it would be to 242 have a single TCP connection between each pair of NSIS peers, but 243 this would result in head-of-line blocking (across multiple 244 signalling sessions). Could more than one TCP connection be used to 245 mitigate this? 247 SCTP is another alternative for carrying NTLP messages. SCTP supports 248 multiple streams within an association. SCTP also supports reliable 249 delivery of out of order delivery of messages (though this feature is 250 unavailable when TLS is being used). 252 In the base RSVP protocol there are no sequence numbers in the 253 messages. Consequently there is no method to detect out-of-order 254 delivery or duplicate messages. Out-of-order delivery can still be 255 allowed when the RSVP Cryptographic Authentication mechanism [5] is 256 used, although replay protection is provided. 258 2.6 Duplicate Message Detection 260 Do we care about receiving duplicate messages at the NTLP, or is this 261 purely an NSLP problem? 263 Are security concerns about message replay addressed? (see Section 264 9). 266 2.7 Lossless Transport and Loss Detection 268 How is identification of message loss and/or retransmission provided? 270 Should the NTLP actually provide true lossless transport end-to-end, 271 or simply local recovery (peer-to-peer) from messages which can be 272 detected to have been dropped (e.g. because of congestion)? 274 2.8 Other Issues 276 It may be useful for lower layer information to be visible at the 277 NTLP. For example, changes in the TTL of received packets may be an 278 indication that a route change has occurred, or the TTL may need to 279 be controlled explicitly. Given existing implementation constraints, 280 does this have implications for what encapsulation should be used 281 (e.g. does it imply the use of raw IP sockets)? 283 3. Routing and Discovery 285 3.1 Peer Discovery 287 Addressing of NTLP messages can be peer-to-peer or end-to-end, as 288 discussed in section 3.3.4 of [1]. 290 Peer discovery in the data receiver to sender direction is not 291 required (see the sender/receiver oriented issues discussed in [10]). 293 In the downstream direction, the NTLP is required to perform peer 294 discovery (at least implicitly), in addition to transporting NSLP 295 messages along the data path. Are the messages for discovery 296 integrated into the rest of the NTLP protocol? Or, is the discovery 297 mechanism separated from the transport of NSLP messages, for example, 298 as a dedicated message exchange? Should the NTLP be able to accept 299 alternative source of information about which peer to talk to? 301 For the discovery mechanism, how similar are the signalling and data 302 messages? (see discussion in Section 3.4). 304 Some NTLP entities also terminate the signalling transport (e.g. when 305 acting as a proxy on behalf of an end-system). How do you detect that 306 you are the last NTLP entity before the data receiver? What if there 307 are more NTLP entities, but none with the relevant NSLP? 309 RSVP uses end-to-end addressing in some of its messages, and makes 310 use of the IPv4 router alert option (or IPv6 hop-by-hop option) to 311 inform routers that they should intercept and process the messages. 312 Further details are discussed in section 4.1 of [1]. 314 3.2 Path Discovery 316 The NTLP does not provide an explicit topology or path discovery 317 service to the NSLP. It does, however, carry out implicit path 318 discovery simply by being able to route from one NTLP hop to the 319 next. 321 Is the state necessary for backwards routing stored locally at each 322 node, or carried in route record objects (see further discussion in 323 Section 5). 325 3.3 Capability Discovery 327 The NTLP needs to consider Capability Discovery and/or Exchange and/ 328 or Agreement. What sort of things appear as "capabilities"? - 329 signalling applications (i.e. NSLPs), types of signalling 330 application, supported features, options, etc? 332 RSVP can use AdSpec objects to learn information from nodes along a 333 path primarily for QoS purposes, although the same mechanism could be 334 generalised for other purposes. There is no mechanism for learning 335 about the capabilities, security mechanism, supported security 336 options, identity, etc of peers. 338 What is the split between the NTLP and NSLPs for capability discovery 339 mechanisms? What form do the "capabilities" take? 341 3.4 Path Divergence 343 Two forms of path divergence must be considered. Firstly, path 344 divergence may occur when NSIS signalling is sent down a different 345 route to the main data flow, for example due to policy forwarding 346 being used to select the route for the data flow. Secondly, path 347 divergence may occur during the life of a reservation when rerouting 348 occurs, with the data flow going down a new path, but signalling 349 state persisting on the old path, and possibly signalling messages 350 continuing to use the old path. 352 3.4.1 Signalling/Data Path Divergence 354 Divergence may occur when policy forwarding is used which takes 355 account of protocol, transport layer ports, DSCP, etc. in determining 356 the route for packets. This is of most concern when the initial 357 signalling connections are being established, but is also of 358 relevance when rerouting of the data flow occurs. Therefore, the 359 manner in which this should be addressed in the NTLP needs to be 360 considered. 362 Can path divergence be reduced at NSIS-aware nodes, since the node 363 knows about both the data flow and the NSIS signalling messages? i.e. 364 can it look at the flow identifier in the NTLP messages and calculate 365 the next hop directly from this, rather than constructing the NTLP 366 message and then routing normally? 368 At NSIS-unaware nodes performing policy forwarding the data and 369 signalling flows are more likely to diverge since the node is unaware 370 that they are related. The only real countermeasure is to make the 371 path selecting messages of the NSIS protocol look as much like the 372 data flow packets as possible (e.g. same source/destination 373 addresses, same DSCP, etc.). 375 The RSVP protocol does not attempt to directly tackle this form of 376 path divergence in the case of policy forwarding. 378 How should the NTLP tackle this form of path divergence? For example, 379 should the 'discovery' messages be made to look like the data flow? 381 3.4.2 Path Divergence Through Rerouting 383 When rerouting occurs the signalling data may continue to be sent 384 along the old route (particularly if signalling data is addressed 385 directly between NSIS peers). The NTLP should be capable of detecting 386 this and performing rerouting as required. How should NSIS entities 387 detect route changes, and how quickly should they react? 389 Some RSVP messages, such as Path messages, are addressed to the data 390 destination, and can usually be used to detect when rerouting of the 391 signalling path has occurred. RSVP assumes that this indicates also a 392 rerouting of the data flow. 394 In other cases (e.g. Resv and Bundle messages), the RSVP messages are 395 addressed directly to an RSVP neighbour. These cannot detect route 396 changes. In fact, it is forbidden to use Bundle messages when changes 397 in the next hop cannot be detected. 399 Since an NSIS capable router would also have the related data traffic 400 passing through it, can it use this information to detect when this 401 data flow 'disappears' due to rerouting and determine that the data 402 path has changed? 404 How should the NTLP work to ensure timely identification of route 405 changes to a data flow? Possibilities for route change identification 406 include: 408 o Local detection (e.g. routing local repair) 410 o Remote detection (e.g. by signalling application) 412 o Sending of (un-bundled) downstream signalling messages (basic RSVP 413 approach) 415 o Sending explicit signalling to verify the next peer identity (CASP 416 approach) 418 How should the NTLP react to data path changes? Should the protocol 419 explicitly define the state management (e.g. hold-down timers) 420 necessary to prevent spurious signalling, or should it assume this is 421 done 'externally' and react promptly itself? e.g. RSVP message 422 processing rules include such rules for processing Path messages to 423 mitigate route flapping problems. On the other hand, if the route 424 change is caused by a mobility event [13] a prompt reaction is 425 essential. Should the NTLP include different variants of peer 426 discovery messages to handle this type of issue? Is the selection of 427 a variant influenced by the NSLP being used? 429 4. NAT and Firewall Traversal 431 The NTLP/NSLP carry flow identifying information in their payloads. 432 This causes some 'NAT-unfriendliness', since the NAT must change 433 these payloads to reflect the way it has (or will) translate the data 434 flows. 436 For correct NAT traversal of RSVP packets the NAT must be able to 437 understand a number of RSVP object classes, including session 438 objects, hop objects, error specification objects, filter 439 specification objects, reservation confirmation objects. 441 NAT issues for RSVP are discussed in section 4.2 of [8], where the 442 need for an RSVP-ALG (Application Layer Gateway) is identified, as is 443 the fact that this will not work when RSVP Integrity objects are 444 being used. 446 Is it desirable to be able to support NSIS-aware NATs without them 447 requiring full NSIS support with a MIDCOM NSLP, and when NTLP is 448 being used for a flow without using a MIDCOM NSLP (i.e. when using 449 NSLPs other than MIDCOM)? Is it desirable to place any objects that 450 may need to be manipulated by the NAT in the NTLP, so that new NSLPs 451 can be defined without requiring modifications to the NAT? 453 If the NTLP is carried over TCP or SCTP, then flow state can be 454 expected to already be handled in most NATs and stateful firewalls. 455 Will an NTLP-ALG or NTLP entity in the NAT be used to perform the 456 translation on flow identifiers carried by the protocol? 458 5. State Location 460 The NSIS protocols will establish state along the signalling path. 461 One component of this is application state (which is relevant to the 462 NSLP). Also, there may be message transport state (which could be 463 hidden inside the NTLP). How are these state components related, and 464 what dependencies are there between the two parts? 465 Should the NTLP be directly or indirectly involved in managing NSLP 466 state? 468 What state should be held in the NTLP (if any)? And, what state 469 should be held by the various NSLPs? Should state held at the NTLP be 470 soft state? Can multiple NSLP states (from a single NSLP or different 471 NSLPs) be associated with a single NTLP "session"? What is the 472 relationship between the state lifetime at the NTLP and NSLP? 474 The concept of a split between 'NTLP' and 'NSLP' parts does not exist 475 in RSVP, so no prior implementation or design experience can be 476 gleaned from RSVP on this issue. 478 It is necessary to consider where to put state in the network. For 479 this it is necessary to consider whether the NTLP should be optimised 480 for (a) low latency at signalling start-up, or (b) low latency on 481 route changes. Based on the answer to that question, the protocol 482 might need to keep state either (a) at the edge of the network, or 483 (b) in the core (i.e. close to where the change occurs). 485 NTLP state identified within this draft, includes: 487 o Peer state, which includes: 489 * Presence 491 * Capabilities 493 * Status 495 * Negotiated parameters 497 o Routing state, including: 499 * Next hops 501 * Previous hops 503 o Security related state 505 o Session and flow identification 507 o NTLP configuration, such as: 509 * State for duplicate detection 511 * Data for potential retransmission 512 * RTT for congestion control 514 * Path MTU 516 How much state is needed for the protocol to work? 518 How much state is needed for the protocol to work efficiently? 520 How much state is needed for the error handling? 522 Should the NTLP do any merging of states/messages itself? Does the 523 NTLP perform "lazy forwarding" (e.g. in the style of RSVP with 524 refresh reduction, where messages representing a state change are 525 forwarded immediately, but refreshes can be sent as part of a summary 526 refresh)? Or, are these NSLP issues? In particular, if the NTLP does 527 not perform state management, then it cannot offer this type of 528 functionality. 530 6. Overload Protection 532 Protection against overload caused for malicious purposes is 533 discussed in Section 9.2. 535 What mechanisms should the NTLP provide to protect against overload 536 during normal use? 538 What overload protection capability the NTLP should provide as part 539 of the service for NSLPs? For example, should it provide flow 540 control? 542 7. Failure detection and Failover 544 The handling of re-routing to avoid path divergence is discussed in 545 Section 3.4.2, and has different requirements to the need to handle 546 NTLP failures. 548 Should the NTLP be able to detect and handle failures (e.g. lost NTLP 549 entities) itself? 551 Even if the NTLP does not perform failover itself, should it be 552 designed to allow easy failover by an NSLP? What are the constraints 553 on the NTLP that come from this? 555 Is a technique similar to the BGP Graceful Restart appropriate to 556 avoid rerouting and route flap when an NSIS entity restarts? 558 8. Feedback/Error Messages 559 What error conditions are relevant at the NTLP? 561 The NSIS protocols must support "transport" related errors and NSLP 562 (e.g. QoS) errors. RSVP does not make a (structural) distinction 563 between the two. 565 An example of an NTLP to NSLP (i.e. generated by an NTLP but consumed 566 by an NSLP) error message is an 'NSLP unreachable' message. It may be 567 that this is the only NTLP to NSLP error message, with other error 568 messages being either NTLP to NTLP or NSLP to NSLP. 570 Should the NTLP provide error handling functions on behalf of the 571 NSLPs? Or, must an NSLP handle errors itself? 573 What about ICMP errors (e.g. where an NTLP message is sent to a node 574 that doesn't support NTLP)? Are these correctly addressed? For 575 example, consider the case where an intermediate node between two 576 end-points sends out a message with the end-point addresses as the 577 source and destination (to avoid path divergence). What happens if 578 this results in an ICMP error message from further downstream? (This 579 error message will be sent to the source, but is actually of interest 580 to the intermediate node.) 582 How are ICMP errors processed in relation to the NTLP? (e.g. consider 583 UDP related ICMP port unreachable vs TCP RST processing) 585 Are errors sent hop-by-hop or not? For some types of error only the 586 originator of the message to which the error is a response should 587 process the error, in other cases it may be desirable for error 588 messages to affect state at intermediate entities. The latter 589 requires hop-by-hop error handling, the former case can be handled 590 either hop-by-hop or by direct addressing to the message originator. 591 An example of non-hop-by-hop message is the Notification message in 592 RSVP-TE which is transmitted directly to the source. 594 Is there a distinction between an NSLP path teardown and an NTLP 595 session termination? Does removing (for example) QoS reservation 596 state automatically remove path state, or is an explicit path 597 teardown required? Does a path teardown remove reservation state 598 automatically? 600 9. Security 602 It is assumed that at the NTLP layer the only security concerns are 603 for message protection and overload protection (protection against 604 malicious traffic), including the internal or external key management 605 mechanisms to support this. 607 It should be noted that the security mechanisms for the NTLP are 608 contingent on other aspects of the design. 610 9.1 Message Protection 612 Should the NTLP use an existing security mechanism (e.g. IPsec or 613 TLS)? Or, should a new security mechanism be developed for the NTLP 614 (e.g. in the style of the RSVP integrity mechanism)? 616 Should we reuse an existing key exchange protocol, or write our own? 617 (e.g. if rolling our own integrity protection mechanism) 619 How much flexibility does the security mechanism need to have? Should 620 the NTLP protocol specify a single solution for the complete security 621 problem? Or, are some parts of the NTLP operation different to others 622 (and so need different security mechanisms)? 624 How are nodes identified? How is identity information securely 625 exchanged? 627 9.2 Denial of Service Protection 629 Should the NTLP provide protection against flooding attacks itself? 630 Or, is it sufficient to rely on lower layers (e.g. SCTP cookies, IKE 631 cookies)? 633 Who is made to "work hard" during an attack? Is the flooder made to 634 suffer in any way? Where does the "attack" come from (e.g. can it be 635 forwarded down a series of NSIS entities)? Are the initial messages 636 sufficiently cheap that such attacks have little effect (e.g. what 637 state do they create)? 639 10. Message Objects and Extensibility 641 It is currently undecided whether any of the RSVP objects [15] 642 should be reused for the NTLP. 644 The message formatting may be required to support new NTLP message 645 types. Other protocols have used techniques such as marking objects 646 "optional" or "critical" to provide support for this. 648 RSVP allows unknown classes to be handled in different ways: the 649 entire message may rejected, the object may be ignored and not 650 forwarded, or the object may be ignored and forwarded. Unknown types 651 of object within a known class generally result in an error being 652 sent back. However, certain objects which are opaque to RSVP (e.g. 653 FLOWSPEC, ADSPEC, and POLICY_DATA) can be passed on to the relevant 654 module for a decision to be made. 656 The NTLP also needs to be able to handle new upper layer 'things'. It 657 is an open question as to whether these are specified as new 658 signalling applications, new types of signalling application, new 659 capabilities, additional optional aspects of a signalling 660 application, etc. 662 An NTLP is expected to be able to support multiple signalling 663 applications (e.g. QoS and MIDCOM). It is to be decided whether these 664 must be supported at the same time (both in the same NTLP message, or 665 both related to the same NTLP 'session' identifier). 667 11. Other Functionality 669 11.1 Scoping 671 Is it necessary to be able to specify a scope for a message (or 672 individual objects) in the NTLP? (Or, is the purely an NSLP concept?) 674 11.2 Inter/Intra Domain Use 676 Are there different modes of operation for intra/inter domain use? 677 How is this performed (e.g. having some functionality made optional 678 and only used in a particular mode of operation)? 680 11.3 Mobility Support 682 Mobility related issues are still to be considered. See [13] for some 683 discussion. 685 11.4 Session/State Identification 687 Issues relating session/state identification (including their 688 relationship to flow identification) are still to be considered. 690 12. Security Considerations 692 This design considerations document raises no security considerations 693 in and of itself. Design considerations relating to the security of 694 an NTLP protocol are given in Section 9. 696 Informative References 698 [1] Hancock, R. and I. Freytsis, "Next Steps in Signaling: 699 Framework", draft-ietf-nsis-fw-01 (work in progress), November 700 2002. 702 [2] Brunner, M., "Requirements for Signaling Protocols", 703 draft-ietf-nsis-req-06 (work in progress), December 2002. 705 [3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 706 896, January 1984. 708 [4] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 709 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 710 Specification", RFC 2205, September 1997. 712 [5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic 713 Authentication", RFC 2747, January 2000. 715 [6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 716 September 2000. 718 [7] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. 719 Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 720 2961, April 2001. 722 [8] Holdrege, M. and P. Srisuresh, "Protocol Complications with the 723 IP Network Address Translator", RFC 3027, January 2001. 725 [9] Braden, R. and B. Lindell, "A Two-Level Architecture for 726 Internet Signaling", draft-braden-2level-signal-arch-01 (work 727 in progress), November 2002. 729 [10] Hancock, R., "Sender and Receiver Orientation Issues in NSIS", 730 draft-hancock-nsis-sender-receiver-00 (work in progress), 731 October 2002. 733 [11] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol", 734 draft-schulzrinne-nsis-casp-00 (work in progress), September 735 2002. 737 [12] Westberg, L., "Using RSVPv1 as NTLP (NSIS Transport Layer 738 Protocol): suggestions for modifications on RFC2205", 739 draft-westberg-nsis-rsvp-as-ntlp-00 (work in progress), January 740 2003. 742 [13] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", 743 draft-thomas-nsis-rsvp-analysis-00 (work in progress), November 744 2002. 746 [14] Aboba, B. and J. Wood, "Authentication, Authorization and 747 Accounting (AAA) Transport Profile", 748 draft-ietf-aaa-transport-12 (work in progress), January 2003. 750 [15] 752 Authors' Addresses 754 Andrew McDonald 755 Siemens/Roke Manor Research 756 Old Salisbury Lane 757 Romsey, Hampshire SO51 0ZN 758 United Kingdom 760 EMail: andrew.mcdonald@roke.co.uk 762 Robert Hancock 763 Siemens/Roke Manor Research 764 Old Salisbury Lane 765 Romsey, Hampshire SO51 0ZN 766 United Kingdom 768 EMail: robert.hancock@roke.co.uk 770 Eleanor Hepworth 771 Siemens/Roke Manor Research 772 Old Salisbury Lane 773 Romsey, Hampshire SO51 0ZN 774 United Kingdom 776 EMail: eleanor.hepworth@roke.co.uk 778 Full Copyright Statement 780 Copyright (C) The Internet Society (2003). All Rights Reserved. 782 This document and translations of it may be copied and furnished to 783 others, and derivative works that comment on or otherwise explain it 784 or assist in its implementation may be prepared, copied, published 785 and distributed, in whole or in part, without restriction of any 786 kind, provided that the above copyright notice and this paragraph are 787 included on all such copies and derivative works. However, this 788 document itself may not be modified in any way, such as by removing 789 the copyright notice or references to the Internet Society or other 790 Internet organizations, except as needed for the purpose of 791 developing Internet standards in which case the procedures for 792 copyrights defined in the Internet Standards process must be 793 followed, or as required to translate it into languages other than 794 English. 796 The limited permissions granted above are perpetual and will not be 797 revoked by the Internet Society or its successors or assignees. 799 This document and the information contained herein is provided on an 800 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 801 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 802 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 803 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 804 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 806 Acknowledgement 808 Funding for the RFC Editor function is currently provided by the 809 Internet Society.