Internet DRAFT - draft-honeywell-ctp

draft-honeywell-ctp



Internet Engineering Task Force                             P. Romanczyk
Internet-Draft                                               C. Colicino
Intended Status: Standard                                       M. Landi
Expires: May 13, 2018                                         T. Brodsky
                                                               Honeywell
                                                       November 13, 2017

                    Cloud Tunneling Protocol (CTP)
                     draft-honeywell-ctp-04.txt

Abstract

    This specification defines operating semantics of the Cloud
    Tunneling Protocol (CTP).  CTP enables a standardized mechanism for
    connecting Internet-of-Things (IoT) devices to hosted cloud
    services.  CTP provides a network efficient means to facilitate
    multiple concurrent data conversations over the same channel by
    providing multiplexed virtual sockets.  The protocol allows for
    services on either endpoint to be advertised and accessible to each
    endpoint of the CTP connection.
    
Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents 
    at any time.  It is inappropriate to use Internet-Drafts as 
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/1id-abstracts.html

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

    This Internet-Draft will expire on May 13, 2018.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

    1.   Introduction
    1.1   Protocol Overview
    1.2   Definitions of Commonly Used Terms
    2.   Requirements Language
    3.   Encapsulation
    3.1   Frame Header
    3.2   Control Frames
    3.3   Commands and Tags
    3.4   Control Frame Acknowledgements
    4.   Initial Connection
    4.1   Establishment
    4.2   Authentication/Authorization
    4.3   Transport Security
    4.4   Keepalives
    5.   Endpoint Services
    6.   Virtual Sockets
    6.1   Reserved Virtual Sockets
    6.2   Virtual Socket Life-Cycle
    6.3   Virtual Socket Allocation
    7.   IANA Considerations
    7.1   Registration of CTP Identification Strings
    8.   Security Considerations
    8.1   Denial of Service
    8.1.1  Connection Starving
    8.1.2  Zombie TCP/IP Connections
    8.1.3  Zombie CTP Connections
    8.1.4  Data Flooding
    8.2   Command Length Security
    8.3   Label Logic Considerations
    9.   References
    9.1.   Normative References
    9.2.   Informative References
    10.  Appendices
    10.1  Appendix A. Connection Dataflow
    10.2  Appendix B. Virtual Socket Dataflow
    Authors' Addresses
    IPR Disclosure
    Disclaimer

1.  Introduction

    This document is a specification of the Cloud Tunneling Protocol
    (CTP).  CTP communication normally occurs over a TCP/IP socket
    connection. CTP is an application layer protocol that can multiplex
    multiple TCP/IP [RFC793] sockets over a single connection.  In the
    context of the Internet Suite (TCP/IP), the CTP protocol is located
    above the transport layer and below other application-layer
    protocols.  This protocol describes a method of exposing and
    tunneling multiple services on both the client and server endpoints
    through a single TCP/IP connection. CTP is a departure from standard
    virtual private network (VPN) protocols as it does not define a
    method for accessing network based resources directly.  Instead,
    resources are defined at the CTP application layer and resolved by
    either endpoint as configured.

    The CTP protocol was developed by the CTP working group.  It is
    created to operate specifically for the TCP/IP Internet environment,
    wrapping multiple bi-directional TCP/IP conversations within a
    single connection.  The protocol was designed to facilitate the
    access of multiple services simultaneously between two endpoints,
    with data traversing complex networks interpolated with routers,
    firewalls, and network address translation.  Much work has been done
    to produce an efficient protocol that can provide the type of
    connectivity discussed.

        [ Application ] <---Process to Process---> [ Application ]
        [     CTP     ]                            [     CTP     ]
        [  Transport  ] <------Host to Host------> [  Transport  ]
        [  Internet   ]                            [  Internet   ]
        [     Link    ]                            [     Link    ]
               ^                                          ^
               |__________________________________________|

               Figure 1a: CTP in the Internet Protocol Suite

1.1  Protocol Overview

    CTP assumes a long-lived TCP/IP connection established between a
    client and a remote server.  This connection is assumed to be
    originated from the client.  In general, a client establishes a
    single connection to the remote server for efficiency.  The CTP
    protocol describes how to achieve multiple TCP/IP conversations over
    this single connection.

    The CTP protocol is a binary protocol which encapsulates application
    layer data into frames for transport.  These frames provide the
    ability to multiplex multiple conversations on a single connection
    by designating which conversation, or virtual socket, the frame is
    associated with.

    Once a connection is established, all communication between the two
    endpoints is bidirectional for any TCP/IP conversation.  Each
    endpoint can run in either a client or server context using multiple
    virtual sockets.  As such, both the client and server endpoints can
    establish virtual sockets over this single CTP connection.  CTP
    utilizes control messages to negotiate the establishment,
    maintenance, and tear-down of virtual sockets over the lifetime of
    this connection.

    Establishing a virtual socket signals to the remote endpoint the
    initiator's intent to access a remote service.   Once a virtual
    socket is established, data can be transmitted over this channel.
    Data is multiplexed and encapsulated into frames on the sending
    endpoint.  On the receiving endpoint, frames are demultiplexed and
    de-encapsulated.  All communication between endpoints is
    deterministic with a fixed frame header specifying the payload size
    to follow.

   [HTTP]  [RTSP]  [RTMP] <-----------------> [HTTP]  [RTSP]  [RTMP]
        [ Application ] <---Process to Process---> [ Application ]
        [     CTP     ]                            [     CTP     ]
        [  Transport  ] <------Host to Host------> [  Transport  ]
        [  Internet   ]                            [  Internet   ]
        [     Link    ]                            [     Link    ]
               |                                          |
               |__________________________________________|

       Figure 1.1b: Example Applications Tunneled through CTP

         Multiple application-layer processes with CTP within
         the context of the Internet Protocol Suite.
         By utilizing the protocol, both the TCP/IP client and
         TCP/IP server can expose their own services.

1.2  Definitions of Commonly Used Terms

    This section provides definitions for the terms that have a specific
    meaning to the CTP protocol.  These terms are used throughout this
    specification.

    Endpoint
        One end of a TCP/IP socket connection.  This term refers to
        either a TCP/IP server or client.

    Local Endpoint
         The local end of a TCP/IP socket connection from the reader's
         perspective.

    Remote Endpoint
         The remote end of a TCP/IP socket connection from the reader's
         perspective.

    CTP Client
        The endpoint from which the CTP connection originated.

    CTP Server
        The endpoint that received the CTP connection.

    Frame
        The basic unit of transmission in CTP.  Encapsulates application
        layer data and specifies a particular TCP/IP conversation.

    Control Frame
        Extends a standard CTP frame to include a command, or action, as
        well as parameters in the frame's payload.

    String
        A finite sequence of ASCII encoded characters as defined in RFC
        20 [RFC20].

    Command
        An action represented as a 4 byte string in a control frame.

    Tag
        A key/value pair used to represent a parameter for a given
        control frame's command.

    Endpoint Service
        A service or resource as advertised and exposed by a CTP
        endpoint.

    Virtual Socket
        A single TCP/IP conversation in a multiplexed CTP connection.

    Service Label
        A string that identifies a given endpoint service.  Service
        labels are advertised by endpoints and used to specify which
        services endpoints are accessing through a virtual socket.

2.  Requirements Language

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in BCP 14, RFC 2119
    [RFC2119].

3.  Frame Encapsulation

    CTP encapsulates and interleaves both data and control messages into
    transmission units called frames.  All frames must begin with a
    fixed size header (8 bytes).  The frame header provides the protocol
    with information about what data the frame encapsulates.  This
    information is used to determine which TCP/IP conversation, or
    virtual socket, the frame is associated with.

    The header also specifies the length of the data payload to follow.
    The maximum size of a frame is 65,543 bytes including the 8 byte
    header. The maximum frame payload size is 65,535 bytes.  Frames can
    be split over multiple TCP/IP packets if necessary, but the entire
    frame must be sent in full before the next frame can be sent.

3.1  Frame Header

    Following the TCP/IP header, the packet's payload will contain one
    or more CTP frames.  Each frame header must have the following
    structure:

                  0
                  0   1   2   3   4   5   6   7
                +---+---+---+---+---+---+---+---+
                | I |VERSION|VIRTUAL| R |PAYLOAD|
                | D |       |SOCKET | S |SIZE   |
                |   |       |ID     | V |       |
                +---+---+---+---+---+---+---+---+

              Figure 3.1a: CTP Frame Header Layout

    These frame fields are described in detail in Figure 3.1b. All
    numerical values in the frame header must be encoded as Big-Endian.

        +--------------+-----------+---------------------------------+
        | FIELD        | SIZE      | DESCRIPTION                     |
        +--------------+-----------+---------------------------------+
        | ID Tag       | 1 byte    | Indicates the start of a frame. |
        |              |           | Set at 0x41 (character 'A')     |
        +--------------+-----------+---------------------------------+
        | Protocol     | 2 bytes   | Indicates the CTP version. Byte |
        | Version      |           | 1 indicates major version. Byte |
        |              |           | 2 indicates minor version.      |
        +--------------+-----------+---------------------------------+
        | Virtual      | 2 bytes   | Indicates the Virtual Socket ID |
        | Socket ID    |           | which identifies a user-defined |
        |              |           | endpoint service.               |
        +--------------+-----------+---------------------------------+
        | Reserved     | 1 byte    | Reserved for future protocol    |
        |              |           | use.                            |
        +--------------+-----------+---------------------------------+
        | Payload Size | 2 bytes   | Size of the application layer   |
        |              |           | payload to follow.              |
        +--------------+-----------+---------------------------------+

                    Figure 3.1b: CTP Frame Header Fields

3.2  Control Frames

    CTP control frames are sent using virtual sockets 0 and 1 for client
    and server originated commands, respectively.  Control frames
    contain the same header as standard CTP frames, but contain
    additional command and tag data as part of the frame's payload.
    All control frames must be acknowledged by the remote endpoint
    before a new control frame can be sent.

              0                                       1
              0   1   2   3   4   5   6   7   8   9   0   1
            +---+---+---+---+---+---+---+---+---+---+---+---+
            | I |VERSION|VIRTUAL| R |PAYLOAD|    COMMAND    |
            | D |       |SOCKET | S |SIZE   |               |
            |   |       |ID     | V |       |               |
            +---+---+---+---+---+---+---+---+---+---+---+---+
            |              TAGS (Variable Size)             |
            +---+---+---+---+---+---+---+---+---+---+---+---+

                  Figure 3.2a: CTP Control Frame Header

3.3  Commands and Tags

    Control frames (Section 3.2) contain a 4 byte command string that
    indicates a particular action a remote endpoint must take.  The
    command string is located in the 4 bytes following the payload size
    field.  A control frame must not contain more than one command.

    Many commands contain one or more parameters defined as tags.  A tag
    is structured as 2 bytes of ASCII text for the tag name, followed by
    a 2 byte unsigned integer specifying the size of the value to
    follow.  There is no limit on the number of tags that can follow a
    command.  However, all tag data plus the command must be less than
    the maximum frame payload size.  Control frames may contain tags
    that are not explicitly defined in this document, allowing an
    implementer to extend the functionality of the control channels.

                  0                                       1
              0   1   2   3   4   5   6   7   8   9   0   1...
            +---+---+---+---+---+---+---+---+---+---+---+---+
            | TAG   | SIZE  | VALUE (Variable Size)         |
            | NAME  |       |                               |
            +---+---+---+---+---+---+---+---+---+---+---+---+

                          Figure 3.3a: CTP Tag

    Commands and tags are part of the frame's payload. The length of the
    data in the command and tags section must be reflected in the frame
    header's payload size field.  All control frames must be
    acknowledged by the remote endpoint by sending an acknowledgement
    command (ACK) back to the sender with a status code tag (ST)
    indicating the status of the request (Section 3.4). The following
    commands and tags must be supported:

    AUTH (authenticate): The authentication command is sent to
        authenticate a given CTP connection.  The authentication command
        is optional, and only used for CTP connections that require
        authentication.  The authentication command supports three forms
        of authentication: credentials (username/password), token, and
        client certificates.  See Section 4.2 for more details on
        authorization. The following tags are supported by this command:

            UN: username (string)

            PW: password (string)

            TK: token (string)

            CR: client certificate (base64 encoded string)

        A successful authentication request shall return with an OK
        status code (0x00).  Requests that fail authentication shall
        return with an UNAUTHORIZED status code (0x40).  See Section 3.4
        for more details on response status codes.

    OPVS (open virtual socket): Requests that a virtual socket be opened
        on the remote endpoint.  The request specifies the endpoint
        service and virtual socket identifier that must be used for the
        virtual socket.  See Section 6 for more details on virtual
        socket establishment.  The following tags are required by this
        command:

            SV: endpoint service (string)

            VS: virtual socket identifier (unsigned 2 byte integer)

        A successful open virtual socket acknowledgement frame shall
        contain an OK status code (0x00).  Failure status codes may
        include PROTOCOL_NOT_SUPPORTED (0x60),
        VIRTUAL_SOCKET_ALREADY_OPEN (0x61), and
        VIRTUAL_SOCKET_UNAVAILABLE (0x63).  See Section 3.4 for more
        details on response status codes.

    CLVS (close virtual socket): Requests that a virtual socket be
        closed on the remote endpoint.  The request specifies the
        virtual socket identifier which specifies the virtual socket to
        be closed.  See Section 6.2 for more details on the virtual
        socket life-cycle.  The following tags are required by this
        command:

            VS: virtual socket identifier (unsigned 2 byte integer)

        A successful close virtual socket acknowledgement frame shall
        contain an OK status code (0x00).  Failure status codes may
        include VIRTUAL_SOCKET_ALREADY_CLOSED (0x62).  See Section 3.4
        for more details on response status codes.

    ACK (acknowledgement):  Acknowledgements are sent in response to
        control frames.  All control frames must be acknowledged using
        the ACK command.  The acknowledgement frame must contain a
        status tag (ST) indicating the return status of the request
        (Section 3.4).  Additional trace data may be returned using the
        EX and TR tags.  The following tags are supported by this
        command:

            ST: status (unsigned 2 byte integer)

            EX: exception message (string)

            TR: stack trace (string)

    SVLT (service list): Retrieves a list of endpoint services
        (Section 5) supported by the connected endpoint.  There are no
        tags associated with this command.

        The remote endpoint shall return a list of SV tags indicating
        the service labels that are exposed through the endpoint.
        Multiple SV tags are supported in the acknowledgement response.
        An OK status code (0x00) tag must be included in the list of
        tags (Section 3.4).

    SYNC (synchronize): Retrieves a list of virtual sockets that are
        currently allocated on the remote endpoint.  There are no tags
        associated with this command.

        The remote endpoint shall return a list of open virtual sockets
        using a SV tag to identify the service and a VS tag to identify
        the virtual socket identifier of the open virtual socket.
        Multiple SV/VS tags are supported in the acknowledgement
        response.  An OK status code (0x00) must be included in the list
        of tags (Section 3.4)

    PING (ping): Pings the remote endpoint to ensure CTP connectivity.
        This should be used for application-layer keepalive messages.
        There are no tags associated with this command.

        The remote endpoint must return an acknowledgement with an OK
        status code (0x00) (Section 3.4).

3.4  Control Frame Acknowledgements

    While standard CTP frames do not require responses, all CTP control
    frames must be acknowledged by the remote endpoint.  Acknowledgement
    frames are control frames with the command field set to "ACK".  All
    acknowledgement frames have a status tag (ST) set to indicate the
    status of the request.  The status tag is represented as a 1 byte
    value corresponding to one of the following values:

    OK (0x0): Indicates that the control frame was successfully
        processed.

    ALREADY_AUTHENTICATED (0x01): Returned when an authentication
        command (AUTH) (Section 3.3) has been sent after the connection
        is already authenticated.

    BUSY (0x07): Indicates the endpoint is currently busy processing a
        previously received control frame (Section 3.2).

    UNAUTHORIZED (0x40): Indicates that the authentication command
        (AUTH) (Section 3.3) was received, but contained missing or
        incorrect authentication information.

    FORBIDDEN (0x41): Returned when a command is sent to a remote
        endpoint before a successful authentication command (AUTH)
        (Section 3.3) was received or access to a requested resourced
        was denied.

    SERVICE_NOT_SUPPORTED (0x60): Indicates that the remote endpoint
        does not support the specified service or resource (Section 5)
        supplied with an open virtual socket (OPVS) command
        (Section 3.3).

    VIRTUAL_SOCKET_ALREADY_OPEN (0x61): Returned when the remote
        endpoint already has a virtual socket with the specified
        identifier open.  This error code indicates that the server and
        client are not synchronized.  Possibly returned due to a faulty
        CTP implementation.

    VIRTUAL_SOCKET_ALREADY_CLOSED (0x62): Indicates that the close
        virtual socket command (CLVS) (Section 3.3) was not successful
        because the virtual socket is already closed on the remote
        endpoint.

    VIRTUAL_SOCKET_UNAVAILABLE (0x63): Indicates that the remote
        endpoint has no further virtual sockets available.  See Section
        6.3 for more details on virtual socket allocation.

    INVALID_TAG (0x80): Indicates that the remote endpoint was unable to
        process a command because it contained tags that were not valid
        for the command.

    INVALID_STATUS (0x81): Indicates that a status code was not
        recognized by the remote endpoint.

    INVALID_COMMAND (0x82): Returned when the remote endpoint receives a
        control command (Section 3.3) that it does not recognize.

    TIMEOUT (0x90): Indicates that the command timed out during
        processing on the remote endpoint.

    GENERAL_ERROR (0xFF): Indicates that an application-layer CTP error
        occurred on the endpoint.

    Application layer errors (0xFF) are used to troubleshoot CTP
    software implementations and are not meant to be used to indicate an
    error with a service being tunneled through CTP. Optionally,
    applications can choose to supply more information to the remote
    endpoint by adding an EX tag for an error message and/or a TR tag
    with an attached stack trace.  See Section 3.3 for more information
    about supported acknowledgement command (ACK) tags.

4.  Initial Connection

    A Cloud Tunneling Protocol connection is created when a TCP/IP
    socket is established between a CTP client and a CTP server.  The
    originator of the TCP/IP socket is known as the CTP client.  The
    receiver of the TCP/IP socket is known as the CTP server.

4.1  Establishment

    A CTP connection is established by the CTP client establishing a
    TCP/IP socket connection to the CTP server.  If the client does not
    require authentication, the connection is considered established.
    If the client is required to authenticate then the AUTH command
    (Section 3.3) must be sent and acknowledged successfully before the
    connection is considered established.

4.2  Authentication/Authorization

    The protocol supports three different methods of authenticating a
    CTP connection: credentials (user/password), token, and client
    certificates.  CTP authentication occurs when the CTP client sends
    the authorization command (AUTH) (Section 3.3).  CTP does not
    provide a mechanism for authorizing access to specific resources.
    This should be handled at the CTP application layer or at the
    service application layer if necessary.

        +-------------+-----------+---------------------------------+
        | TYPE        | TAGS      | DESCRIPTION                     |
        |-------------+-----------+---------------------------------+
        | Token       | TR        | String formatted token.         |
        +-------------+-----------+---------------------------------+
        | Credentials | UN        | String formatted user name.     |
        |             | PW        | String formatted password.      |
        +-------------+-----------+---------------------------------+
        | Client      | CR        | Base64 encoded string           |
        | Certificate |           | representation of binary        |
        |             |           | certificate content.            |
        +-------------+-----------+---------------------------------+

                    Figure 4.2a: CTP Authentication Types

4.3  Transport Security

    CTP does not define any encryption or transport security.
    Implementations of CTP that utilize authorization functionality or
    tunnel sensitive data should use SSL/TLS sockets in their
    implementation to remain secure.  CTP sockets can be wrapped in a
    SSL/TLS connection for both encryption and transport layer security,
    making use of existing PKI infrastructure.  See RFC 2246 [RFC2246]
    and RFC 6101 [RFC6101] for more information.

4.4  Keepalives

    Determining when and where an endpoint is connected is a common
    problem driving many scalable server based architectures that exist
    today.  CTP attempts to solve this problem with the addition of an
    optional keepalive mechanism on-top of the existing TCP/IP keepalive
    implementation.  CTP will, by default, utilize the existing TCP/IP
    keepalive to determine if a connection is dropped unexpectedly.
    These keepalive timers should be set to a low interval to ensure
    speedy notification of a dropped connection.

    CTP also provides an application layer keepalive through the ping
    command (PING) (Section 3.3).  The ping command allows either
    endpoint in a CTP connection to ping the remote endpoint.  Ping
    commands are replied with a standard CTP acknowledgement control
    frame (ACK) (Section 3.3).  These application layer keepalives can
    optionally be used to ensure that the CTP stack is operating
    correctly.  These events can be scheduled at periodic intervals and
    used to refresh statistics and status of a given connection.

5.  Endpoint Services

    Endpoint services are resources or services advertised by a remote
    endpoint.  After a CTP connection has been established and validated
    (Section 4), either endpoint can request a list of supported
    services from the remote endpoint by issuing the service list
    command (SVLT) (Section 3.3).  Endpoint services are represented as
    string based labels used by an endpoint to route a virtual socket to
    an associated service. Examples of protocol labels include:
        1. HTTP
        2. RTSP
        3. 80
        4. 1935
        5. localhost:554
        6. service.example
        7. service.example:80

    Each CTP endpoint determines how to route a given request to the
    appropriate service.  Each implementation may handle label request
    routing differently.  For most use cases, it is strongly recommended
    that the domain:port format is used as it provides the greatest
    amount of flexibility with minimal configuration.

6.  Virtual Sockets

    Virtual sockets are used to indicate a particular TCP/IP
    conversation being multiplexed over a CTP connection.  Each frame
    specifies a particular conversation based on the value of the
    virtual socket ID field specified in the frame header (Section 3.1).
    The Cloud Tunneling Protocol supports up to 65,536 virtual sockets
    per TCP/IP connection.

6.1  Reserved Virtual Sockets

    CTP reserves two channels for control communication between
    endpoints.  Virtual socket identifier 0 and 1 are reserved for this
    use.  When a CTP connection is initially established between two
    hosts, the initiator sends the authentication command (AUTH)
    (Section 3.3) over virtual socket 0 if authentication is enabled.
    All commands originating from the CTP client (the CTP connection
    originator) must be sent using virtual socket 0.  Commands
    originating from the CTP server (the CTP connection receiver) must
    be sent using virtual socket 1.

6.2  Virtual Socket Life-Cycle

    Virtual sockets can be opened and closed by either endpoint at any
    point after the initial connection is established if necessary.
    During virtual socket initialization, one endpoint issues an open
    virtual socket command (OPVS) (Section 3.3) which indicates the
    particular service or resource the endpoint is interested in
    accessing, as well as the virtual socket identifier to associate
    with this virtual connection.  Once the remote endpoint processes
    the command and allocates the same virtual socket ID, the remote
    endpoint must reply to the request by sending an acknowledgement
    command (ACK) (Section 3.3) back on the same control virtual socket
    the request originated.

    The virtual socket can remain open as long as necessary and even
    persist for the lifetime of the CTP connection.  However, virtual
    sockets should be closed when no longer needed to conserve resources
    on both the client and server CTP endpoints.  Virtual sockets can be
    closed by issuing the close virtual socket command (CLVS)
    (Section 3.3).

6.3  Virtual Socket Allocation

    Virtual socket identifiers are allocated by the originating endpoint
    on demand when an open virtual socket request is issued.  Virtual
    sockets opened from the CTP client endpoint must issue even numbered
    virtual socket identifiers, while virtual sockets originating from
    the CTP server endpoint must issue odd numbered virtual socket
    identifiers.  This ensures that no identifier collisions occur if
    both the server and client attempt to open a virtual socket at the
    same time.

    Client originated virtual sockets must start being assigned at 2.
    Server originated virtual sockets must start being assigned at 3.
    Each endpoint must keep track of the last allocated virtual socket
    identifier and increment (by two) from that point.  Once the maximum
    number of virtual socket identifiers is reached, counting must
    roll-over and start again at the starting number.  If no additional
    free virtual socket identifiers exist, an error condition must be
    raised to the caller.

7.  IANA Considerations

    A string for identifying CTP is entered into the
    "Application-Layer Protocol Negotiation (ALPN) Protocol IDs"
    registry established in [RFC7301].

7.1  Registration of CTP Identification Strings

    This document creates a registration for the identification of CTP
    in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs"
    registry established in [RFC7301].

    The "ctp/1" string identifies CTP when used over TLS:

    Protocol:  CTP over TLS

    Identification Sequence: 0x63 0x74 0x70 0x2f 0x31 0x73

    Specification: This document

8.  Security Considerations

8.1  Denial of Service

    CTP connections require some state management and therefore must
    allocate some amount of server resources to maintaining each
    connection's state (socket status and virtual sockets).  When
    handling a large amount of concurrent connections it is important to
    manage resources efficiently.  CTP connections are dependent on
    TCP/IP sockets, so the same care maintaining TCP/IP sockets must be
    taken for CTP connections.

8.1.1  Connection Starving

    Connection starving occurs when a TCP connection is established from
    the CTP client to the CTP server, but no data is transferred over
    this connection.  Resources are allocated by the server to handle
    the maintenance of this TCP socket even though it is not being
    utilized.  A large amount of these inactive connections could cause
    a denial of service.  Server implementations should terminate TCP/IP
    sockets that don't send data after a given period of time to
    conserve server resources.

8.1.2  Zombie TCP/IP Connections

    A zombie TCP/IP connection is a TCP/IP socket that has been properly
    established, but the client has unexpectedly terminated the socket
    without notifying the remote endpoint.  The server implementation
    may never know that this socket has been terminated if data is not
    transmitted through it.  Maintaining a large number of these zombie
    TCP/IP connections could consume significant server resources
    leading to a denial of service.  It is recommended that TCP/IP
    keepalives be used for all CTP sockets to ensure that this situation
    is avoided.  See Section 4.4 for more details on sending TCP/IP
    keepalives.

8.1.3  Zombie CTP Connections

    A zombie CTP connection is a CTP connection that has been properly
    established and has an active TCP/IP socket, but the underlying CTP
    implementation is not transmitting data.  This connection is
    actively using server resources, but is not functional.  Server
    implementations that do not actively determine the validity of a CTP
    connection are at risk of a denial of service based on these
    conditions.  It is recommended that server implementations implement
    a ping mechanism as discussed in Section 4.4.

8.1.4  Data Flooding

    Data flooding can occur when one CTP connection sends a greater
    amount of data than other connections.  The larger amount of data
    may be unfairly processed by the CTP server implementation, slowing
    down data processing of other connections.  CTP server
    implementations should fairly read and process incoming data to
    ensure that all connections are not slowed down by a busy
    connection.

8.2  Command Length Security

    It is possible that the sum of the tag lengths in a control frame
    exceeds the maximum frame length.  As discussed in Section 3.3, a
    control frame's command and tag data must never exceed the frame's
    payload size, as such these frames are invalid.  CTP implementations
    must respond with an acknowledgement command (ACK) (Section 3.3)
    with the status code set to INVALID_COMMAND (0x82) (Section 3.4).
    When processing control frames, implementations must not read beyond
    the frame's payload size (Section 3.1).

8.3  Label Logic Considerations

    Implementations should not parse endpoint service labels to
    determine what services to connect to.  Endpoint services should be
    explicitly defined, specifying which endpoint services are exposed.
    Open virtual socket command (OPVS) (Section 3.3) can then be used to
    access these explicitly defined services.

9.  References

9.1  Normative References

    [RFC2119]
        Bradner S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

    [RFC20]
        "ASCII format for Network Interchange", RFC 20, October 16th,
        1969.

    [RFC793]
        "Transmission Control Protocol", RFC 793, September 1981.

    [RFC7301]
        Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport
        Layer Security (TLS) Application-Layer Protocol Negotiation
        Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014.

9.2  Informative References

    [RFC2246]
        Dierks T., Allen C., "The TLS Protocol", RFC 2246, January 1999.

    [RFC6101]
        Freier A., Karlton P., Kocher P., "The Secure Sockets Layer
        (SSL) Protocol Version 3.0", RFC 6101, August 2011

10.1  Appendix A. Connection Dataflow

    Diagram 1 below depicts the typical CTP initial connection dataflow.
    After standard TCP[1] and SSL/TLS[2] negotiations, the CTP client
    sends the AUTH authentication request[3].  The CTP server verifies
    the client credentials and responds with and acknowledgement command
    (ACK) [4].  At that point both connecting endpoints advertise their
    corresponding endpoint services via service list (SVLT) requests and
    acknowledgements.  Note that the CTP client uses virtual socket (VS)
    0 and the CTP server uses VS 1.  As indicated, those virtual sockets
    IDs are reserved for CTP control.  In the below diagram the CTP
    server advertises HTTP services [6] and the CTP client shows HTTP
    and RTSP internal server capabilities [8].  That concludes the
    initial CTP exchange.  Both CTP endpoints are now ready to provide
    their services.

       +----+                                               +----+
       |    |                                               |    |
       |    |[1]           +---------------+                |    |
       |    |<------------>| TCP Handshake |<-------------->|    |
       |    |              +---------------+                |    |
       |    |[2]           +---------------+                |    |
       |    |<------------>| TLS Handshake |<-------------->|    |
       |    |              +---------------+                |    |
       |    |[3]           +---------------+                |    |
       |    |----VS:0----> | AUTH / UN+PW  | ------------>  |    |
       |    |              +---------------+                |    |
       | T  |[4]           +---------------+                | T  |
       | C  |<------------ |    ACK / ST   | <---VS:0-----  | C  |
       | P  |              +---------------+                | P  |
       |    |[5]           +---------------+                |    |
       |    |----VS:0----> |     SVLT      | ------------>  |    |
       | C  |              +---------------+                | S  |
       | L  |              +---------------+                | E  |
       | I  |[6]           | ACK / ST:OK   |                | R  |
       | E  |<------------ |     / SV:HTTP | <---VS:0-----  | V  |
       | N  |              |               |                | E  |
       | T  |              +---------------+                | R  |
       |    |[7]           +---------------+                |    |
       |    |<-----------  |     SVLT      | <---VS:1-----  |    |
       |    |              +---------------+                |    |
       |    |              +---------------+                |    |
       |    |[8]           | ACK / ST:OK   |                |    |
       |    |---VS:1-----> |     / SV:HTTP | ------------>  |    |
       |    |              |     / SV:RTSP |                |    |
       |    |              +---------------+                |    |
       |    |                                               |    |
       +----+                                               +----+

                Diagram 1: Initial Connection Data Flow

10.2  Appendix B. Virtual Socket Dataflow

    Diagram 2 shows the typical virtual socket dataflow.  As indicated
    in diagram 1, the CTP client broadcast HTTP service capability which
    is requested by the CTP server endpoint. The server initiates the
    virtual socket by sending the open virtual socket (OPVS) [1] command
    to TCP client indicating that the service endpoint (HTTP) and
    virtual socket ID (VS:3) has been allocated for that request.  Note
    that control virtual socket 1 is used by TCP server. The TCP client
    responds with the acknowledgement [2]. At that point the HTTP
    request [3] and HTTP response [4] are sent from communicating
    endpoints on virtual socket 3 (VS:3).

       +----+                                               +----+
       |    |                                               |    |
       |    |                                               |    |
       |    |              +---------------+                |    |
       |    |[1]           | OPVS/ SV:HTTP |                |    |
       |    |<------------ |     / VS:0003 | <--VS:1------  |    |
       | T  |              |               |                | T  |
       | C  |              +---------------+                | C  |
       | P  |[2]           +---------------+                | P  |
       |    |---VS:1-----> |   ACK / ST    | ------------>  |    |
       |    |              +---------------+                |    |
       | C  |                                               | S  |
       | L  |              HTTP Data Session                | E  |
       | I  |              +---------------+                | R  |
       | E  |[3]           |    VS:0003    |                | V  |
       | N  |<------------ |GET / HTTP/1.1 | <---VS:3-----  | E  |
       | T  |              |...            |                | R  |
       |    |              +---------------+                |    |
       |    |              +---------------+                |    |
       |    |[4]           |    VS:0003    |                |    |
       |    |---VS:3-----> |HTTP/1.1 200 OK| ------------>  |    |
       |    |              |...            |                |    |
       |    |              +---------------+                |    |
       |    |                                               |    |
       |    |                                               |    |
       +----+                                               +----+

        Diagram 2: Virtual Socket Data Flow - HTTP Data Example

Authors' Addresses

    Piotr Romanczyk
    Honeywell

    EMail: piotr.romanczyk@honeywell.com

    Christopher Colicino
    Honeywell

    EMail: christopher.colicino@honeywell.com

    Michael Landi
    Honeywell

    EMail: michael.landi@honeywell.com

    Tomas Brodsky
    Honeywell

    EMail: tomas.brodsky@honeywell.com

IPR Disclosure

    "By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79."

Disclaimer

   "This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Expires May 13, 2018