idnits 2.17.1 draft-khosravi-forces-tcptml-00.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 434. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 12 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [7]), 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 315: '... the CEs and FEs MUST be established b...' RFC 2119 keyword, line 324: '...points that implement TLS MUST perform...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 108 has weird spacing: '... define both ...' == Line 113 has weird spacing: '...ultiple trans...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 2004) is 7100 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 section? '2' on line 41 looks like a reference -- Missing reference section? '3' on line 233 looks like a reference -- Missing reference section? '7' on line 234 looks like a reference -- Missing reference section? '5' on line 79 looks like a reference -- Missing reference section? 'RFC3746' on line 122 looks like a reference -- Missing reference section? '4' on line 108 looks like a reference -- Missing reference section? 'Reqs' on line 246 looks like a reference -- Missing reference section? '11' on line 254 looks like a reference -- Missing reference section? '8' on line 321 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Hormuzd Khosravi 2 Internet Draft Intel Corp. 3 Document: draft-khosravi-forces-tcptml-00.txt Furquan Ansari 4 Expires: May 2005 Lucent Tech. 5 Working Group: ForCES Jon Maloy 6 Ericsson 8 November 2004 10 TCP/IP based TML (Transport Mapping Layer) for ForCES protocol 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as ``work in 28 progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 40 this document are to be interpreted as described in [2]. 42 Abstract 44 This document defines the TCP/IP based TML (Transport Mapping Layer) 45 for the ForCES protocol. It explains the rationale for choosing the 46 transport protocols and also describes how this TML addresses all 47 the requirements described in the Forces [3] requirements and ForCES 48 protocol [7] document. 50 Table of Content 52 1. Definitions.....................................................2 53 2. Introduction....................................................3 54 3. Protocol Framework Overview.....................................3 55 4. TCP/IP TML Overview.............................................5 56 4.1. Rationale for using TCP/IP....................................5 57 4.2. Separate Control and Data channels............................5 58 4.3. Reliability...................................................6 59 4.4. Congestion Control............................................6 60 4.5. Security......................................................6 61 4.6. Addressing....................................................6 62 4.7. Prioritization................................................7 63 4.8. HA Decisions..................................................7 64 4.9. Encapsulations Used...........................................7 65 5. Example Scenarios...............................................7 66 5.1. Establishment of Association..................................7 67 5.2. Steady State Communication....................................7 68 6. Security Considerations.........................................7 69 6.1. TLS Usage for this TML........................................7 70 7. IANA Considerations.............................................8 71 8. References......................................................8 72 8.1. Normative References..........................................8 73 8.2. Informative References........................................9 74 9. Acknowledgments.................................................9 75 10. Authors' Addresses.............................................9 77 1. Definitions 79 The following definitions are taken from [3], [5] 81 ForCES Protocol - While there may be multiple protocols used within 82 the overall ForCES architecture, the term "ForCES protocol" refers 83 only to the protocol used at the Fp reference point in the ForCES 84 Framework in RFC3746 [RFC3746]. This protocol does not apply to 85 CE-to-CE communication, FE-to-FE communication, or to communication 86 between FE and CE managers. Basically, the ForCES protocol works in 87 a master-slave mode in which FEs are slaves and CEs are masters. 89 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 90 architecture that defines the ForCES protocol messages, the protocol 91 state transfer scheme, as well as the ForCES protocol architecture 92 itself (including requirements of ForCES TML (see below)). 93 Specifications of ForCES PL are defined by this document. 95 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 96 ForCES protocol architecture that specifically addresses the 97 protocol message transportation issues, such as how the protocol 98 messages are mapped to different transport media (like TCP, IP, ATM, 99 Ethernet, etc), and how to achieve and implement reliability, 100 multicast, ordering, etc. This document defines a TCP/IP based 101 ForCES TML. 103 2. Introduction 105 The ForCES (Forwarding and Control Element Separation) working group 106 in the IETF is defining the architecture and protocol for separation 107 of control and forwarding elements in network elements such as 108 routers. [3], [4] define both architectural and protocol 109 requirements for the communication between CE and FE. The ForCES 110 protocol layer [7] describes the protocol specification. It is 111 envisioned that the ForCES protocol would be independent of the 112 interconnect technology between the CE and FE and can run over 113 multiple transport technologies and protocol. Thus a Transport 114 Mapping Layer has been defined in the protocol framework that will 115 take care of mapping the protocol messages to specific transports. 116 This document defines the TCP/IP based TML for the ForCES protocol 117 layer. It also addresses all the requirements for the TML including 118 security, reliability, etc. 120 3. Protocol Framework Overview 122 The reader is referred to the Framework document [RFC3746], and in 123 particular sections 3 and 4, for architectural overview and where 124 and how the ForCES protocol fits in. There may be some content 125 overlap between the ForCES protocol draft [7] and this section in 126 order to provide clarity. 128 The ForCES protocol constitutes two pieces: the PL and TML layer. 129 This is depicted in Figure 1 below. 131 +------------------------------------------------ 132 | CE PL layer | 133 +------------------------------------------------ 134 | CE TML layer | 135 +------------------------------------------------ 136 ^ 137 | 139 ForCES | (i.e. Forces data + control 140 PL | packets ) 141 messages | 142 over | 143 specific | 144 TML | 145 encaps | 146 and | 147 transport | 148 | 149 v 150 +------------------------------------------------ 151 | FE TML layer | 152 +------------------------------------------------ 153 | FE PL layer | 154 +------------------------------------------------ 156 Figure 1: ForCES Interface 158 The PL layer is in fact the ForCES protocol. Its semantics and 159 message layout are defined in [7]. The TML Layer is necessary to 160 connect two ForCES PL layers as shown in Figure 1 above. 162 Both the PL and TML layers are standardized by the IETF. While only 163 one PL layer is defined, different TMLs are expected to be 164 standardized. To interoperate the TML layer at the CE and FE are 165 expected to be of the same definition. 167 On transmit, the PL layer delivers its messages to the TML layer. 168 The TML layer delivers the message to the destination TML layer(s). 169 On reception, the TML delivers the message to its destination PL 170 layer(s). 172 3.1.1 The PL layer 174 The PL is common to all implementations of ForCES and is 175 standardized by the IETF [7]. The PL layer is responsible for 176 associating an FE or CE to an NE. It is also responsible for 177 tearing down such associations. An FE uses the PL layer to throw 178 various subscribed-to events to the CE PL layer as well as respond 179 to various status requests issued from the CE PL. The CE configures 180 both the FE and associated LFBs attributes using the PL layer. In 181 addition the CE may send various requests to the FE to activate or 182 deactivate it, reconfigure its HA parameterization, subscribe to 183 specific events etc. 185 3.1.2 The TML layer 186 The TML layer is essentially responsible for transport of the PL 187 layer messages. The TML is where the issues of how to achieve 188 transport level reliability, congestion control, multicast, 189 ordering, etc. are handled. It is expected more than one TML will 190 be standardized. The different TMLs each could implement things 191 differently based on capabilities of underlying media and transport. 192 However, since each TML is standardized, interoperability is 193 guaranteed as long as both endpoints support the same TML. All 194 ForCES Protocol Layer implementations should be portable across all 195 TMLs, because all TMLs have the same top edge semantics. 197 4. TCP/IP TML Overview 199 The TCP/IP TML consists of two TCP connections between the CE and FE 200 over which the protocol messages are exchanged. One of the 201 connection is called the Control channel, over which control 202 messages are exchanged, the other is called data channel over which 203 external protocol packets, such as routing packets will be 204 exchanged. The TCP connections will use unique server port numbers 205 for each of the channels. In addition to this, this TML will provide 206 mechanisms to prioritize the messages over the different channels. 208 Some of the rationale of choosing this transport mechanism as well 209 as explanation of how it meets the TML requirements is explained 210 below. 212 4.1.Rationale for using TCP/IP 214 TCP meets all the reliability requirements (no losses, no data 215 corruption, no re-ordering of data) for the ForCES protocol/TML and 216 also provides congestion control mechanism, which is important to 217 meet the scalability requirement. In addition, it helps with 218 interoperability since TCP is a well-understood, widely deployed 219 transport protocol. Using TCP also enables this TML and the protocol 220 to work seamlessly in single hop and multihop scenarios. 222 4.2.Separate Control and Data channels 224 The ForCES NEs are subject to Denial of Service (DoS) attacks 225 [Requirements Section 7 #15]. A malicious system in the network can 226 flood a ForCES NE with bogus control packets such as spurious RIP or 227 OSPF packets in an attempt to disrupt the operation of and the 228 communication between the CEs and FEs. In order to protect against 229 this situation, the TML uses separate control and data channels for 230 communication between the CEs and FEs. 232 The data channel carries the control protocol packets such as RIP, 233 OSPF messages as outlined in Requirements [3] Section 7 #10, which 234 are carried in ForCES Packet Redirect messages [7], between the CEs 235 and FEs. All the other ForCES messages, which are used for 236 configuration/capability exchanges, event notification, etc, are 237 carried over the control channel. The data channel is set up only 238 after the control channel is set up and the capability exchange has 239 successfully taken place between the FEs and CEs. The CE signals the 240 FE to establish the data channel at the appropriate time and 241 provides it with the channel addressing information, such as, port 242 number in case of TCP (see section 5.3). By default, the data 243 channel is established on the CE control channel port number +1. 245 The reliability requirements for the data channel messages are 246 different from that of the control messages [Reqs] i.e. they dont 247 require strict reliability in terms of retransmission, etc. However 248 congestion control is important for the data channel because in case 249 of DoS attacks, if an unreliable transport such as UDP is used for 250 the data traffic, it can more easily overflow the physical 251 connection, overwhelming the control traffic with congestion. Thus 252 we need a transport protocol that provides congestion control but 253 does not necessarily provide full reliability. Datagram Congestion 254 Control Protocol (DCCP) [11], which is currently being defined, is a 255 transport protocol that exactly meets this requirement. However 256 since it is currently not an IETF standard RFC, and the authors are 257 unaware of any existing implementations, this TML uses TCP as 258 transport protocol for the data channel (for IP interconnect). TCP 259 provides the congestion control mechanism required for the data 260 channel and its wide deployment eases interoperability. 262 4.3.Reliability 264 TCP provides the reliability (no losses, no data corruption, no re- 265 ordering of data) required for ForCES protocol control messages. 267 4.4.Congestion Control 269 TCP provides congestion control needed to satisfy this requirement. 271 4.5.Security 273 This TML uses TLS [8] to provide security in insecure environments. 274 Please see section 6 on security considerations for more details. 276 4.6.Addressing 278 This TML uses addressing provided by IP layer. 280 4.7.Prioritization 282 This TML provides prioritization of messages sent over control 283 channel as compared to the data channel. This has also been found to 284 be useful in face of DoS attacks on the protocol. The details of 285 this are TBD. 287 4.8.HA Decisions 289 TBD 291 4.9.Encapsulations Used 293 Other than the TCP/IP header, no other encapsulations will be added 294 to the ForCES protocol messages. 296 5. Example Scenarios 298 5.1.Establishment of Association 300 TBD 302 5.2.Steady State Communication 304 TBD 306 6. Security Considerations 308 If the CE or FE are in a single box and network operator is running 309 under a secured environment then it is up to the network 310 administrator to turn off all the security functions. This is 311 configured during the pre-association phase of the protocol. 313 When the CEs, FEs are running over IP networks or in an insecure 314 environment, this TML uses TLS [8] to provide security. The security 315 association between the CEs and FEs MUST be established before any 316 ForCES protocol messages are exchanged between the CEs and FEs. 318 6.1.TLS Usage for this TML 320 This section is applicable for CE or FE endpoints that use the TML 321 with TLS [8] to secure communication. 323 Since CE is master and FEs are slaves, the FEs are TLS clients and 324 CEs are TLS server. The endpoints that implement TLS MUST perform 325 mutual authentication during TLS session establishment process. CE 326 must request certificate from FE and FE needs to pass the requested 327 information. 329 We recommend TLS-RSA-with-AES-128-CBC-SHA� cipher suite, but CE or 330 FE may negotiate other TLS cipher suites. TLS must be used for all 331 control channel messages. TLS is optional for the data channel since 332 data channel packets are not encrypted externally to the NE. 334 This TML uses TLS to provide security when the NE is in an insecure 335 environment. This is because IPsec provides less flexibility when 336 configuring trust anchors since it is transparent to the application 337 and use of Port identifiers is prohibited within IKE Phase 1. This 338 provides restriction for IPsec to configure trust anchors for each 339 application separately and policy configuration is common for all 340 applications. 342 7. IANA Considerations 344 The TCP/IP TML needs to have a two well-defined TCP port numbers, 345 which needs to be assigned by IANA. 347 8. References 348 8.1.Normative References 350 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 351 October 1996. 353 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 354 Levels", RFC2119 (BCP), IETF, March 1997. 356 3. Khosravi, et al., �Requirements for Separation of IP Control and 357 Forwarding�, RFC 3654, November 2003. 359 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 360 April 2004. 362 5. L. Yang, et al., � ForCES Forwarding Element Functional Model�, 363 work in progress�, July 2004, 365 6. A. Audu, et al.,  Forwarding and Control Element protocol (FACT)" 366 draft-gopal-forces-fact-06.txt, February 2004. 368 7. A. Doria, et al., �ForCES protocol specification�, draft-ietf- 369 forces-protocol-00.txt, September 2004. 371 8.2.Informative References 373 8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. 374 Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 376 9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 377 Security over Stream Control Transmission Protocol", RFC 3436, 378 December 2002. 380 10. R. Stewart, et al., Stream Control Transmission Protocol 381 (SCTP)�, RFC 2960, October 2000. 383 11. E. Kohler, M. Handley, S. Floyd, J. Padhye, Datagram 384 Congestion Control Protocol (DCCP)�, draft-ietf-dccp-spec-04.txt, 385 June 2003. 387 12. Floyd, S., Congestion Control Principles�, RFC 2914, September 388 2000. 390 13. A. Doria, F. Hellstrand, K. Sundell, T. Worster, General 391 Switch Management Protocol (GSMP) V3�, RFC 3292, June 2002. 393 14. H. Balakrishnan, et al. The Congestion Manager�, RFC 3124, 394 June 2001. 396 9. Acknowledgments 398 10. Authors' Addresses 400 Hormuzd Khosravi 401 Intel 402 2111 NE 25th Avenue 403 Hillsboro, OR 97124 404 Phone: 1-503-264-0334 405 Email: hormuzd.m.khosravi@intel.com 407 Furquan Ansari 408 101 Crawfords Corner Road 409 Holmdel, NJ 07733 410 USA 411 Phone: +1 732-949-5249 412 Email: furquan@lucent.com 414 Jon Maloy 415 Ericsson Research Canada 416 8400 Boul Decarie 417 Ville Mont-Royal, Quebec H4P 2N2 418 Canada 419 Phone: 1-514-345-7900 420 Email: jon.maloy@ericsson.com 422 Copyright Statement 424 Copyright (C) The Internet Society (year). This document is subject 425 to the rights, licenses and restrictions contained in BCP 78, and 426 except as set forth therein, the authors retain all their rights. 428 This document and the information contained herein are provided on 429 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 430 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 431 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 432 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 433 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.