idnits 2.17.1 draft-honeywell-ctp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 939 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 9, 2017) is 2515 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HTTP' is mentioned on line 170, but not defined == Missing Reference: 'RTSP' is mentioned on line 170, but not defined == Missing Reference: 'RTMP' is mentioned on line 170, but not defined -- Looks like a reference, but probably isn't: '1' on line 863 -- Looks like a reference, but probably isn't: '2' on line 867 -- Looks like a reference, but probably isn't: '3' on line 868 -- Looks like a reference, but probably isn't: '4' on line 868 -- Looks like a reference, but probably isn't: '6' on line 818 -- Looks like a reference, but probably isn't: '8' on line 819 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Proposed Standard RFC: RFC 7301 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Romanczyk 2 Internet-Draft C. Colicino 3 Intended Status: Standard M. Landi 4 Expires: September 8, 2017 T. Brodsky 5 Honeywell 6 May 9, 2017 8 Cloud Tunneling Protocol (CTP) 9 draft-honeywell-ctp-03.txt 11 Abstract 13 This specification defines operating semantics of the Cloud 14 Tunneling Protocol (CTP). CTP enables a standardized mechanism for 15 connecting Internet-of-Things (IoT) devices to hosted cloud 16 services. CTP provides a network efficient means to facilitate 17 multiple concurrent data conversations over the same channel by 18 providing multiplexed virtual sockets. The protocol allows for 19 services on either endpoint to be advertised and accessible to each 20 endpoint of the CTP connection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on September 8, 2017. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction 63 1.1 Protocol Overview 64 1.2 Definitions of Commonly Used Terms 65 2. Requirements Language 66 3. Encapsulation 67 3.1 Frame Header 68 3.2 Control Frames 69 3.3 Commands and Tags 70 3.4 Control Frame Acknowledgements 71 4. Initial Connection 72 4.1 Establishment 73 4.2 Authentication/Authorization 74 4.3 Transport Security 75 4.4 Keepalives 76 5. Endpoint Services 77 6. Virtual Sockets 78 6.1 Reserved Virtual Sockets 79 6.2 Virtual Socket Life-Cycle 80 6.3 Virtual Socket Allocation 81 7. IANA Considerations 82 7.1 Registration of CTP Identification Strings 83 8. Security Considerations 84 8.1 Denial of Service 85 8.1.1 Connection Starving 86 8.1.2 Zombie TCP/IP Connections 87 8.1.3 Zombie CTP Connections 88 8.1.4 Data Flooding 89 8.2 Command Length Security 90 8.3 Label Logic Considerations 91 9. References 92 9.1. Normative References 93 9.2. Informative References 94 10. Appendices 95 10.1 Appendix A. Connection Dataflow 96 10.2 Appendix B. Virtual Socket Dataflow 97 Authors' Addresses 98 IPR Disclosure 99 Disclaimer 101 1. Introduction 103 This document is a specification of the Cloud Tunneling Protocol 104 (CTP). CTP communication normally occurs over a TCP/IP socket 105 connection. CTP is an application layer protocol that can multiplex 106 multiple TCP/IP [RFC793] sockets over a single connection. In the 107 context of the Internet Suite (TCP/IP), the CTP protocol is located 108 above the transport layer and below other application-layer 109 protocols. This protocol describes a method of exposing and 110 tunneling multiple services on both the client and server endpoints 111 through a single TCP/IP connection. CTP is a departure from standard 112 virtual private network (VPN) protocols as it does not define a 113 method for accessing network based resources directly. Instead, 114 resources are defined at the CTP application layer and resolved by 115 either endpoint as configured. 117 The CTP protocol was developed by the CTP working group. It is 118 created to operate specifically for the TCP/IP Internet environment, 119 wrapping multiple bi-directional TCP/IP conversations within a 120 single connection. The protocol was designed to facilitate the 121 access of multiple services simultaneously between two endpoints, 122 with data traversing complex networks interpolated with routers, 123 firewalls, and network address translation. Much work has been done 124 to produce an efficient protocol that can provide the type of 125 connectivity discussed. 127 [ Application ] <---Process to Process---> [ Application ] 128 [ CTP ] [ CTP ] 129 [ Transport ] <------Host to Host------> [ Transport ] 130 [ Internet ] [ Internet ] 131 [ Link ] [ Link ] 132 ^ ^ 133 |__________________________________________| 135 Figure 1a: CTP in the Internet Protocol Suite 137 1.1 Protocol Overview 139 CTP assumes a long-lived TCP/IP connection established between a 140 client and a remote server. This connection is assumed to be 141 originated from the client. In general, a client establishes a 142 single connection to the remote server for efficiency. The CTP 143 protocol describes how to achieve multiple TCP/IP conversations over 144 this single connection. 146 The CTP protocol is a binary protocol which encapsulates application 147 layer data into frames for transport. These frames provide the 148 ability to multiplex multiple conversations on a single connection 149 by designating which conversation, or virtual socket, the frame is 150 associated with. 152 Once a connection is established, all communication between the two 153 endpoints is bidirectional for any TCP/IP conversation. Each 154 endpoint can run in either a client or server context using multiple 155 virtual sockets. As such, both the client and server endpoints can 156 establish virtual sockets over this single CTP connection. CTP 157 utilizes control messages to negotiate the establishment, 158 maintenance, and tear-down of virtual sockets over the lifetime of 159 this connection. 161 Establishing a virtual socket signals to the remote endpoint the 162 initiator's intent to access a remote service. Once a virtual 163 socket is established, data can be transmitted over this channel. 164 Data is multiplexed and encapsulated into frames on the sending 165 endpoint. On the receiving endpoint, frames are demultiplexed and 166 de-encapsulated. All communication between endpoints is 167 deterministic with a fixed frame header specifying the payload size 168 to follow. 170 [HTTP] [RTSP] [RTMP] <-----------------> [HTTP] [RTSP] [RTMP] 171 [ Application ] <---Process to Process---> [ Application ] 172 [ CTP ] [ CTP ] 173 [ Transport ] <------Host to Host------> [ Transport ] 174 [ Internet ] [ Internet ] 175 [ Link ] [ Link ] 176 | | 177 |__________________________________________| 179 Figure 1.1b: Example Applications Tunneled through CTP 181 Multiple application-layer processes with CTP within 182 the context of the Internet Protocol Suite. 183 By utilizing the protocol, both the TCP/IP client and 184 TCP/IP server can expose their own services. 186 1.2 Definitions of Commonly Used Terms 188 This section provides definitions for the terms that have a specific 189 meaning to the CTP protocol. These terms are used throughout this 190 specification. 192 Endpoint 193 One end of a TCP/IP socket connection. This term refers to 194 either a TCP/IP server or client. 196 Local Endpoint 197 The local end of a TCP/IP socket connection from the reader's 198 perspective. 200 Remote Endpoint 201 The remote end of a TCP/IP socket connection from the reader's 202 perspective. 204 CTP Client 205 The endpoint from which the CTP connection originated. 207 CTP Server 208 The endpoint that received the CTP connection. 210 Frame 211 The basic unit of transmission in CTP. Encapsulates application 212 layer data and specifies a particular TCP/IP conversation. 214 Control Frame 215 Extends a standard CTP frame to include a command, or action, as 216 well as parameters in the frame's payload. 218 String 219 A finite sequence of ASCII encoded characters as defined in RFC 220 20 [RFC20]. 222 Command 223 An action represented as a 4 byte string in a control frame. 225 Tag 226 A key/value pair used to represent a parameter for a given 227 control frame's command. 229 Endpoint Service 230 A service or resource as advertised and exposed by a CTP 231 endpoint. 233 Virtual Socket 234 A single TCP/IP conversation in a multiplexed CTP connection. 236 Service Label 237 A string that identifies a given endpoint service. Service 238 labels are advertised by endpoints and used to specify which 239 services endpoints are accessing through a virtual socket. 241 2. Requirements Language 243 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 244 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 245 document are to be interpreted as described in BCP 14, RFC 2119 246 [RFC2119]. 248 3. Frame Encapsulation 250 CTP encapsulates and interleaves both data and control messages into 251 transmission units called frames. All frames must begin with a 252 fixed size header (8 bytes). The frame header provides the protocol 253 with information about what data the frame encapsulates. This 254 information is used to determine which TCP/IP conversation, or 255 virtual socket, the frame is associated with. 257 The header also specifies the length of the data payload to follow. 258 The maximum size of a frame is 65,543 bytes including the 8 byte 259 header. The maximum frame payload size is 65,535 bytes. Frames can 260 be split over multiple TCP/IP packets if necessary, but the entire 261 frame must be sent in full before the next frame can be sent. 263 3.1 Frame Header 265 Following the TCP/IP header, the packet's payload will contain one 266 or more CTP frames. Each frame header must have the following 267 structure: 269 0 270 0 1 2 3 4 5 6 7 271 +---+---+---+---+---+---+---+---+ 272 | I |VERSION|VIRTUAL| R |PAYLOAD| 273 | D | |SOCKET | S |SIZE | 274 | | |ID | V | | 275 +---+---+---+---+---+---+---+---+ 277 Figure 3.1a: CTP Frame Header Layout 279 These frame fields are described in detail in Figure 3.1b. All 280 numerical values in the frame header must be encoded as Big-Endian. 282 +--------------+-----------+---------------------------------+ 283 | FIELD | SIZE | DESCRIPTION | 284 +--------------+-----------+---------------------------------+ 285 | ID Tag | 1 byte | Indicates the start of a frame. | 286 | | | Set at 0x41 (character 'A') | 287 +--------------+-----------+---------------------------------+ 288 | Protocol | 2 bytes | Indicates the CTP version. Byte | 289 | Version | | 1 indicates major version. Byte | 290 | | | 2 indicates minor version. | 291 +--------------+-----------+---------------------------------+ 292 | Virtual | 2 bytes | Indicates the Virtual Socket ID | 293 | Socket ID | | which identifies a user-defined | 294 | | | endpoint service. | 295 +--------------+-----------+---------------------------------+ 296 | Reserved | 1 byte | Reserved for future protocol | 297 | | | use. | 298 +--------------+-----------+---------------------------------+ 299 | Payload Size | 2 bytes | Size of the application layer | 300 | | | payload to follow. | 301 +--------------+-----------+---------------------------------+ 303 Figure 3.1b: CTP Frame Header Fields 305 3.2 Control Frames 307 CTP control frames are sent using virtual sockets 0 and 1 for client 308 and server originated commands, respectively. Control frames 309 contain the same header as standard CTP frames, but contain 310 additional command and tag data as part of the frame's payload. 311 All control frames must be acknowledged by the remote endpoint 312 before a new control frame can be sent. 314 0 1 315 0 1 2 3 4 5 6 7 8 9 0 1 316 +---+---+---+---+---+---+---+---+---+---+---+---+ 317 | I |VERSION|VIRTUAL| R |PAYLOAD| COMMAND | 318 | D | |SOCKET | S |SIZE | | 319 | | |ID | V | | | 320 +---+---+---+---+---+---+---+---+---+---+---+---+ 321 | TAGS (Variable Size) | 322 +---+---+---+---+---+---+---+---+---+---+---+---+ 324 Figure 3.2a: CTP Control Frame Header 326 3.3 Commands and Tags 328 Control frames (Section 3.2) contain a 4 byte command string that 329 indicates a particular action a remote endpoint must take. The 330 command string is located in the 4 bytes following the payload size 331 field. A control frame must not contain more than one command. 333 Many commands contain one or more parameters defined as tags. A tag 334 is structured as 2 bytes of ASCII text for the tag name, followed by 335 a 2 byte unsigned integer specifying the size of the value to 336 follow. There is no limit on the number of tags that can follow a 337 command. However, all tag data plus the command must be less than 338 the maximum frame payload size. Control frames may contain tags 339 that are not explicitly defined in this document, allowing an 340 implementer to extend the functionality of the control channels. 342 0 1 343 0 1 2 3 4 5 6 7 8 9 0 1... 344 +---+---+---+---+---+---+---+---+---+---+---+---+ 345 | TAG | SIZE | VALUE (Variable Size) | 346 | NAME | | | 347 +---+---+---+---+---+---+---+---+---+---+---+---+ 349 Figure 3.3a: CTP Tag 351 Commands and tags are part of the frame's payload. The length of the 352 data in the command and tags section must be reflected in the frame 353 header's payload size field. All control frames must be 354 acknowledged by the remote endpoint by sending an acknowledgement 355 command (ACK) back to the sender with a status code tag (ST) 356 indicating the status of the request (Section 3.4). The following 357 commands and tags must be supported: 359 AUTH (authenticate): The authentication command is sent to 360 authenticate a given CTP connection. The authentication command 361 is optional, and only used for CTP connections that require 362 authentication. The authentication command supports three forms 363 of authentication: credentials (username/password), token, and 364 client certificates. See Section 4.2 for more details on 365 authorization. The following tags are supported by this command: 367 UN: username (string) 369 PW: password (string) 371 TK: token (string) 373 CR: client certificate (base64 encoded string) 375 A successful authentication request shall return with an OK 376 status code (0x00). Requests that fail authentication shall 377 return with an UNAUTHORIZED status code (0x40). See Section 3.4 378 for more details on response status codes. 380 OPVS (open virtual socket): Requests that a virtual socket be opened 381 on the remote endpoint. The request specifies the endpoint 382 service and virtual socket identifier that must be used for the 383 virtual socket. See Section 6 for more details on virtual 384 socket establishment. The following tags are required by this 385 command: 387 SV: endpoint service (string) 389 VS: virtual socket identifier (unsigned 2 byte integer) 391 A successful open virtual socket acknowledgement frame shall 392 contain an OK status code (0x00). Failure status codes may 393 include PROTOCOL_NOT_SUPPORTED (0x60), 394 VIRTUAL_SOCKET_ALREADY_OPEN (0x61), and 395 VIRTUAL_SOCKET_UNAVAILABLE (0x63). See Section 3.4 for more 396 details on response status codes. 398 CLVS (close virtual socket): Requests that a virtual socket be 399 closed on the remote endpoint. The request specifies the 400 virtual socket identifier which specifies the virtual socket to 401 be closed. See Section 6.2 for more details on the virtual 402 socket life-cycle. The following tags are required by this 403 command: 405 VS: virtual socket identifier (unsigned 2 byte integer) 407 A successful close virtual socket acknowledgement frame shall 408 contain an OK status code (0x00). Failure status codes may 409 include VIRTUAL_SOCKET_ALREADY_CLOSED (0x62). See Section 3.4 410 for more details on response status codes. 412 ACK (acknowledgement): Acknowledgements are sent in response to 413 control frames. All control frames must be acknowledged using 414 the ACK command. The acknowledgement frame must contain a 415 status tag (ST) indicating the return status of the request 416 (Section 3.4). Additional trace data may be returned using the 417 EX and TR tags. The following tags are supported by this 418 command: 420 ST: status (unsigned 2 byte integer) 422 EX: exception message (string) 424 TR: stack trace (string) 426 SVLT (service list): Retrieves a list of endpoint services 427 (Section 5) supported by the connected endpoint. There are no 428 tags associated with this command. 430 The remote endpoint shall return a list of SV tags indicating 431 the service labels that are exposed through the endpoint. 432 Multiple SV tags are supported in the acknowledgement response. 433 An OK status code (0x00) tag must be included in the list of 434 tags (Section 3.4). 436 SYNC (synchronize): Retrieves a list of virtual sockets that are 437 currently allocated on the remote endpoint. There are no tags 438 associated with this command. 440 The remote endpoint shall return a list of open virtual sockets 441 using a SV tag to identify the service and a VS tag to identify 442 the virtual socket identifier of the open virtual socket. 443 Multiple SV/VS tags are supported in the acknowledgement 444 response. An OK status code (0x00) must be included in the list 445 of tags (Section 3.4) 447 PING (ping): Pings the remote endpoint to ensure CTP connectivity. 448 This should be used for application-layer keepalive messages. 449 There are no tags associated with this command. 451 The remote endpoint must return an acknowledgement with an OK 452 status code (0x00) (Section 3.4). 454 3.4 Control Frame Acknowledgements 456 While standard CTP frames do not require responses, all CTP control 457 frames must be acknowledged by the remote endpoint. Acknowledgement 458 frames are control frames with the command field set to "ACK". All 459 acknowledgement frames have a status tag (ST) set to indicate the 460 status of the request. The status tag is represented as a 1 byte 461 value corresponding to one of the following values: 463 OK (0x0): Indicates that the control frame was successfully 464 processed. 466 ALREADY_AUTHENTICATED (0x01): Returned when an authentication 467 command (AUTH) (Section 3.3) has been sent after the connection 468 is already authenticated. 470 BUSY (0x07): Indicates the endpoint is currently busy processing a 471 previously received control frame (Section 3.2). 473 UNAUTHORIZED (0x40): Indicates that the authentication command 474 (AUTH) (Section 3.3) was received, but contained missing or 475 incorrect authentication information. 477 FORBIDDEN (0x41): Returned when a command is sent to a remote 478 endpoint before a successful authentication command (AUTH) 479 (Section 3.3) was received or access to a requested resourced 480 was denied. 482 SERVICE_NOT_SUPPORTED (0x60): Indicates that the remote endpoint 483 does not support the specified service or resource (Section 5) 484 supplied with an open virtual socket (OPVS) command 485 (Section 3.3). 487 VIRTUAL_SOCKET_ALREADY_OPEN (0x61): Returned when the remote 488 endpoint already has a virtual socket with the specified 489 identifier open. This error code indicates that the server and 490 client are not synchronized. Possibly returned due to a faulty 491 CTP implementation. 493 VIRTUAL_SOCKET_ALREADY_CLOSED (0x62): Indicates that the close 494 virtual socket command (CLVS) (Section 3.3) was not successful 495 because the virtual socket is already closed on the remote 496 endpoint. 498 VIRTUAL_SOCKET_UNAVAILABLE (0x63): Indicates that the remote 499 endpoint has no further virtual sockets available. See Section 500 6.3 for more details on virtual socket allocation. 502 INVALID_TAG (0x80): Indicates that the remote endpoint was unable to 503 process a command because it contained tags that were not valid 504 for the command. 506 INVALID_STATUS (0x81): Indicates that a status code was not 507 recognized by the remote endpoint. 509 INVALID_COMMAND (0x82): Returned when the remote endpoint receives a 510 control command (Section 3.3) that it does not recognize. 512 TIMEOUT (0x90): Indicates that the command timed out during 513 processing on the remote endpoint. 515 GENERAL_ERROR (0xFF): Indicates that an application-layer CTP error 516 occurred on the endpoint. 518 Application layer errors (0xFF) are used to troubleshoot CTP 519 software implementations and are not meant to be used to indicate an 520 error with a service being tunneled through CTP. Optionally, 521 applications can choose to supply more information to the remote 522 endpoint by adding an EX tag for an error message and/or a TR tag 523 with an attached stack trace. See Section 3.3 for more information 524 about supported acknowledgement command (ACK) tags. 526 4. Initial Connection 528 A Cloud Tunneling Protocol connection is created when a TCP/IP 529 socket is established between a CTP client and a CTP server. The 530 originator of the TCP/IP socket is known as the CTP client. The 531 receiver of the TCP/IP socket is known as the CTP server. 533 4.1 Establishment 535 A CTP connection is established by the CTP client establishing a 536 TCP/IP socket connection to the CTP server. If the client does not 537 require authentication, the connection is considered established. 538 If the client is required to authenticate then the AUTH command 539 (Section 3.3) must be sent and acknowledged successfully before the 540 connection is considered established. 542 4.2 Authentication/Authorization 544 The protocol supports three different methods of authenticating a 545 CTP connection: credentials (user/password), token, and client 546 certificates. CTP authentication occurs when the CTP client sends 547 the authorization command (AUTH) (Section 3.3). CTP does not 548 provide a mechanism for authorizing access to specific resources. 549 This should be handled at the CTP application layer or at the 550 service application layer if necessary. 552 +-------------+-----------+---------------------------------+ 553 | TYPE | TAGS | DESCRIPTION | 554 |-------------+-----------+---------------------------------+ 555 | Token | TR | String formatted token. | 556 +-------------+-----------+---------------------------------+ 557 | Credentials | UN | String formatted user name. | 558 | | PW | String formatted password. | 559 +-------------+-----------+---------------------------------+ 560 | Client | CR | Base64 encoded string | 561 | Certificate | | representation of binary | 562 | | | certificate content. | 563 +-------------+-----------+---------------------------------+ 565 Figure 4.2a: CTP Authentication Types 567 4.3 Transport Security 569 CTP does not define any encryption or transport security. 570 Implementations of CTP that utilize authorization functionality or 571 tunnel sensitive data should use SSL/TLS sockets in their 572 implementation to remain secure. CTP sockets can be wrapped in a 573 SSL/TLS connection for both encryption and transport layer security, 574 making use of existing PKI infrastructure. See RFC 2246 [RFC2246] 575 and RFC 6101 [RFC6101] for more information. 577 4.4 Keepalives 579 Determining when and where an endpoint is connected is a common 580 problem driving many scalable server based architectures that exist 581 today. CTP attempts to solve this problem with the addition of an 582 optional keepalive mechanism on-top of the existing TCP/IP keepalive 583 implementation. CTP will, by default, utilize the existing TCP/IP 584 keepalive to determine if a connection is dropped unexpectedly. 585 These keepalive timers should be set to a low interval to ensure 586 speedy notification of a dropped connection. 588 CTP also provides an application layer keepalive through the ping 589 command (PING) (Section 3.3). The ping command allows either 590 endpoint in a CTP connection to ping the remote endpoint. Ping 591 commands are replied with a standard CTP acknowledgement control 592 frame (ACK) (Section 3.3). These application layer keepalives can 593 optionally be used to ensure that the CTP stack is operating 594 correctly. These events can be scheduled at periodic intervals and 595 used to refresh statistics and status of a given connection. 597 5. Endpoint Services 599 Endpoint services are resources or services advertised by a remote 600 endpoint. After a CTP connection has been established and validated 601 (Section 4), either endpoint can request a list of supported 602 services from the remote endpoint by issuing the service list 603 command (SVLT) (Section 3.3). Endpoint services are represented as 604 string based labels used by an endpoint to route a virtual socket to 605 an associated service. Examples of protocol labels include: 606 1. HTTP 607 2. RTSP 608 3. 80 609 4. 1935 610 5. localhost:554 611 6. service.example 612 7. service.example:80 614 Each CTP endpoint determines how to route a given request to the 615 appropriate service. Each implementation may handle label request 616 routing differently. For most use cases, it is strongly recommended 617 that the domain:port format is used as it provides the greatest 618 amount of flexibility with minimal configuration. 620 6. Virtual Sockets 622 Virtual sockets are used to indicate a particular TCP/IP 623 conversation being multiplexed over a CTP connection. Each frame 624 specifies a particular conversation based on the value of the 625 virtual socket ID field specified in the frame header (Section 3.1). 626 The Cloud Tunneling Protocol supports up to 65,536 virtual sockets 627 per TCP/IP connection. 629 6.1 Reserved Virtual Sockets 631 CTP reserves two channels for control communication between 632 endpoints. Virtual socket identifier 0 and 1 are reserved for this 633 use. When a CTP connection is initially established between two 634 hosts, the initiator sends the authentication command (AUTH) 635 (Section 3.3) over virtual socket 0 if authentication is enabled. 636 All commands originating from the CTP client (the CTP connection 637 originator) must be sent using virtual socket 0. Commands 638 originating from the CTP server (the CTP connection receiver) must 639 be sent using virtual socket 1. 641 6.2 Virtual Socket Life-Cycle 643 Virtual sockets can be opened and closed by either endpoint at any 644 point after the initial connection is established if necessary. 645 During virtual socket initialization, one endpoint issues an open 646 virtual socket command (OPVS) (Section 3.3) which indicates the 647 particular service or resource the endpoint is interested in 648 accessing, as well as the virtual socket identifier to associate 649 with this virtual connection. Once the remote endpoint processes 650 the command and allocates the same virtual socket ID, the remote 651 endpoint must reply to the request by sending an acknowledgement 652 command (ACK) (Section 3.3) back on the same control virtual socket 653 the request originated. 655 The virtual socket can remain open as long as necessary and even 656 persist for the lifetime of the CTP connection. However, virtual 657 sockets should be closed when no longer needed to conserve resources 658 on both the client and server CTP endpoints. Virtual sockets can be 659 closed by issuing the close virtual socket command (CLVS) 660 (Section 3.3). 662 6.3 Virtual Socket Allocation 664 Virtual socket identifiers are allocated by the originating endpoint 665 on demand when an open virtual socket request is issued. Virtual 666 sockets opened from the CTP client endpoint must issue even numbered 667 virtual socket identifiers, while virtual sockets originating from 668 the CTP server endpoint must issue odd numbered virtual socket 669 identifiers. This ensures that no identifier collisions occur if 670 both the server and client attempt to open a virtual socket at the 671 same time. 673 Client originated virtual sockets must start being assigned at 2. 674 Server originated virtual sockets must start being assigned at 3. 675 Each endpoint must keep track of the last allocated virtual socket 676 identifier and increment (by two) from that point. Once the maximum 677 number of virtual socket identifiers is reached, counting must 678 roll-over and start again at the starting number. If no additional 679 free virtual socket identifiers exist, an error condition must be 680 raised to the caller. 682 7. IANA Considerations 684 A string for identifying CTP is entered into the 685 "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" 686 registry established in [RFC7301]. 688 7.1 Registration of CTP Identification Strings 690 This document creates a registration for the identification of CTP 691 in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" 692 registry established in [RFC7301]. 694 The "ctp/1" string identifies CTP when used over TLS: 696 Protocol: CTP over TLS 698 Identification Sequence: 0x63 0x74 0x70 0x2f 0x31 0x73 700 Specification: This document 702 8. Security Considerations 704 8.1 Denial of Service 706 CTP connections require some state management and therefore must 707 allocate some amount of server resources to maintaining each 708 connection's state (socket status and virtual sockets). When 709 handling a large amount of concurrent connections it is important to 710 manage resources efficiently. CTP connections are dependent on 711 TCP/IP sockets, so the same care maintaining TCP/IP sockets must be 712 taken for CTP connections. 714 8.1.1 Connection Starving 716 Connection starving occurs when a TCP connection is established from 717 the CTP client to the CTP server, but no data is transferred over 718 this connection. Resources are allocated by the server to handle 719 the maintenance of this TCP socket even though it is not being 720 utilized. A large amount of these inactive connections could cause 721 a denial of service. Server implementations should terminate TCP/IP 722 sockets that don't send data after a given period of time to 723 conserve server resources. 725 8.1.2 Zombie TCP/IP Connections 727 A zombie TCP/IP connection is a TCP/IP socket that has been properly 728 established, but the client has unexpectedly terminated the socket 729 without notifying the remote endpoint. The server implementation 730 may never know that this socket has been terminated if data is not 731 transmitted through it. Maintaining a large number of these zombie 732 TCP/IP connections could consume significant server resources 733 leading to a denial of service. It is recommended that TCP/IP 734 keepalives be used for all CTP sockets to ensure that this situation 735 is avoided. See Section 4.4 for more details on sending TCP/IP 736 keepalives. 738 8.1.3 Zombie CTP Connections 740 A zombie CTP connection is a CTP connection that has been properly 741 established and has an active TCP/IP socket, but the underlying CTP 742 implementation is not transmitting data. This connection is 743 actively using server resources, but is not functional. Server 744 implementations that do not actively determine the validity of a CTP 745 connection are at risk of a denial of service based on these 746 conditions. It is recommended that server implementations implement 747 a ping mechanism as discussed in Section 4.4. 749 8.1.4 Data Flooding 751 Data flooding can occur when one CTP connection sends a greater 752 amount of data than other connections. The larger amount of data 753 may be unfairly processed by the CTP server implementation, slowing 754 down data processing of other connections. CTP server 755 implementations should fairly read and process incoming data to 756 ensure that all connections are not slowed down by a busy 757 connection. 759 8.2 Command Length Security 761 It is possible that the sum of the tag lengths in a control frame 762 exceeds the maximum frame length. As discussed in Section 3.3, a 763 control frame's command and tag data must never exceed the frame's 764 payload size, as such these frames are invalid. CTP implementations 765 must respond with an acknowledgement command (ACK) (Section 3.3) 766 with the status code set to INVALID_COMMAND (0x82) (Section 3.4). 767 When processing control frames, implementations must not read beyond 768 the frame's payload size (Section 3.1). 770 8.3 Label Logic Considerations 772 Implementations should not parse endpoint service labels to 773 determine what services to connect to. Endpoint services should be 774 explicitly defined, specifying which endpoint services are exposed. 775 Open virtual socket command (OPVS) (Section 3.3) can then be used to 776 access these explicitly defined services. 778 9. References 780 9.1 Normative References 782 [RFC2119] 783 Bradner S., "Key words for use in RFCs to Indicate Requirement 784 Levels", BCP 14, RFC 2119, March 1997. 786 [RFC20] 787 "ASCII format for Network Interchange", RFC 20, October 16th, 788 1969. 790 [RFC793] 791 "Transmission Control Protocol", RFC 793, September 1981. 793 [RFC7301] 794 Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport 795 Layer Security (TLS) Application-Layer Protocol Negotiation 796 Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014. 798 9.2 Informative References 800 [RFC2246] 801 Dierks T., Allen C., "The TLS Protocol", RFC 2246, January 1999. 803 [RFC6101] 804 Freier A., Karlton P., Kocher P., "The Secure Sockets Layer 805 (SSL) Protocol Version 3.0", RFC 6101, August 2011 807 10.1 Appendix A. Connection Dataflow 809 Diagram 1 below depicts the typical CTP initial connection dataflow. 810 After standard TCP[1] and SSL/TLS[2] negotiations, the CTP client 811 sends the AUTH authentication request[3]. The CTP server verifies 812 the client credentials and responds with and acknowledgement command 813 (ACK) [4]. At that point both connecting endpoints advertise their 814 corresponding endpoint services via service list (SVLT) requests and 815 acknowledgements. Note that the CTP client uses virtual socket (VS) 816 0 and the CTP server uses VS 1. As indicated, those virtual sockets 817 IDs are reserved for CTP control. In the below diagram the CTP 818 server advertises HTTP services [6] and the CTP client shows HTTP 819 and RTSP internal server capabilities [8]. That concludes the 820 initial CTP exchange. Both CTP endpoints are now ready to provide 821 their services. 823 +----+ +----+ 824 | | | | 825 | |[1] +---------------+ | | 826 | |<------------>| TCP Handshake |<-------------->| | 827 | | +---------------+ | | 828 | |[2] +---------------+ | | 829 | |<------------>| TLS Handshake |<-------------->| | 830 | | +---------------+ | | 831 | |[3] +---------------+ | | 832 | |----VS:0----> | AUTH / UN+PW | ------------> | | 833 | | +---------------+ | | 834 | T |[4] +---------------+ | T | 835 | C |<------------ | ACK / ST | <---VS:0----- | C | 836 | P | +---------------+ | P | 837 | |[5] +---------------+ | | 838 | |----VS:0----> | SVLT | ------------> | | 839 | C | +---------------+ | S | 840 | L | +---------------+ | E | 841 | I |[6] | ACK / ST:OK | | R | 842 | E |<------------ | / SV:HTTP | <---VS:0----- | V | 843 | N | | | | E | 844 | T | +---------------+ | R | 845 | |[7] +---------------+ | | 846 | |<----------- | SVLT | <---VS:1----- | | 847 | | +---------------+ | | 848 | | +---------------+ | | 849 | |[8] | ACK / ST:OK | | | 850 | |---VS:1-----> | / SV:HTTP | ------------> | | 851 | | | / SV:RTSP | | | 852 | | +---------------+ | | 853 | | | | 854 +----+ +----+ 856 Diagram 1: Initial Connection Data Flow 858 10.2 Appendix B. Virtual Socket Dataflow 860 Diagram 2 shows the typical virtual socket dataflow. As indicated 861 in diagram 1, the CTP client broadcast HTTP service capability which 862 is requested by the CTP server endpoint. The server initiates the 863 virtual socket by sending the open virtual socket (OPVS) [1] command 864 to TCP client indicating that the service endpoint (HTTP) and 865 virtual socket ID (VS:3) has been allocated for that request. Note 866 that control virtual socket 1 is used by TCP server. The TCP client 867 responds with the acknowledgement [2]. At that point the HTTP 868 request [3] and HTTP response [4] are sent from communicating 869 endpoints on virtual socket 3 (VS:3). 871 +----+ +----+ 872 | | | | 873 | | | | 874 | | +---------------+ | | 875 | |[1] | OPVS/ SV:HTTP | | | 876 | |<------------ | / VS:0003 | <--VS:1------ | | 877 | T | | | | T | 878 | C | +---------------+ | C | 879 | P |[2] +---------------+ | P | 880 | |---VS:1-----> | ACK / ST | ------------> | | 881 | | +---------------+ | | 882 | C | | S | 883 | L | HTTP Data Session | E | 884 | I | +---------------+ | R | 885 | E |[3] | VS:0003 | | V | 886 | N |<------------ |GET / HTTP/1.1 | <---VS:3----- | E | 887 | T | |... | | R | 888 | | +---------------+ | | 889 | | +---------------+ | | 890 | |[4] | VS:0003 | | | 891 | |---VS:3-----> |HTTP/1.1 200 OK| ------------> | | 892 | | |... | | | 893 | | +---------------+ | | 894 | | | | 895 | | | | 896 +----+ +----+ 898 Diagram 2: Virtual Socket Data Flow - HTTP Data Example 900 Authors' Addresses 902 Piotr Romanczyk 903 Honeywell 905 EMail: piotr.romanczyk@honeywell.com 907 Christopher Colicino 908 Honeywell 910 EMail: christopher.colicino@honeywell.com 912 Michael Landi 913 Honeywell 915 EMail: michael.landi@honeywell.com 917 Tomas Brodsky 918 Honeywell 920 EMail: tomas.brodsky@honeywell.com 922 IPR Disclosure 924 "By submitting this Internet-Draft, each author represents that any 925 applicable patent or other IPR claims of which he or she is aware 926 have been or will be disclosed, and any of which he or she becomes 927 aware will be disclosed, in accordance with Section 6 of BCP 79." 929 Disclaimer 931 "This document and the information contained herein are provided on 932 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 933 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 934 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 935 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 936 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 937 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 939 Expires September 8, 2017