Stream Control Transmission Protocol (SCTP) Network Address Translation
ResearcherChapinSC29036USArandall@lakerest.netMuenster Univ. of Applied SciencesStegerwaldstr. 3948565 SteinfurtGermanytuexen@fh-muenster.deMuenster Univ. of Applied SciencesStegerwaldstr. 3948565 SteinfurtGermanyi.ruengeler@fh-muenster.deInternet-DraftStream Control Transmission Protocol
provides a reliable communications channel between two end-hosts in many
ways similar to TCP . With the widespread
deployment of Network Address Translators (NAT), specialized code has been added
to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a
single globally unique IPv4 address, even when two hosts (behind a NAT) choose
the same port numbers for their connection. This additional code is sometimes
classified as Network Address and Port Translation or NAPT. To date, specialized
code for SCTP has NOT yet been added to most NATs so that only pure NAT is
available. The end result of this is that only one SCTP capable host can be
behind a NAT.This document describes an SCTP specific variant of NAT which provides
similar features of NAPT in the single point and multi-point traversal
scenario.Stream Control Transmission Protocol
provides a reliable communications channel between two end-hosts in many
ways similar to TCP . With the widespread
deployment of Network Address Translators (NAT), specialized code has been added
to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a
single globally unique IPv4 address, even when two hosts (behind a NAT) choose
the same port numbers for their connection. This additional code is sometimes
classified as Network Address and Port Translation or NAPT. To date, specialized
code for SCTP has NOT yet been added to most NATs so that only true NAT is
available. The end result of this is that only one SCTP capable host can be
behind a NAT.This document proposes an SCTP specific variant NAT that provides the NAPT
functionality without changing SCTP port numbers. The authors feel it is
possible and desirable to make these changes for a number of reasons.
It is desirable for SCTP internal end-hosts on multiple platforms to be able to share a
NAT's public IP address, much as TCP does today.If a NAT does not need to change any data within an SCTP packet it
will reduce the processing burden of NAT'ing SCTP by NOT
needing to execute the CRC32c checksum required by SCTP.Not having to touch the IP payload makes the processing of ICMP
messages in NATs easier.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
.For this discussion we will use several terms, which we
will define and point out in a figure. Private-Address (Priv-Addr) - The private address
that is known to
the internal host. Internal-Port (Int-Port) - The port number that is in use by the host holding
the Private-Address. Normally this is the port that will be translated
by the NAPT to a different port number. Internal-VTag (Int-VTag) - The Verification Tag that the internal host
has chosen for its communication. The
VTag is a unique 32 bit tag that must accompany any incoming SCTP
packet for this association to the Private-Address. External-Address (Ext-Addr) - The address that an internal host
is attempting to contact. External-Port (Ext-Port) - The port number of the peer process at
the External-Address. External-VTag (Ext-VTag) - The Verification Tag that the host holding
the External-Address has chosen for its communication. The
VTag is a unique 32 bit tag that must accompany any incoming
SCTP packet for this association to the External-Address. Public-Address (Pub-Addr) - The public address assigned to the NAT
box which it uses as a source address when sending packets towards
the External-Address.In this case, all packets in the SCTP association go through a
single NAT, as shown below:
A variation of this case is shown below, i.e., multiple NATs in a
single path:
The two SCTP endpoints in this case can be either single-homed or
multi-homed. However, the important thing is that the NAT (or NATs) in
this case sees ALL the packets of the SCTP association. In this single point traversal scenario, we must acknowledge that
while one of the main benefits of SCTP multi-homing is redundant
paths, the NAT function represents a single point of failure in the
path of the SCTP multi-home association. However, the rest of the path
may still benefit from path diversity provided by SCTP
multi-homing.This case involves multiple NATs and each NAT only sees some of the
packets in the SCTP association. An example is shown below:
This case does NOT apply to a single-homed SCTP association (i.e.,
BOTH endpoints in the association use only one IP address). The
advantage here is that the existence of multiple NAT traversal points
can preserve the path diversity of a multi-homed association for the
entire path. This in turn can improve the robustness of the
communication.To make this work, however, all the NATs involved must recognize
the packets they see as belonging to the same SCTP association and
perform address translation in a consistent way.
This may require that a pre-defined table of ports and addresses were
shared between the NATs. Other external management schemes that help
multiple NATs coordinate a multi-homed SCTP association could be
investigated.In this section we assume that we have multiple SCTP capable hosts
behind a NAT which has one Public-Address. Furthermore we are
focusing in this section on the single point traversal scenario.The modification of SCTP packets sent to the public Internet is
easy. The source address of the packet has to be replaced with the
Public-Address. It may also be necessary to establish some
state in the NAT box to handle incoming packets, which is discussed
later.For SCTP packets coming from the public Internet the destination
address of the packets has to be replaced with the Private-Address
of the host the packet has to be delivered to. The lookup of the
Private-Address is based on the External-VTag, External-Port, External-Address,
Internal-VTag and the Internal-Port.For the SCTP NAT processing the NAT box has to maintain a table
of Internal-VTag, Internal-Port, Private-Address, External-VTag, External-Port
and External-Address. An entry in that table is called a NAT state
control block.The processing of outgoing SCTP packets containing an INIT-chunk
is described in the following figure. The scenario shown is valid for all
message flows in this section.
It should be noted that normally a NAT control block will be created. However,
it is possible that there is already a NAT control block with the
same External-Address, External-Port, External-VTag, Internal-VTag but different
Private-Address. In this case the INIT SHOULD be dropped and an ABORT MAY
be sent back.The processing of outgoing SCTP packets containing no INIT-chunk
is described in the following figure.
The processing of incoming SCTP packets containing INIT-ACK chunks
is described in the following figure.
In the case Lookup fails, the SCTP packet is dropped. The Update routine
inserts the External-VTag (the Initiate-Tag of the INIT-ACK chunk)
in the NAT state control block.The processing of incoming SCTP packets containing an ABORT or
SHUTDOWN-COMPLETE chunk with the T-Bit set is described in the following figure.
The processing of other incoming SCTP packets is described in the
following figure.
For an incoming packet containing an INIT-chunk a table lookup is made
only based on the addresses and port numbers. If an entry with an Internal-VTag
of zero is found, it is considered a match and the Internal-VTag is updated.This allows the handling of INIT-collision through NAT.There is one drawback of the SCTP specific variant of NAT compared
to a NAPT solution like the ones available for TCP. Consider the case
where two hosts in the Private-Address space want to set up an SCTP association
with the same server running on the same host in the Internet. This means
that the External-Port and the External-Address are the same. If they both
choose the same Internal-Port the server cannot distinguish both associations
based on the address and port numbers. For the server it looks like
the association is being restarted. To overcome this limitation the
client sends a NAT_SUPPORTED parameter in the INIT-chunk which is defined
as follows:When the server receives this parameter it will also use the
verification tag to look up the association. However, this will
make it impossible to restart such associations.Consider the case where two hosts in the Private-Address space want to
set up an SCTP association with the same server running on the same host
in the Internet. This means that the External-Port and the External-Address
are the same. If they both choose the same Internal-Port and Internal-VTag, the
NAT box cannot distinguish incoming packets anymore. But this is very
unlikely. The Internal-VTags are chosen at random and if the Internal-Ports are
also chosen from the ephemeral port range at random this gives a 46 bit
random number which has to match.
In the TCP like NAPT case the NAT box can control the 16 bit Natted Port.However, in this unlikely event the NAT box MUST respond
to the INIT chunk by sending an ABORT chunk with the M-bit set.
The source address of the packet containing the ABORT chunk MUST
be the destination address of the SCTP packet containing the
INIT chunk.
The sender of the packet containing the INIT chunk MAY start
the association setup procedure after choosing a new initiate tag.The ABORT chunk defined in is therefore
extended by using the following format:The following error cause with cause code 0x00B0 (Colliding NAT table entry)
SHOULD be included in the ABORT chunk:If the NAT box receives a packet for which the lookup procedure
does not find an entry in the NAT table, a packet containing an ERROR
packet is sent back with the M-bit set.
The source address of the packet containing the ERROR chunk MUST
be the destination address of the incoming SCTP packet. The verification
tag is reflected.The ERROR chunk defined in is therefore
extended by using the following format:The following error cause with cause code 0x00B1 (Missing NAT table entry)
SHOULD be included in the ERROR chunk:If an end-point receives a packet with this ERROR chunk it MAY send
an SCTP packet with an ASCONF chunk containing an Add IP Address
parameter followed by a vtag parameter:If the NAT box receives a packet for which it has no NAT table entry
and the packet contains an ASCONF chunk with a vtag parameter, the NAT
box MUST update its NAT table according to the verification tags in
the vtag parameter.If a multi-homed SCTP end-point behind a NAT connects to a peer,
it first sets up the association single-homed.
Then it adds each IP address using ASCONF chunks. The address to add
is the wildcard address and the lookup address also.
The ASCONF chunks SHOULD also contain a vtag parameter.A NAT box MUST support IP reassembly of received fragmented
SCTP packets. The fragments may arrive in any order.When an SCTP packet has to be fragmented by the NAT box and
the IP header forbids fragmentation a corresponding ICMP packet SHOULD
be sent.Small NAT boxes, i.e. NAT boxes which only have to support a
small number of concurrent SCTP associations, MAY not take the
external address into account when processing packets. Therefore the
External-Address could also be removed from the NAT table.This simplification may make implementing a NAT box easier, however,
the collision probability is higher than using a mapping which takes
the external address into account.The internal client starts the association with the external
server via a four-way-handshake.The internal client is single-homed whereas the external server is
multi-homed. The server includes its addresses in the INIT-ACK chunk,
which results in two NAT entries.
Assocation is already established between Host A and Host B.
If two hosts are behind NATs, they have to get knowledge of the
peer's public address. This can be achieved with a so-called
rendezvous server. Afterwards the destination addresses are public,
and the association is set up with the help of the INIT collision.
The NAT boxes create their entries according to their internal peer's
point of view. Therefore, NAT A's Internal-VTag and Internal-Port are
NAT B's External-VTag and External-Port, respectively. The
naming of the verification tag in the packet flow is done from the
sending peer's point of view.TBDState maintenance within a NAT is always a subject of possible
Denial Of Service attacks. This document recommends that at
a minimum a NAT runs a timer on any SCTP state so that old
association state can be cleaned up.The authors wish to thank
Qiaobing Xie,
Henning Peters,
Bryan Ford,
David Hayes,
Alfred Hines,
Dan Wing,
and Jason But
for their invaluable comments.