idnits 2.17.1 draft-ietf-forces-sctptml-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. 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 abstract seems to contain references ([RFC3654], [RFC2960], [FE-PROTO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 224: '... The TML SHOULD will be able to ...' RFC 2119 keyword, line 617: '...en the CEs and FEs MUST be established...' RFC 2119 keyword, line 627: '...points that implement TLS MUST perform...' 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 (July 14, 2008) is 5764 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) == Missing Reference: 'RFC3768' is mentioned on line 578, but not defined ** Obsolete undefined reference: RFC 3768 (Obsoleted by RFC 5798) == Unused Reference: 'RFC2434' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'FE-MODEL' is defined on line 686, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hadi Salim 3 Internet-Draft ZNYX Networks 4 Expires: January 15, 2009 K. Ogawa 5 NTT Corporation 6 July 14, 2008 8 SCTP based TML (Transport Mapping Layer) for ForCES protocol 9 draft-ietf-forces-sctptml-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Abstract 38 This document defines the SCTP based TML (Transport Mapping Layer) 39 for the ForCES protocol. It explains the rationale for choosing the 40 SCTP (Stream Control Transmission Protocol) [RFC2960] and also 41 describes how this TML addresses all the requirements described in 42 [RFC3654] and the ForCES protocol [FE-PROTO] draft. 44 Table of Contents 46 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 49 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5 51 3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6 52 3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6 53 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 54 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 9 55 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 10 56 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 11 57 4.2.2. Satisfying Reliability Requirement . . . . . . . . . . 13 58 4.2.3. Satisfying Congestion Control Requirement . . . . . . 13 59 4.2.4. Satisfying Timeliness and prioritizationi 60 Requirement . . . . . . . . . . . . . . . . . . . . . 13 61 4.2.5. Satisfying Addressing Requirement . . . . . . . . . . 14 62 4.2.6. Satisfying HA Requirement . . . . . . . . . . . . . . 14 63 4.2.7. Satisfying DOS Prevention Requirement . . . . . . . . 14 64 4.2.8. Satisfying Encapsulation Requirement . . . . . . . . . 14 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 6.1. TLS Usage for Securing TML . . . . . . . . . . . . . . . . 15 68 6.2. IPSec Usage for securing TML . . . . . . . . . . . . . . . 15 69 7. Manageability Considerations . . . . . . . . . . . . . . . . . 16 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Intellectual Property and Copyright Statements . . . . . . . . . . 18 77 1. Definitions 79 The following definitions are taken from [RFC3654]and [RFC3746]: 81 ForCES Protocol -- The protocol used at the Fp reference point in the 82 ForCES Framework in [RFC3746]. 84 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 85 architecture that defines the ForCES protocol architecture and the 86 state transfer mechanisms as defined in [FE-PROTO]. 88 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 89 ForCES protocol architecture that specifically addresses the protocol 90 message transportation issues, such as how the protocol messages are 91 mapped to different transport media (like TCP, IP, ATM, Ethernet, 92 etc), and how to achieve and implement reliability, multicast, 93 ordering, etc. 95 2. Introduction 97 The ForCES (Forwarding and Control Element Separation) working group 98 in the IETF is defining the architecture and protocol for separation 99 of Control Elements(CE) and Forwarding Elements(FE) in Network 100 Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively 101 define architectural and protocol requirements for the communication 102 between CE and FE. The ForCES protocol layer specification 103 [FE-PROTO] describes the protocol semantics and workings. The ForCES 104 protocol layer operates on top of an inter-connect hiding layer known 105 as the TML. The relationship is illustrated in Figure 1. 107 This document defines the SCTP based TML for the ForCES protocol 108 layer. It also addresses all the requirements for the TML including 109 security, reliability, etc as defined in [FE-PROTO]. 111 XXXX: TBD - a reference to the correct document for a more complete 112 list of terminology. 114 3. Protocol Framework Overview 116 The reader is referred to the Framework document [RFC3746], and in 117 particular sections 3 and 4, for an architectural overview and 118 explanation of where and how the ForCES protocol fits in. 120 There is some content overlap between the ForCES protocol draft 121 [FE-PROTO] and this section in order to provide clarity to the reader 122 of this document. 124 The ForCES layout constitutes two pieces: the PL and TML layer. This 125 is depicted in Figure 1. 127 +----------------------------------------------+ 128 | CE PL | 129 +----------------------------------------------+ 130 | CE TML | 131 +----------------------------------------------+ 132 ^ 133 | 134 ForCES | (i.e. Forces data + control 135 PL | packets ) 136 messages | 137 over | 138 specific | 139 TML | 140 encapsulation| 141 and | 142 transport | 143 | 144 v 145 +-----------------------------------------------+ 146 | FE TML | 147 +-----------------------------------------------+ 148 | FE PL | 149 +-----------------------------------------------+ 151 Figure 1: Message exchange between CE and FE to establish an NE 152 association 154 The PL layer is in charge of the ForCES protocol. Its semantics and 155 message layout are defined in [FE-PROTO]. The TML Layer is necessary 156 to connect two ForCES PL layers as shown in Figure 1. 158 Both the PL and TML are standardized by the IETF. While only one PL 159 is defined, different TMLs are expected to be standardized. The TML 160 at each of the peers (CE and FE) is expected to be of the same 161 definition in order to inter-operate. 163 When transmitting, the PL delivers its messages to the TML. The TML 164 then delivers the PL message to the destination peer TML(s) as 165 defined by the addressing in the PL message. 167 On reception of a message, the TML delivers the message to its 168 destination PL layer(s) (as described in the ForCES header). 170 3.1. The PL 172 The PL is common to all implementations of ForCES and is standardized 173 by the IETF [FE-PROTO]. The PL layer is responsible for associating 174 an FE or CE to an NE. It is also responsible for tearing down such 175 associations. An FE uses the PL layer to throw various subscribed-to 176 events to the CE PL layer as well as respond to various status 177 requests issued from the CE PL. The CE configures both the FE and 178 associated LFBs attributes using the PL layer. In addition the CE 179 may send various requests to the FE to activate or deactivate it, 180 reconfigure its HA parameterization, subscribe to specific events 181 etc. 183 3.2. The TML layer 185 The TML layer is responsible for transport of the PL layer messages. 186 The TML provides the following services on behalf of the ForCES 187 protocol: 189 1. Reliability 190 As defined by RFC 3654, section 6 #6. 192 2. Security 193 TML provides security services to the ForCES PL. The TML 194 definition needs to define how the following are achieved: 196 * Endpoint authentication of FE and CE 198 * Message authentication 200 * Confidentiality service 202 3. Congestion Control 203 The congestion control mechanism defined by the TML should 204 prevent the FE from being overloaded by the CE. Additionally, 205 the circumstances under which notification is sent to the PL to 206 notify it of congestion must be defined. 208 4. Uni/multi/broadcast addressing/delivery, if any 209 If there is any mapping between PL and TML level uni/multi/ 210 broadcast addressing it needs to be defined. 212 5. Transport High Availability 213 It is expected that availability of transport links is the TML's 214 responsibility. However, on config basis, the PL layer may wish 215 to participate in link failover schemes and therefore the TML 216 must allow for this. 218 6. Encapsulations used 219 Different types of TMLs will encapsulate the PL messages on 220 different types of headers. The TML needs to specify the 221 encapsulation used. 223 7. Prioritization 224 The TML SHOULD will be able to handle up to 8 priority levels 225 needed by the PL and will provide preferential treatment. 226 The TML needs to define how this is achieved. 228 8. Protection against DoS attacks 229 As described in the Requirements RFC 3654, section 6 231 It is expected more than one TML will be standardized. The different 232 TMLs each could implement things differently based on capabilities of 233 underlying media and transport. However, since each TML is 234 standardized, interoperability is guaranteed only as long as both 235 endpoints support the same TML. 237 3.2.1. TML Parameterization 239 It is expected that it should be possible to use a configuration 240 reference point, such as the FEM or the CEM, to configure the TML. 242 Some of the configured parameters may include: 244 o PL ID 246 o Connection Type and associated data. For example if a TML uses 247 IP/TCP/UDP then parameters such as TCP and UDP ports and IP 248 addresses need to be configured. 250 o Number of transport connections 252 o Connection Capability, such as bandwidth, etc. 254 o Allowed/Supported Connection QoS policy (or Congestion Control 255 Policy) 257 3.3. The TML-PL interface 259 [TML-API] defines an interface between the PL and the TML layers. 260 The end goal of [TML-API] is to provide a consistent top edge 261 semantics for all TMLs to adhere to. Conforming to such an interface 262 makes it easy to plug in different TMLs over time. It also allows 263 for simplified TML parameterization requirement stated in 264 Section 3.2.1. 266 +----------------------+ 267 | | 268 | PL Layer | 269 | | 270 +----------------------+ 271 ^ 272 | 273 | TML API 274 | 275 | 276 V 277 +----------------------+ 278 | | 279 | TML Layer | 280 | | 281 +----------------------+ 283 Figure 2: The TML-PL interface 285 We are going to assume the existence of such an interface and not 286 discuss it further. The reader is encouraged to read [TML-API] as a 287 background. 289 Editorial Note: There is some concern (and confusion) about defining 290 APIs in ForCES. So at the moment the future of [TML-API] is unknown 291 (unless these concerns are cleared). 293 4. SCTP TML overview 295 SCTP [RFC2960] is an end-to-end transport protocol that is equivalent 296 to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP 297 can do most of what UDP, TCP, or DCCP can achieve. SCTP as well can 298 do most of what a combination of the other transport protocols can 299 achieve (eg TCP and DCCP or TCP and UDP). 301 Like TCP, it provides ordered, reliable, connection-oriented, flow- 302 controlled, congestion controlled data exchange. Unlike TCP, it does 303 not provide byte streaming and instead provides message boundaries. 305 Like UDP, it can provide unreliable, unordered data exchange. Unlike 306 UDP, it does not provide multicast support 307 Like DCCP, it can provide unreliable, ordered, congestion controlled, 308 connection-oriented data exchange. 310 SCTP also provides other services that none of the 3 transport 311 protocols mentioned above provide. These include: 313 o Multi-homing 314 An SCTP connection can make use of multiple destination IP 315 addresses to communicate with its peer. 317 o Runtime IP address binding 318 With the SCTP ADDIP feature, a new address can be bound at 319 runtime. This allows for migration of endpoints without 320 restarting the association (valuable for high availability). 322 o A range of reliability shades with congestion control 323 SCTP offers a range of services from full reliability to none, and 324 from full ordering to none. With SCTP, on a per message basis, 325 the application can specify a message's time-to-live. When the 326 expressed time expires, the message can be "skipped". 328 o Built-in heartbeats 329 SCTP has built-in heartbeat mechanism that validate the 330 reachability of peer addresses. 332 o Multi-streaming 333 A known problem with TCP is head of line (HOL) blocking. If you 334 have independent messages, TCP enforces ordering of such messages. 335 Loss at the head of the messages implies delays of delivery of 336 subsequent packets. SCTP allows for defining upto 64K independent 337 streams over the same socket connection, which are ordered 338 independently. 340 o Message boundaries with reliability 341 SCTP allows for easier message parsing (just like UDP but with 342 reliability built in) because it establishes boundaries on a PL 343 message basis. On a TCP stream, one would have to use techniques 344 such peeking into the message to figure the boundaries. 346 o Improved SYN DOS protection 347 Unlike TCP, which does a 3 way connection setup handshake, SCTP 348 does a 4 way handshake. This improves against SYN-flood attacks 349 because listening sockets do not set up state until a connection 350 is validated. 352 o Simpler transport events 353 An application (such as the TML) can subscribe to be notified of 354 both local and remote transport events. Events that can be 355 subscribed-to include indication of association changes, 356 addressing changes, remote errors, expiry of timed messages, etc. 357 These events are off by default and require explicit subscription. 359 o Simplified replicasting 360 Although SCTP does not allow for multicasting it allows for a 361 single message from an application to be sent to multiple peers. 362 This reduces the messaging that typically crosess different memory 363 domains within a host. 365 4.1. Rationale for using SCTP for TML 367 SCTP has all the features required to provide a robust TML. As a 368 transport that is all-encompassing, it negates the need for having 369 multiple transport protocols, as has been suggested so far in the 370 other proposals for TMLs. As a result it allows for simpler coding 371 and therefore reduces a lot of the interoperability concerns. 373 SCTP is also very mature and widely deployed completing the equation 374 that makes it a superior choice in comparison with other proposed 375 TMLs. 377 4.2. Meeting TML requirements 379 PL 380 +---------------------+ 381 | | 382 +-----------+---------+ 383 | TML API 384 TML | 385 +-----------+----------+ 386 | | | 387 | +------+------+ | 388 | | TML core | | 389 | +-+----+----+-+ | 390 | | | | | 391 | SCTP socket API | 392 | | | | | 393 | | | | | 394 | +-+----+----+-+ | 395 | | SCTP | | 396 | +------+------+ | 397 | | | 398 | | | 399 | +------+------+ | 400 | | IP | | 401 | +-------------+ | 402 +----------------------+ 404 Figure 3: The TML-SCTP interface 406 Figure 3 details the interfacing between the TML and SCTP and the 407 internals of the SCTP TML. The core of the TML interfaces on its 408 north bound interface to the PL (utilizing the TML API). On the 409 southbound interface, the TML core interfaces to the SCTP layer 410 utilizing the standard socket interface [Editorial: add here a 411 reference to SCTP Sockets API doc]. There are three SCTP socket 412 connections opened between any two PL layers (whether FE or CE). 414 4.2.1. SCTP TML Channels 416 +--------------------+ 417 | | 418 | TML core | 419 | | 420 +-+-------+--------+-+ 421 | | | 422 | Med prio, | 423 | Semi-reliable | 424 | channel | 425 | | Low prio, 426 | | Unreliable channel 427 | | | 428 ^ ^ ^ 429 | | | 430 Y Y Y 431 High prio,| | | 432 reliable | | | 433 channel | | | 434 Y Y Y 435 +-+--------+--------+-+ 436 | | 437 | SCTP | 438 | | 439 +---------------------+ 441 Figure 4: The TML-SCTP channels 443 Figure 4 details further the interfacing between the TML core and 444 SCTP layers. There are 3 channels used to separate and prioritize 445 the different types of ForCES traffic. Each channel constitutes a 446 socket interface. It should be noted that all SCTP channels are 447 congestion aware (and for that reason that detail is left out of the 448 description of the 3 channels). SCTP port 6700, 6701, 6702 are used 449 for the higher, medium and lower priority channels respectively. 451 4.2.1.1. Justifying Choice of 3 Sockets 453 SCTP allows upto 64K streams to be sent over a single socket 454 interface. The authors initially envisioned using a single socket 455 for all three channels (mapping a channel to an SCTP stream). This 456 simplifies programming of the TML as well as conserves use of SCTP 457 ports. 459 Further analysis revealed head of line blocking issues with this 460 initial approach. Lower priority packets not needing reliable 461 delivery could block higher priority packets (needing reliable 462 delivery) under congestion situation. This proposal alleviates that 463 problem by making the medium and low priority channels obsolete over 464 a period of time, but that is still insufficient to resolve the 465 outstanding HOL issue. 467 XXX: Talk here about Michael Tuxen's approach which will allow for 468 SCTP to prioritize streams within a single socket. Unfortunately, 469 until that approach completes standardization effort we cannot 470 recomend its use for ForCES TML. 472 4.2.1.2. Higher Priority, Reliable channel 474 The higher priority channel uses a standard SCTP reliable socket on 475 port 6700. It is used for CE solicited messages and their responses: 477 1. ForCES configuration messages flowing from CE to FE and responses 478 from the FE to CE. 480 2. ForCES query messages flowing from CE to FE and responses from 481 the FE to the CE. 483 Some events which require guaranteed delivery could also optionally 484 use this interface. An example of an event that would be prioritized 485 and delivered on this channel would be a PL heartbeat (in a scenario 486 when the first few HBs fail to make it to the destination). 488 4.2.1.3. Medium Priority, Mixed Reliable channel 490 The medium priority channel uses SCTP-PR on port 6701. Time limits 491 on how long a message is valid are set on each outgoing message. 492 This channel is used for events from the FE to the CE that are 493 obsoleted over time. Events that are accumulative in nature and are 494 recoverable by the CE (by issuing a query to the FE) can tolerate 495 lost events and therefore should this channel. Example a counter 496 that is monotonically incrementing fits to use this channel. 498 4.2.1.4. Lower Priority, Unreliable channel 500 The lower priority channel on SCTP port 6702 is used for redirect 501 messages between the CE and FE. This channel also uses SCTP-PR with 502 lower timeout values than the medium priority channel. The reason an 503 unreliable channel is used for redirect messages is to allow the 504 control protocol at both the CE and its peer-endpoint to take charge 505 of how the end to end semantics of the said control protocol's 506 operations. For example: 508 1. Some control protocols are reliable in nature, therefore making 509 this channel reliable introduces an extra layer of reliability 510 which could be harmful. So any end to end retransmits will 511 happen from remote. 513 2. Some control protocols may desire to have obsolescence of 514 messages over retransmissions; making this channel reliable 515 contradicts that desire. 517 4.2.1.5. Scheduling of The 3 Channels 519 Strict priority work-conserving scheduling is used to process both on 520 sending and receving by the TML Core. This means that the higher 521 priority messages are always processed first until there are no more 522 left. The lower priority channel is processed only if a channel that 523 is higher priority than itself has no more messages left to process. 524 This means that under congestion situation, a higher priority channel 525 with sufficient messages that occupy the available bandwidth would 526 starve lower priority channel(s). The authors feel this is justified 527 given the choice of the messaging prioritization as described above. 529 4.2.1.6. TML Parameterization 531 TBA: This section will have a list of all parameters needed for 532 booting the TML. 534 4.2.1.7. TML Bootstrapping 536 TBA: This section will show how the FE and CE side of bootstrapping. 538 4.2.2. Satisfying Reliability Requirement 540 As mentioned earlier, a shade of reliability ranges is possible in 541 SCTP. Therefore this requirement is met. 543 4.2.3. Satisfying Congestion Control Requirement 545 Congestion control is built into SCTP. Therefore, this requirement 546 is met. 548 4.2.4. Satisfying Timeliness and prioritizationi Requirement 550 By using 3 sockects in conjunction with the partial-reliability 551 feature, both timeliness and prioritization can be achieved. 553 4.2.5. Satisfying Addressing Requirement 555 SCTP can be told to replicast packets to multiple destinations. The 556 TML will translate PL level addresses, to a variety of unicast IP 557 addresses in order to emulate multicast and broadcast. Note, that 558 there are no extra headers required for SCTP. 560 4.2.6. Satisfying HA Requirement 562 Transport link resiliency is SCTP's strongest point (where it totally 563 outclasses all other TML proposals). Failure detection and recovery 564 is built in as mentioned earlier. 566 o The SCTP multi-homing feature is used to provide path diversity. 567 Should one of the peer IP addresses become unreachable, the 568 other(s) are used without needing lower layer convergence 569 (routing, for example) or even the TML becoming aware. 571 o SCTP heartbeats and data transmission thresholds are used on a per 572 peer IP address to detect reachability faults. The faults could 573 be a result of an unreachable address or peer, which may be caused 574 by a variety of reasons, like interface, network, or endpoint 575 failures. The cause of the fault is noted. 577 o With the ADDIP feature, one can migrate IP addresses to other 578 nodes at runtime. This is not unlike the VRRP[RFC3768] protocol 579 use. This feature is used in addition to multi-homing in a 580 planned migration of activity from one FE/CE to another. In such 581 a case, part of the provisioning recipe at the CE for replacing an 582 FE involves migrating activity of one FE to another. 584 4.2.7. Satisfying DOS Prevention Requirement 586 Three separate streams (one per socket) are used within any FE-CE 587 setup. The scheduling design for processing channels 588 (Section 4.2.1.5)is strict priority. This guarantees that lower 589 priority messages are starved if lack of resources happen. i.e under 590 congestion (which is likely to occur under DOS attack), redirected 591 packets (from outside the NE) get very low priority and obsoleted in 592 short periods if the CE-FE path is congested without consuming 593 resources on the CE-FE path. 595 4.2.8. Satisfying Encapsulation Requirement 597 There is no extra encapsulation added by this TML. SCTP provides for 598 extensions to be added to it by defining new chunks. In the future, 599 should the need arise, a new SCTP extension can be defined to meet 600 newer ForCES requirements. 602 5. IANA Considerations 604 This document makes request of IANA to reserve SCTP ports 6700, 6701, 605 and 6702. 607 6. Security Considerations 609 When operating under a secured environment then the network 610 administrator can turn off all the security functions. This feature 611 is configured during the pre-association phase of the protocol. This 612 mode is called "no security" mode of operation. 614 When the CEs, FEs are running over IP networks or in an insecure 615 environment, the operator has the choice of configuring either TLS 616 [RFC2246] or IPSec [RFC2401] to provide needed security. For IPSec, 617 The security association between the CEs and FEs MUST be established 618 before any ForCES protocol messages are exchanged between the CEs and 619 FEs. 621 6.1. TLS Usage for Securing TML 623 This section is applicable for CE or FE endpoints that use the TML 624 with TLS [RFC2246] to secure communication. 626 Since CE is master and FEs are slaves, the FEs are TLS clients and 627 CEs are TLS server. The endpoints that implement TLS MUST perform 628 mutual authentication during TLS session establishment process. CE 629 must request certificate from FE and FE needs to pass the requested 630 information. 632 We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite. Although 633 consistency is expected it is possible for the CE or FE to negotiate 634 other TLS cipher suites. 636 6.2. IPSec Usage for securing TML 638 This section is applicable for CE or FE endpoints that use the TML 639 with IPSec [RFC2401] to secure their respective communication. IPSec 640 is transparent to the higher-layer applications and can provide 641 security for any transport layer protocol. This mechanism is can be 642 used to secure just the control or both the control and the data 643 channel simultaneously. 645 Editorial Note: We need to flesh the security section with more 646 details. 648 7. Manageability Considerations 650 TBA 652 8. Acknowledgements 654 The authors would like to thank Joel Halpern, Michael Tuxen and Randy 655 Stewart for engaging us in discussions that have made this draft 656 better. 658 9. References 660 9.1. Normative References 662 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 663 RFC 2246, January 1999. 665 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 666 Internet Protocol", RFC 2401, November 1998. 668 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 669 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 670 October 1998. 672 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 673 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 674 Zhang, L., and V. Paxson, "Stream Control Transmission 675 Protocol", RFC 2960, October 2000. 677 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 678 of IP Control and Forwarding", RFC 3654, November 2003. 680 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 681 "Forwarding and Control Element Separation (ForCES) 682 Framework", RFC 3746, April 2004. 684 9.2. Informative References 686 [FE-MODEL] 687 Halpern, J., Deleganes, E., and J. Hadi Salim, "ForCES 688 Forwarding Element Model", February 2008. 690 [FE-PROTO] 691 Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., 692 Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. 693 Gopal, "ForCES Protocol Specification", March 2008. 695 [TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES 696 Transport Mapping Layer (TML) Service Primitives", 697 Feb. 2007. 699 Authors' Addresses 701 Jamal Hadi Salim 702 ZNYX Networks 703 Ottawa, Ontario 704 Canada 706 Email: hadi@znyx.com 708 Kentaro Ogawa 709 NTT Corporation 710 3-9-11 Midori-cho 711 Musashino-shi, Tokyo 180-8585 712 Japan 714 Email: ogawa.kentaro@lab.ntt.co.jp 716 Full Copyright Statement 718 Copyright (C) The IETF Trust (2008). 720 This document is subject to the rights, licenses and restrictions 721 contained in BCP 78, and except as set forth therein, the authors 722 retain all their rights. 724 This document and the information contained herein are provided on an 725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 727 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 728 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 729 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 Intellectual Property 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at 754 ietf-ipr@ietf.org.