TLS Mapping for Scalability Protocols

This mapping should be layered directly on the top of TLS secured connections. While it is possible to use TLS on top of other transports, this document specifically concerns itself with TLS running on top of TCP. Other combinations may be contemplated, and should follow the same details as discussed here. As when running SP over TCP directly, the TCP port number is determined by the application or user. This mapping follows the details of SP over TCP.

An initial connection is first established using TCP, then performing a TLS handshake. This handshake establishes the security parameters of the connection, including negotiation of cipher suites, exchanging keys, and possibly performing one or two-way authentication. The specific details of the TLS negotiation are determined by the application(s) involved, and are not specified here. This includes selection of the specific version of TLS or possibly falling back to SSL version 3 (but not SSL version 1 or 2). TLS presents an encrypted channel that may be treated as a full duplex byte stream between peers. This mapping sits within that channel. Note also that TLS peers may rekey periodically. This happens in the without involving the upper protocol, and the details need not concern us here. Once the TLS layer connection has been established, the communication commences as detailed in SPoverTCP. This includes the exchange of the initial protocol headers identifying the version of SP in use, and the specific protocol type, as well as requirements to disconnect upon receipt of an invalid protocol header or an unrecognized SP version.

This memo includes no request to IANA.

Security considerations are explored in depth as part of TLS. This document does not provide any further implications beyond that in TLS itself. The use of SSLv2 is explicitly forbidden, as SSLv2 contains known weaknesses.