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