Internet DRAFT - draft-cordell-midcom-span-a
draft-cordell-midcom-span-a
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: <Listener Response>.
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 <Keep Alive> (MType = 0) message
to the Relay. (Note that the inactivity period used should allow for
the initial <Keep Alive> message to be lost and TCP to attempt
retransmissions before the NAT binding lifetime expires.)
The <Keep Alive> 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 <Initialise> message (PType = 50).
An instance of the <Initialise> message is sent for each step in the
CHAP handshake sequence.
The header for the <Initialise> message is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MType = 50 (decimal) | MLength = ? (decimal) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Initialisation Message +
The Relay SHOULD NOT send instigate the <Initialisation> 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 <Initialise> message.
The parameter contains the ASCII representation of the characters
'SPAN'. If the first message the Client or the Relay receive is NOT
an <Initialise> 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 <Initialise>
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 <Initialise> 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 <Initialise> 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 <Initialise> 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 <Initialise> 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 <Initialise> Message
A complete example of an <Initialise> 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 <IPv4 Listener Request> message (MType = 100) or a <IPv6
Listener Request> message (MType = 101).
The format of the <IPv4 Listener Request> 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 <IPv6 Listener Request> 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 <Listener Response> (MType = 120) or
<Listener Failed> (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 <Listener Response> 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 <Listener Response> 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 <Listener
Failed> 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 <Listener Failed> 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 <Listener
Incoming Connection> message (MType = 122).
The <Listener Incoming Connection> 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 <Listener Incoming Connection> 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 <Listener Incoming Connection> 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 <Listener Close>
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 <Listener Close> 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 <IPv4 UDP Request> message (MType = 150) or an <IPv6 UDP
Request> message (MType = 151) to the Relay.
The format of the <IPv4 UDP Request> 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 <IPv6 UDP Request> 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 <UDP Response> (MType = 170) or <UDP
Failed> (MType = 171) message.
The start of the <UDP Response> 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 <UDP Response> 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 <UDP Response> 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 <UDP
Failed> 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 <UDP Failed> 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 <UDP Response> 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]
