Internet Engineering Task Force MidCom WG Internet Draft P. Cordell draft-cordell-midcom-span-a-00 Ridgeway Systems & Software Ltd June 24, 2002 Expires: 24 December 2002 SPAN-A - Candidate A for the Pre-Midcom SPAN Protocol STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract SPAN-A (pronounced 'spanner') is a candidate for the pre-midcom SPAN protocol. The scope of SPAN (Simple Protocol for Augmenting NATs) is to enable protocols involving multiple associated sessions to operate across NATs. Such protocols typically use transport addresses to identify associated sessions. This works well for environments where end-to-end addressing is in force, but is broken by the introduction of NATs. SPAN is intended to operate with symmetric NATs by using a relay outside the NAT. It complements STUN [STUN] which operates with various kinds of cone NAT. Cordell [Page 1] Internet Draft SPAN-A June 2002 Note Well This document is an interim product of the pre-midcom design team. As such it is work in progress and publication at this stage does not imply design team consensus on the material herein. 0. Design Rationale This section is to be removed if this document migrates into an RFC. The requirements for SPAN-A were derived from the author's pre-midcom design team notes document. This document indicated that the main requirements of SPAN were persistent TCP listeners, UDP relaying and security. To address security it was decided to use TLS as, at the time of writing, this was going to be used in STUN. This provides both encryption and server authentication in a relatively available module that could be treated as a black box and wouldn't require implementers to roll their own security code. As the security side of things represents the main element of complexity of the protocol and SPAN-A is seen as being short term, this seems a good direction to take. Having adopted TLS as a security element it was decided to try to make this the primary cryptographic element within the system. This has been mostly successful although CHAP was added to authenticate Clients because it was felt unreasonable to require them to use certificates. CHAP was selected because in some cases it is desirable to move the authentication credentials off of the Relay as this is vulnerable to attack as it is in public space. Being widely deployed and well understood, the obvious choice here is RADIUS. It was decided not to expose the plain text password to the Relay and so something like a challenge based password scheme was sought. CHAP is such a scheme and is directly supported by RADIUS and so this was adopted. It is for this reason that CHAP has been selected over other similar protocols such as digest. Naturally this does not rule out the use of other credential storage mechanisms, but it was felt important that the design was able to support one fully worked through end-to-end solution rather than leaving it to chance by randomly selecting some other scheme. In the spirit of making TLS the sole security component, it was decided to use the TLS channel to setup UDP relay instances in addition to TCP listeners. While this does mean that UDP connections do need to use TLS to get established, it also means that there does not need to be a second set of security procedures for UDP. To reduce the duration that the TLS connections are being used, the design allows for the TLS channel to be closed without terminating the UDP relay instances. Given the short-term nature of SPAN-A this was considered to be a good compromise. Cordell [Page 2] Internet Draft SPAN-A June 2002 A further localisation of the security mechanisms was achieved by not requiring digital signing of the UDP control packets. Instead large, unpredictable random numbers are provided to the Client, which it uses to signal the operations that it needs. In addition to avoiding additional security code, this simplifies the processing of the relaying entities and will make them much more deterministic. This will be important if large deployments of Relays start to appear. In terms of message design, it has been decided to follow STUN's lead. However, no attempt has been made to avoid message and parameter codes clashing as it is expected that the two protocols will operate using different ports. It is perhaps worth noting in passing that in an earlier internal version of this document the UDP headers were placed at the end of the UDP packets and called footers. It was pointed out that in most implementations where the packets are dealt with at the application level this added little benefit, and some confusion. However, it may be that the use of footers adds benefits to implementations that operate at the IP packet level. It therefore may be appropriate to review this decision. 1. Introduction SPAN-A (pronounced 'spanner') provides NAT traversal facilities for protocols that involve multiple associated sessions. It is a strategic short-term solution filling the gap between the urgent demand for a NAT traversal solution today and the Midcom solution (or ultimately IPv6) that will be deployed in the future. SPAN-A is a short-term strategic initiative and its design reflects that. Where possible SPAN-A uses off-the-shelf components rather than developing custom solutions specifically for SPAN-A. This is particularly the case in the area of security where SPAN-A uses TLS and CHAP even though a customised security architecture may be more efficient. This is an expedient intended to reduce the amount of design, security analysis, and implementation effort that needs to be done before SPAN-A can be deployed. That said, SPAN-A is intended to be a robust, reliable and secure protocol and these requirements are NOT knowingly compromised in the interest of rapid deployment. SPAN-A provides a client access to two basic services on an external relay. These are: 1. TCP Listeners & TCP relaying for handling incoming TCP connections. 2. UDP relaying. As a SPAN-A relay is likely to require significant resources it is Cordell [Page 3] Internet Draft SPAN-A June 2002 expected that in a number of deployments some charge will be levied for the use of the resources. SPAN-A consequently includes authentication and encryption of key commands to minimise the scope for illicit use of the SPAN-A resources. In order to expedite design, security analysis and implementation, SPAN-A uses TLS [TLS] and CHAP [CHAP] for its primary cryptographic needs. The TLS connection created as a consequence is used as a Control Channel. 2. Terminology In this document, the key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC 2119] and indicate requirement levels for compliant SPAN-A implementations. 3. Definitions Client - The client side of the SPAN-A protocol. This might be a SIP UA. See Figure 1. Client Address - Address and port on a Client corresponding to a particular connection that communicates with the Relay. See Figure 1. Control Channel - The main control channel between the Client and the Relay. This is authenticated and encrypted using TLS and encapsulates all the security mechanisms of the protocol. Inner Relay Address - Address and port on a Relay corresponding to a particular connection that communicates with the Client. See Figure 1. Feature ID - An ID that describes either a Relay or Client feature during initialisation. For example, Feature IDs can describe whether a Relay supports IPv4 and/or IPv6 Outer Relay Addresses. Listener Address - An Outer Relay Address used to listen for incoming TCP connections. Outer Relay Address - Address and port on a Client corresponding to a particular connection that communicates to a Remote Host. See Figure 1. Relay - The Relay is located outside the NAT and performs a forwarding function to allow a Client to be able to receive packets from outside the NAT. It implements multiple Relay Instances. See Figure 1. Relay Instance - A relay instance is a single forwarding instance that forwards packets received on a particular Outer Relay Address to the Client Address, and forwards packets received from the Client on a particular Inner Relay Address to the Remote Host. Cordell [Page 4] Internet Draft SPAN-A June 2002 Remote Host - The remote party involved in the communication. See Figure 1. Rendezvous Address - The address to which a Rendezvous TCP Connection should be made. Rendezvous TCP Connection - A TCP connection initiated by the Client to the Relay to accept an inbound TCP connection received on one of the Relay's listeners. Silently Discard - A message is silently discarded if its content is ignored and no error message is returned to the sending party. This conforms to the principles of [RFC1958]. Cordell [Page 5] Internet Draft SPAN-A June 2002 4. Reference Architecture _________ _________ | | | | | Remote | | Remote | | Host | | Host | |_________| |_________| | Remote Address | Remote Address | | | | | Outer Relay | Outer Relay | Address | Address ____|____ ____|____ | | | | ______| SPAN-A | ______| SPAN-A | ____|___ | Relay | ____|___ | Relay | | | |_________| | | |_________| | Policy | | Inner Relay | Policy | | Inner Relay | Server | | Address | Server | | Address |________| | |________| | | | | NATted Address | NATted Address ____|____ ____|____ Outside | | Outside | | ----------| NAT |----------- ---------| NAT |---------- Inside |_________| Inside |_________| | | | | | Client Address | Client Address ____|____ ____|____ | | | | | SPAN-A | | SPAN-A | | Client | | Client | | & | |_________| | Local | | | Host | | |_________| ____|____ | | | Local | | Host | |_________| (a) (b) Figure 1 - Reference Architectures and Corresponding Addresses Figure 1 shows the reference architecture for SPAN-A. This document specifies the functionality of the SPAN-A Client and the SPAN-A Relay. In some deployments the SPAN-A Client may be incorporated into the local host as shown in Figure 1(a), and in other deployments the SPAN-A Client may act as a proxy on behalf of a local host as Cordell [Page 6] Internet Draft SPAN-A June 2002 shown in Figure 1(b). The particular deployment does not affect the SPAN-A protocol, and the configuration shown in Figure 1(a) is used as the reference architecture for the rest of this document. To further simplify the text in the remainder of the document, the SPAN-A Client is simply referred to as the 'Client' and the SPAN-A Relay is simply referred to as the 'Relay'. The policy server in Figure 1 is assumed to be something like RADIUS [RADIUS]. While SPAN-A has been designed with the idea of using RADIUS as a policy server, the actual policy mechanisms used by the Relay are beyond the scope of this document. Figure 1 also identifies the various addresses that are referred to in the remainder of the document. 5. Conventions The names of messages sent over the Control Channel are contained in angled brackets. For example: . 6. The Control Channel SPAN-A uses TLS [TLS] for Client / Relay authentication. Rather than define additional authentication and encryption schemes for other aspects of the protocol, SPAN-A maintains the TLS connection for use as a secure Control Channel. By adopting this scheme, all cryptographic operations are localised into one place. An application using SPAN-A may establish any number of Control Channels to a Relay, but it is recommended that where possible only one such Control Channel be created. This reduces resources on the devices, and also removes the need for repeated authentication. The Client initiates the Control Channel to the SPAN-A well-known port (port xxxx) on the Relay. 6.1. Control Channel Message Format Messages on the Control Channel have the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType | MLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Contents + | | Where: Cordell [Page 7] Internet Draft SPAN-A June 2002 MType - Message Type. MLength - The length of the message in bytes, including the MType and MLength fields. Message Contents - The content of the message. This is variable length. All fields are in network byte order (i.e. big-endian - See Data Notations in [RFC1700]). All parameters have the following header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | PLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Parameter Contents + | | Where: PType - Parameter Type. PLength - The length of the parameter in bytes, including the PType and PLength fields. In particular IP addresses have the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | PLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Family - Indicates the address family as follows: 1 -> IPv4 2 -> IPv6 6.2. Control Channel Message Processing Most of the parameters described below appear as multiples of 4 bytes. However, as the Control Channel uses TLS for transport there is no guarantee that this 32-bit word alignment will be maintained end-to-end, and the reader must not infer 32-bit word alignment from the text. Messages and parameters have alignment at byte boundaries only. Cordell [Page 8] Internet Draft SPAN-A June 2002 To enable message sanity checking the parameters in the messages MUST appear in the order shown in this document. If a message is received that contains parameters in a different order the recipient should consider the Control Channel to be corrupted and MUST immediately close it. SPAN-A Clients and Relays MUST be able to accept messages containing additional parameters not shown in this document and they MUST be able to ignore parameters that they do not understand while correctly processing the remainder of the parameters. All additional parameters MUST appear after the sets of parameters shown in this document. If messages are received that contain fewer parameters than shown in this document the Control Channel MUST be terminated. SPAN-A Clients and Relays MUST silently discard messages not defined in this document that they do not understand them. Examples of the messages are illustrated further below. 6.3. Control Channel TCP Keep-Alives A number of NATs allow relatively short periods for inactive NAT bindings even for TCP. For example Linux Masquerade will terminate a TCP NAT binding after 15 minutes of inactivity. [RFC1122] recommends against the use of TCP keep-alives and suggests that if they are used the minimum period should be 2 hours. These recommendations obviously don't take into account the situation when a TCP connection goes through a NAT. In short, there are no fixed rules on the use of TCP keep-alive and characteristics it should have. Indeed it appears that some kernels need to be re-built in order to set a keep-alive period other than 2 hours. This is obviously not an acceptable option for many potential SPAN-A deployments and hence an application level keep-alive mechanism is defined for the Control Channel. If no data has been exchanged over the Control Channel for a period that may result in the NAT bindings being removed (for example 10 minutes), the Client SHOULD send a (MType = 0) message to the Relay. (Note that the inactivity period used should allow for the initial message to be lost and TCP to attempt retransmissions before the NAT binding lifetime expires.) The message is: Cordell [Page 9] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 0 (decimal) | MLength = 4 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The scheme relies on TCP to perform the acknowledgement and retry procedures. Hence there is no Keep Alive Response message. 6.4. Closing the Control Channel The Client may close the Control Channel at any time. Once authorised, a Relay should only close the Control Channel on the reception of badly formed messages, or after a period of inactivity during which the keep-alive procedure has failed. 7. Authentication It is expected that a SPAN-A Relay deployment will require significant processing and that in a number of cases the SPAN-A Relay will not be owned as the same organisation as the SPAN-A Client that is using it. It is therefore anticipated that in a number of SPAN-A deployments some form of settlement procedure will have to be employed between the two parties. This implies authorisation. The details of authorisation are application specific, but SPAN-A includes authentication procedures, the results of which can be used as part of the authorisation scheme. SPAN-A allows mutual authentication between the Client and the Relay. In simplistic terms, the Relay will probably want to know that the Client will pay for the service, and the Client wants to know that the Relay will faithfully endeavour to carry out its requests. 7.1. Authentication Procedure Authentication is done during the initial phases of setting up the TLS based Control Channel. If the Client and Relay are able to restore a previous (or currently active) TLS session then no further authentication is required. This allows for fast setup of the Control Channel. If the Client and Relay are NOT able to restore a previous TLS session, then mutual authentication SHOULD be completed before Relay resources are created using the protocol. Either party may close the Control Channel if authentication is not successful. The Relay authenticates itself to the Client using public key techniques by acting as the server in the TLS initialisation procedure. The Client authenticates itself to the Relay using CHAP [CHAP] in the first set of messages exchanged over the Control Channel. This is described further below. Cordell [Page 10] Internet Draft SPAN-A June 2002 8. Initialisation When the Control Channel is first established and a previous or current TLS session has not been resumed, a number of operations must be completed. These include Protocol Identification, Client Authentication, and Feature Identification. All of these operations are completed using the message (PType = 50). An instance of the message is sent for each step in the CHAP handshake sequence. The header for the message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 50 (decimal) | MLength = ? (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Initialisation Message + The Relay SHOULD NOT send instigate the message sequence if a TLS session has been resumed. 8.1. Protocol Identification Protocol Identification is achieved by sending a Protocol Identification parameter (PType = 1) in each message. The parameter contains the ASCII representation of the characters 'SPAN'. If the first message the Client or the Relay receive is NOT an message, or it does NOT contain a valid Protocol Identification parameter, they MUST immediately terminate the Control Channel. This parameter has the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 1 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'S' = 83(dec) | 'P' = 80(dec) | 'A' = 65(dec) | 'N' = 78(dec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.2. Client Authentication The Client authenticates itself using CHAP. The CHAP messages are encapsulated in CHAP parameters (PType = 2) within the messages. A CHAP Parameter has the form: Cordell [Page 11] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 2 (decimal) | PLength = ? (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Encapsulated CHAP Message + . . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An message, including the Protocol Identification parameter and the Features parameter, is sent for each step of the CHAP authentication procedure. To allow a single Relay to be able to authenticate Clients from multiple domains (which may correspond to different enterprises and may be authenticated using different databases) the Name field in the CHAP response MUST be of the form 'client@domain'. For example, 'pcordell@ridgewaysystems.com'. Where no suitable domain name is present, the domain name is omitted, but the '@' character MUST still be present. The 'client' part of the name can be any valid CHAP Name. The hashing function used to calculate the CHAP response is MD5 [MD5]. The CHAP authentication software SHOULD rely on the TCP transport for reliability of message delivery and not send additional challenges if the response is delayed. However implementations MUST tolerate repetition of CHAP messages and respond according to the CHAP specification. An example CHAP parameter is: Cordell [Page 12] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 2 (decimal) | PLength = 38 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 (Res) | Identifier=22 | Length = 34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value size=16 | | +-+-+-+-+-+-+-+-+ + | | + + | MD5 Hash Result | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 'p' | 'e' | 't' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'e' | '@' | 'i' | 'e' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 't' | 'f' | '.' | 'o' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'r' | 'g' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Code, Identifier, and Length are defined in [CHAP]. 8.3. Feature Identification It is important for the Relay to be able to notify the Client of the features it supports. In particular, it must be able to indicate whether the Outer Relay Addresses it provides belong to the IPv4 and/or IPv6 address families. This is done by including a Feature Set parameter (PType = 3) within the message. Each feature is identified by a Feature ID. The set of Feature IDs that represent the Client or Relay's features are concatenated together and placed in a Feature Identification parameter within the message. Each Feature ID is encoded as one byte. The currently defined set of Feature IDs is: 1 -> Outer Relay supports IPv4 addresses 2 -> Outer Relay supports IPv6 addresses Note that for symmetry a Client MUST include a Feature Set Parameter in the messages that it sends to the Relay even though at present there are no features that a Client can advertise. As an example, a Feature Set parameter indicating that the Relay supports only IPv4 Outer Relay Addresses has the form: Cordell [Page 13] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 3 (decimal) | PLength = 5 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+ 8.4. Example Message A complete example of an message (in this case the Client responding to the Relay's CHAP challenge) is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 50 (decimal) | MLength = 54 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 1 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'S' = 83(dec) | 'P' = 80(dec) | 'A' = 65(dec) | 'N' = 78(dec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 2 (decimal) | PLength = 38 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 (Res) | Identifier=22 | Length = 34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value size=16 | | +-+-+-+-+-+-+-+-+ + | | + + | MD5 Hash Result | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 'p' | 'e' | 't' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'e' | '@' | 'i' | 'e' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 't' | 'f' | '.' | 'o' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'r' | 'g' | PType = 3 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLength = 4 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. Persistent TCP Listeners 9.1. Creating a Listener A Client requests a persistent TCP listener on the Relay by sending either a message (MType = 100) or a message (MType = 101). The format of the message is: Cordell [Page 14] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 100 (decimal) | MLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 101 (decimal) | MLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Listener ID (PType = 4) is used by the Client and the Relay to identify the listener throughout the lifetime of the listener. Note that the Listener ID is only unique to the Control Channel over which it is signalled and not unique to all listeners on the Relay. The Relay MUST respond with a (MType = 120) or (MType = 121) message depending on whether the Relay has been able to create the listener, and whether it is an IPv4 or IPv6 listener. If the Relay has created an IPv4 listener, it returns the following variant of the message: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 120 (decimal) | MLength = 24 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 5 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Listener Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener IP v4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Relay has created an IPv6 listener, it returns the following variant of the message: Cordell [Page 15] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 120 (decimal) | MLength = 36 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 5 (decimal) | PLength = 24 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 2 | Listener Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Listener IP v6 Addr | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In these messages, the Listener Address (PType = 5) is the address of the listener created on the Relay. If the Relay is unable to create a listener, it returns the message: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 121 (decimal) | MLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 6 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Class | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message contains an Error parameter (PType = 6). The Error Class and Error Codes used in the Error parameter are defined at the end of the document. 9.2. Handling an Incoming TCP connection When the Relay wishes to notify the Client of an incoming TCP connection on a listener, it MUST send the Client a message (MType = 122). The message for an IPv4 Rendezvous Address has the form: Cordell [Page 16] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 122 (decimal) | MLength = 64 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 7 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 8 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 9 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Rendezvous Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rendezvous IP v4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message for an IPv6 Rendezvous Address has the form: Cordell [Page 17] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 122 (decimal) | MLength = 76 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 7 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 8 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 9 (decimal) | PLength = 24 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 2 | Rendezvous Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Rendezvous IP v6 Addr | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Listener ID tells the Client which listener has received the incoming connection. The Association ID (PType = 7) is a cryptographically random unpredictable 16-byte value that is sufficiently unique to allow the Relay to tell apart different listening events and prevent service stealing. The Association Response ID (PType = 8) is used to allow the Client to confirm that the genuine Relay has accepted the Rendezvous TCP connection and it has not been accepted by another entity. Cordell [Page 18] Internet Draft SPAN-A June 2002 The Rendezvous Address (PType = 9) tells the Client to where it should create an outbound connection on the Relay. Depending on the implementation of the Relay this may vary according to the listener that receives the incoming connection, or it may be the same address and port irrespective of the listener that receives the incoming connection. The address family (i.e. IPv4 or IPv6) of the Rendezvous Address must be the same address family as the address on the Relay of the Control Channel. On reception of the message the Client SHOULD create a TCP connection to the specified Rendezvous Address. This is called a Rendezvous TCP connection. The first sixteen bytes that the Client sends to the Relay over this connection MUST be the Association ID. Thus the first few bytes from the Client to the Relay are as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + The first few of bytes that the Relay sends to the Client of the Rendezvous TCP Connection MUST contain the Association Response ID and the address of the Remote Host from which the Relay received the incoming connection. The former allows the Client to confirm that the Rendezvous TCP Connection has been accepted by the genuine Relay and has not been maliciously intercepted. The latter allows the Client to implement policy about which Remote Hosts it wishes to service. Consequently, for an IPv4 listener the first set of bytes that the Relay sends to the Client is as follows: Cordell [Page 19] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote IP v4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + And for an IPv6 listener, the first set of bytes is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 2 | Remote Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Remote IP v6 Addr | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + If the Relay can not associate a listener with the Association ID then it MUST immediately close the Rendezvous TCP Connection. 9.3. Rendezvous TCP Connection Framing and Keep-Alive Strategy For the reasons stated above for the Control Channel, the Rendezvous TCP Connection requires application level keep-alives. This unfortunately necessitates additional in-band signalling over the Rendezvous TCP Connection. To accommodate this, each block of data that is exchanged over the Rendezvous TCP Connection MUST be preceded by a 16-bit value (in network byte order) that indicates the length of the data being sent plus the length of the length field. For Cordell [Page 20] Internet Draft SPAN-A June 2002 example, to send 14 bytes of application level data, the following data must be sent: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 16 (decimal) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | 14 bytes of application data | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length fields are removed by the Relay before it forwards the application data to the Remote Host, or if applicable, the Client forwards the application data to the Local Host. It is the responsibility of the Client to maintain the NAT bindings. If it is necessary to send data over the Rendezvous TCP Connection in order to refresh the NAT binding, but there is no application data available to send, the Client MUST send only the length field and no data. Thus it sends: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 2 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note the scheme does not require the Relay to acknowledge the refresh event, as the TCP layer will automatically perform the acknowledgement and carry out any re-transmission if the packet containing the refresh indication is lost. 9.4. Closing a TCP listener A Client can close a Relay listener by sending a message (MType = 123). This has the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 123 (decimal) | MLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 4 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Listener ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On reception of the message the Relay MUST terminate the listener, AND clear any remote incoming TCP connections that have been received but are waiting to be accepted. For this reason it is important that the Client completes any TCP rendezvous operations that it is interested in before closing a listener to avoid a race condition. Cordell [Page 21] Internet Draft SPAN-A June 2002 All listeners associated with a particular Control Channel MUST be closed if the Control Channel is closed. 9.5. Closing a Relayed inbound TCP Connection Closing a TCP connection that has been initiated via a listener on the Relay is simple. When the Client wishes to gracefully close the connection, it performs a shutdown on the TCP connection to the Relay. On being signalled that the TCP connection from the Client is to be closed, the Relay MUST wait until all queued data to be sent to the Remote Host has been sent, and then perform a shutdown on the TCP connection to the Remote Host. The Relay MUST continue to forward data received from the Remote Host to the Client. When the Relay receives the close from the Remote Host, and all queued data has been sent to the Client, the Relay MUST close the TCP connection to the Client. Similarly, if the Relay receives indication that the connection to the Remote Host is to be gracefully closed, it MUST forward any queued data to the Client and then perform a shutdown on the connection to the Client. The Relay MUST continue to forward data received from the Client to the Remote Host. When the Relay receives the close from the Client, and all queued data has been sent to the Remote Host, the Relay MUST close the TCP connection to the Remote Host. If the Relay receives a hard shutdown on either TCP connection of the Relay Instance, it MUST perform a hard shutdown on the partner TCP connection. All queued data is immediately discarded. 10. UDP Forwarding 10.1. UDP Packet Format between Client and Relay The SPAN-A UDP relay operation requires additional information to be exchanged between the Client and the Relay. This additional information is placed in-band in the UDP packets in the form of a header. The header is designed to be compact in order to minimise the potential for inducing IP fragmentation. The resultant format of the UDP packets exchanged between the Client and the Relay is as follows: Cordell [Page 22] Internet Draft SPAN-A June 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT | HL | Port (if present) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Header Info... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + UDP Packet data + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: HT - (Header Type) Indicates the type of header. The different types are defined below. HL - (Header Length) The number of bytes in the header including the Header Type and Header Length. Port - If the header contains an address, then this field contains the associated port. If the header does not contain an address, then this field is set to 0. Header Info - Variable length header information. All fields are in network byte order (i.e. big-endian - See Data Notations in [RFC1700]). The header is removed before the Relay forwards packets to the Remote Host, or, if the deployment is relevant, the Client forwards packets to the local host. 10.2. Initiating UDP Forwarding To create a UDP forwarding instance on the Relay a Client sends either an message (MType = 150) or an message (MType = 151) to the Relay. The format of the message is: Cordell [Page 23] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 150 (decimal) | MLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 10 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 11 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused = | Consecutive Ports = | | 0 | 1 or 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the message is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 151 (decimal) | MLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 10 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 11 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused = | Consecutive Ports = | | 0 | 1 or 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Transaction ID (PType = 10) is used by the Client to associate the response with the appropriate request. The Consecutive Ports parameter (PType = 11) indicates the number of consecutive ports that the Relay should allocate. The lowest numbered allocated port of the Outer Relay Addresses MUST satisfy the equation: (lowest port % Consecutive-Ports ) == 0 The Relay MUST respond with a (MType = 170) or (MType = 171) message. The start of the message has the form: Cordell [Page 24] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 170 (decimal) | MLength = ? (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 10 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + The Transaction ID in the response MUST be the same as the Transaction ID used in the request. The message contains the following information for each of the ports allocated: Association ID (PType = 12) Association Response ID (PType = 13) Close ID (PType = 14) Close Response ID (PType = 15) Outer Relay Address (PType = 16) Inner Relay Address (PType = 17) The format of this information for an IPv4 UDP port is: Cordell [Page 25] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 12 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 13 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 14 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 15 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close Response ID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 16 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Outer Relay Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Relay IP v4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 17 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Inner Relay Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Relay IP v4 Addr | Cordell [Page 26] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the IDs are 16-byte random values that must be unpredictable and sufficiently unique to allow the Relay to tell apart different IDs over a period that is relevant to it. How these IDs are used is described below. The Outer Relay Address and the Inner Relay Address are defined in Figure 1 and the definitions section. The address family of the Inner Relay Address MUST be the same address family as the Control Channel address on the Relay. There is an instance of this parameter set per UDP port that is allocated. The format for an IPv6 port is similar except that the IPv4 addresses are replaced by IPv6 addresses. For example, a message corresponding to a request for a pair of IPv4 UDP ports has the form: Cordell [Page 27] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 170 (decimal) | MLength = 220 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 10 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 12 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID (Port 1) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 13 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID (Port 1) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 14 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close ID (Port 1) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 15 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close Response ID (Port 1) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 16 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Outer Relay Port (Port 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Relay IP v4 Addr (Port 1) | Cordell [Page 28] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 17 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Inner Relay Port (Port 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Relay IP v4 Addr (Port 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 12 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association ID (Port 2) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 13 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Association Response ID (Port 2) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 14 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close ID (Port 2) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 15 (decimal) | PLength = 20 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Close Response ID (Port 2) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 16 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Outer Relay Port (Port 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Relay IP v4 Addr (Port 2) | Cordell [Page 29] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 17 (decimal) | PLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Family = 1 | Inner Relay Port (Port 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Relay IP v4 Addr (Port 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Once the message has been received Clients MAY close the Control Channel without affecting the state of the UDP Forwarding Instances that have been setup. However, the Client may wish to leave the Control Channel established so that it may be used for future control operations. If the Relay is unable to allocate the port resources it sends a message (MType = 171). That is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MType = 171 (decimal) | MLength = 12 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 10 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType = 6 (decimal) | PLength = 8 (decimal) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Class | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message contains an Error parameter (PType = 6). The Error Class and Error Codes used in the Error parameter are defined at the end of the document. 10.3. Making an Association When the Client receives the message, for each port that is being configured, it MUST send an Association Packet to the specified Inner Relay Address from the port that it wishes to subsequently receive relayed data. An Association Packet is a UDP packet that contains only an Association Header. An Association Header is identified by the HT field being set to the decimal value 255 and has the form: Cordell [Page 30] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | | | 255 (decimal) | 20 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Association ID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ On first reception of an Association Packet with a valid Association ID, the Relay will record the address from which the packet came as the address to which packets for this Relay Instance MUST be sent to the Client. The Relay MUST respond to the reception of a valid Association Packet by sending an Association Packet containing the Association Response ID. The format of this is the same as the Association Packet sent by the Client, i.e.: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | | | 255 (decimal) | 20 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Association Response ID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Using a different Association ID in the response sent back to the Client reduces the chance that an attacker may be able to spoof the response. Using large random values rather than methods such as digital signing removes the need for cryptographic operations in this area of the implementation. The Client is responsible for ensuring that the Association Packet is received by the Relay. If the Client does not receive a response after 200ms it SHOULD re-send its Association Packet. It MUST then double its wait period. If after this period it has not received a response it SHOULD re-send a further Association Packet. This procedure is repeated until a wait period of 3.2 seconds is reached. If after that period no response has been received, the Client should give up. If the Relay can not associate the Association ID with a valid Relay Cordell [Page 31] Internet Draft SPAN-A June 2002 Instance the Relay MUST ignore the packet. 10.4. UDP Forwarding Procedures 10.4.1. Relay Action during UDP Forwarding On reception of a packet from a Remote Host, the Relay MUST insert either an IPv4 Header or an IPv6 Header indicating the original source address of the packet and forward it to the Client. When the Client receives a packet from the Relay it MUST sanity check the contents of the header. It MUST discard packets that contain an unknown Header Type. It MUST also discard packets that indicate a Header Length that is not compatible with the Header Type. When a Client wishes to send a packet via the Relay to a Remote Host, it includes either an IPv4 Header or an IPv6 Header indicating the address to which the packet should be forwarded. The Client then sends the packet to the Inner Relay Address specified when the UDP forwarding operation was initiated. Likewise, the Relay MUST discard similarly malformed packets that it receives from the Client. Note that a Client may legitimately send a packet directly to the Remote Host without using the Relay. 10.4.2. The IPv4 Header An IPv4 header is identified by the HT field being set to the decimal value 0. The IPv4 address and port are in network byte order. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | Port | | 0 (decimal) | 8 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP v4 Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + UDP Packet data + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10.4.3. The IPv6 Header Cordell [Page 32] Internet Draft SPAN-A June 2002 An IPv6 header is identified by the HT field being set to the decimal value 1. The IPv6 address and port are in network byte order. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | Port | | 1 (decimal) | 20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IP v6 Addr | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + UDP Packet data + | | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 10.5. NAT Binding Keep-Alive In periods of inactivity a Client SHOULD refresh the NAT bindings at suitable periods (for example after 30 seconds) by repeating the procedure for making the initial association. That is, it sends an Association Packet with the correct Association ID to the Relay and confirms that a suitable response is received from the Relay. 10.6. Terminating UDP Forwarding SPAN-A allows a Client to explicitly close a UDP Relay Instance on the Relay. This is done by sending a Close Packet. This is a UDP packet that contains only a Close Header. The Close Header contains the unique Close ID specified by the Relay when the relay instance was instantiated. A Close Header is identified by the HT field being set to the decimal value 254. Its format is: Cordell [Page 33] Internet Draft SPAN-A June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | 0 | | 254 (decimal) | 20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Close ID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the Relay receives a Close Packet that contains a valid Close ID, the Relay MUST terminate the Relay Instance. It MUST then send a Close Packet that contains the Close Response ID. The format of this is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HT = | HL = | 0 | | 254 (decimal) | 20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Close Response ID | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Client does not receive a Close Packet from the Relay after a suitable period it must re-send its Close Packet using the same retry strategy as for the Association Packet. The Relay MUST be able to send a Close Packet containing the correct Close Response ID even if a Close Packet previously received from the Client has already terminated the Relay Instance. For this reason the Relay MUST maintain the correlation between Close ID and Close Response ID for at least the duration of the defined retry strategy. A Relay SHOULD terminate a Relay Instance if no activity is detected on that instance for a period greater than 10 minutes. All UDP Relay Instances are closed independently irrespectively of whether they were opened individually or as part of a pair. 11. Error Parameters The Error parameters (PType = 6) that are returned by SPAN-A consist of two parts: Error Class and Error Code. An Error Code value in one Error Class has a different meaning to the same valued Error Code in Cordell [Page 34] Internet Draft SPAN-A June 2002 a different Error Class. The following Error Classes are defined: 0 - Transient - A Client may be able to successfully retry the operation at a later time. Errors due to lack of resources may fall into this class. 1 - Persistent - A Client is unlikely to be successful if it tries the same operation after a short delay. Errors of this nature may be due to policy decisions. 2 - Fatal - No operations can be expected to succeed after an error of this class is received. 11.1. Defined Transient (Class 0) Error Codes 0 - Unspecified 1 - No Resources 11.2. Defined Persistent (Class 1) Error Codes 0 - Unspecified 1 - Feature not supported 2 - Requested address family not supported 3 - Not allowed due to policy 11.3. Defined Fatal (Class 2) Error Codes 0 - Unspecified 1 - Shutting Down 12. Summary of Message and Parameter Types This section presents a summary of the control message and parameter types. All values are decimal. To aid debugging and extension control Message Types are allocated in blocks as follows: 0-49 Control Channel management 50-99 Initialisation and authentication 100-149TCP Persistent listeners 150-199UDP Relaying Cordell [Page 35] Internet Draft SPAN-A June 2002 200+ Reserved for future use Within these ranges request and responses are separated into sub-ranges. The Message Types are as follows: MType - Message Name 0 - Keep Alive 50 - Initialise 100 - IPv4 Listener Request 101 - IPv6 Listener Request 120 - Listener Response 121 - Listener Failed 122 - Listener Incoming Connection 123 - Listener Close 150 - IPv4 UDP Request 151 - IPv6 UDP Request 170 - UDP Response 171 - UDP Failed The parameter types are as follows: PType - Parameter Name 1 - Protocol Identification 2 - CHAP Message 3 - Features 4 - Listener ID 5 - Listener Address 6 - Error Code 7 - Association ID 8 - Association Response ID Cordell [Page 36] Internet Draft SPAN-A June 2002 9 - Rendezvous Address 10 - Transaction ID 11 - Consecutive Ports 12 - Association ID 13 - Association Response ID 14 - Close ID 15 - Close Response ID 16 - Outer Relay Address 17 - Inner Relay Address The following is a summary of the UDP Header Types: HT - Header Name 0 - IPv4 Address 1 - IPv6 Address 254 - Close ID 255 - Association ID The following is a summary of the Address Family codes: 1 - IPv4 2 - IPv6 The following is a summary of the Feature ID codes: 1 - Relay supports IPv4 Outer Relay Address 2 - Relay supports IPv6 Outer Relay Address 13. UNSAF Considerations The IAB has recognised that there is an urgent need to address the problems that NATs cause protocols that involve multiple associated data streams. It also recognises that it will take a long time to fully address the problem technically and an even longer period for the solutions to be widely deployed. Therefore the IAB has sanctioned the introduction of short-term solutions that can fill the immediate need today, but will be deprecated when more considered solutions are available and deployed. As part of allowing these Cordell [Page 37] Internet Draft SPAN-A June 2002 short-term solutions, the IAB insists that a number of considerations presented in [UNSAF] be addressed. This section addresses the UNSAF Considerations with respect to SPAN-A. 13.1. UNSAF Consideration 1 - Problem Definition o Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems; this is why "short term fixes usually aren't". The purpose of SPAN-A is to allow real-time peer-to-peer multimedia protocols such as SIP, H.323, Megaco and MGCP to operate across NATs. 13.2. UNSAF Consideration 2 - Exit Strategy o Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed. There are a number of exit strategies for a SPAN-A installation. The most immediate of these is likely to be migrating the installation to Midcom. Ultimately, both of these will be replaced when IPv6 is universally deployed. (However, note that in migrating to IPv6, it may be necessary to temporarily deploy IPv4/IPv6 NATs either in addition to, or as a substitute to pure IPv4 NATs.) The main reason why SPAN-A is not a long term solution is because it adds additional relay points (potentially adding noticeable delay to the media transport), introduces points of failure and in turn cost. Therefore, if deployers find benefit from having deployed multimedia using SPAN-A, at a later time they will more than likely want to upgrade to a solution that does not incur the problems introduced by relaying. SPAN-A is designed to be as transparent as possible. As such it does not require changes to be made to the protocols that it transports. This means that when the SPAN-A component is removed from the system, it can be done cleanly without vestiges of the solution remaining in other components where they may limit evolution of the various protocols or contribute to unforeseen compatibility problems. Further, SPAN-A can be implemented in such a way that it emulates a regular TCP/IP stack. As such, changes to the core client code is not required, and it is easy to remove SPAN-A behaviour when it is no longer required. 13.3. UNSAF Consideration 3 - Introduction of Brittleness o Discussion of specific issues that may render systems more Cordell [Page 38] Internet Draft SPAN-A June 2002 "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition. The main element of brittleness introduced by SPAN-A is stateful intermediaries. These may be involved in both the signalling and media paths. As such, SPAN-A introduces points of failure that are not present in a system that operates according to the end-to-end principle. There are two main aspects to providing a robust solution in this context; recovery of resources associated with peer failure, and reconstitution of state as part of failure recovery so that a communication can continue with a minimum of interruption. SPAN-A has been designed so that if components of the system fail, this is detected and resources can be recovered. Currently SPAN-A does not explicitly include mechanisms for reconstitution of state. Reconstitution of state may be achieved using a number of redundant server techniques, or it may be possible in future to enhance SPAN-A to support exchange of opaque signed data that allows state restoration on system failure. With regard to the impact of SPAN-A on related systems, SPAN-A's transparent design means that it does not require other systems (such as remote UAs) to support features to enable it to work. Therefore call completion will not be conditional on whether remote parties can tolerate special traversal specific behaviour (such as the RTP/RTCP port pair relationship being broken). Indeed, with suitable architecting, SPAN-A can be deployed as if it were an alternative transport stack, and as such, all interactions with the stack can proceed as if a regular TCP/IP stack were being used. This minimises the number of traversal specific tweaks that need to be added to client code, thus easing development and removing the potential for bugs. 13.4. UNSAF Consideration 4 - Contributing to the Longer Term Solution o Identify requirements for longer term, sound technical solutions - - contribute to the process of finding the right longer term solution. The author(s) of SPAN-A see it as an enabling technology. SPAN-A should be easier to deploy than Midcom (which requires a NAT upgrade). As such, administrators may be inclined to deploy a SPAN-A solution at a time that they are not prepared to deploy a Midcom solution. Having successfully deployed a SPAN-A solution, and found that it gives them benefits, they may then be prepared to make the commitment to Midcom and ultimately full IPv6. By acting as a stepping stone in this way, SPAN-A is an enabling Cordell [Page 39] Internet Draft SPAN-A June 2002 technology that should evolve the network in a favourable way. 14. Security Considerations There are three areas in which a SPAN-A deployment might help an attacker. These are eavesdropping, impersonation, and denial of service. Eavesdropping would involve intercepting the SPAN-A configuration messages and manipulating them in such a way that the data packets are routed to an attacker. In practice if the attacker were able to sniff the SPAN-A configuration messages, then they would also be able to sniff any of the other data packets. Hence SPAN-A does not introduce a threat that is not already there. If confidentiality is required, then the host should use encryption. In principle an attacker could launch an impersonation attack by sending packets to the Relay in such a way that the Remote Host thought the packets were coming from the Relay rather than the attacker. Since this would require the attacker to spoof the packet source addresses, the attacker already has the means to perform such an impersonation attack. Hence, SPAN-A does not introduce a new threat, and hosts can use existing (or soon to be existing) techniques to counter this attack. The main threat that SPAN-A introduces is a Denial of Service (DoS) attack. To perform this an attacker would sniff the SPAN-A Association Packets and inject its own versions. As long as the attacker appears to function in the same way as a NAT in this phase there is no way that either the Relay or the Client can tell an attacker apart from a genuine NAT. Having convinced the Relay that it is the appropriate NAT, the attacker would subsequently not forward any packets to the Client, thus denying service. By using different request and response IDs SPAN-A makes this more difficult for an attacker, and in the absence of packet loss the correct result would be pretty much guaranteed. However, this isn't a complete solution. One option is for the Relay to send statistics to the Client indicating how many packets it has forwarded. The Client could then compare this with how many packets it had actually received and take appropriate action if it was suspicious. This would complicate the protocol and add additionally messaging traffic, and, as SPAN-A is a short-term protocol, this option has not been taken. Another option is for the Relay to be programmed with the acceptable set of NAT addresses for a particular Client. This would work well for Clients that are always located behind a particular set of enterprise NATs. For mobile Clients, the Relay could ensure that the UDP addresses corresponded to the address of the Control Channel. However, these heuristics are imprecise and it is likely to be difficult to develop a set of heuristics that will work flawlessly Cordell [Page 40] Internet Draft SPAN-A June 2002 for all occasions. Hence such techniques should be considered methods of last resort. One consolation is that in the modern Internet the scope for such malicious sniffing is considerably reduced over what it has been in the past. In the public Internet, most of the links are point-to-point between reputable router providers. Even in the intranet environment, more and more links (such as switched Ethernet) do not involve shared media (although unencrypted 802.11 wireless differs from this trend). Another possible attack is to attack the TLS control path by injecting suitably formed TCP packets that would cause the state of the Client and/or Relay's TCP stacks to become confused. The author is not aware how feasible this attack is. 15. Intellectual Property Both Ridgeway Systems & Software Ltd and Nortel Networks have filed patents covering protocols that perform a similar function to SPAN-A and in a similar way. Patent claims being what they are, SPAN-A may infringe both of these patents. Further information on this matter may be found on the IETF's IPR web pages. 16. Acknowledgements Pete Cordell would like to thank his colleagues at Ridgeway Systems and Software for numerous conversations and reviews of text over the years that have led to the specification of SPAN-A. 17. References [CHAP]W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996. [MD5] R. Rivest, "The MD5 Message-Digest Algorithm," RFC 1321, April 1992. [MPLS]E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label Switching Architecture," RFC 3031, January 2001. [RADIUS]C. Rigney et al., "Remote Authentication Dial In User Service (RADIUS)," RFC 2865, June 2000. [STUN]J. Rosenberg et al., "STUN - Simple Traversal of UDP Through NATs," IETF Internet Draft, draft-rosenberg-midcom-stun-01.txt, March 1 2002. [TLS] T. Dierks & C. Allen, "The TLS Protocol Version 1.0," RFC 2246, January 1999. [RFC1122]R. Braden, Editor, "Requirements for Internet Hosts -- Cordell [Page 41] Internet Draft SPAN-A June 2002 Communication Layers," RFC 1122, October 1989. [RFC1958]B. Carpenter, Editor, "Architectural Principles of the Internet," RFC 1958, June 1996. [RFC1700]J. Reynolds & J. Postel, "Assigned Numbers," RFC 1700, October 1994. (Note: this document as a whole is now obsolete, but the Data Notations section is still applicable.) [RFC2119]S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Mar. 1997. [RFC2525]V. Paxson et al., "Known TCP Implementation Problems," RFC 2525, March 1999. 18. Authors' Addresses Pete Cordell Ridgeway Systems & Software Ltd 66 Suttons Business Park Reading RG6 1AZ England pcordell@ridgewaysystems.com Cordell [Page 42]