SONATA - SCTP Over NAT Adaptation
Architecture
Some initial considerations on supporting SCTP with NAT have been proposed
by Xie
(IETF Internet Draft), however this project will look to extend on this work
and provide a working implementation. A NAT implementation to support SCTP based
on the typical TCP and/or UDP NAT implementation has a number of problems:
- The SCTP Checksum is calculated over the entire SCTP packet, not just
just the transport layer header. Any modification of the port numbers
used would require the checksum to be recalculated for the entire packet.
Such an implementation would be inefficient where NAT is typically
deployed on low-powered home-user routers
- The SCTP Protocol is multi-homed, even if only one address is
available behind the NAT, the other end of the association may have
multiple end-points. In this situation port numbers must be preserved
for the whole association
- There can be multiple associations sharing the same address/port-number
end-points. For example, two PCs behind the NAT may choose the same
local port number to associate with a remote end-point. In this case
we must be able to differentiate between the two associations on the
outside of the NAT
Association Identification
We propose to build an implementation that uses the unique Verification
Tag (VTag) field of the SCTP header to identify unique associations. Under
this scenario it would not be necessary to change the port numbers of any
SCTP association as it traverses the NAT. The major benefit is that the SCTP
checksum would not need to be recalculated for every packet traversing the
NAT.
The SCTP VTag uniquely identifies an association and should be randomly
generated for each association. In a correct implementation, it is unlikely
that that a VTag will be duplicated for concurrent flows to different
endpoints of two distinct associations. The lookup table for NAT translations
should base its decisions on the VTags of SCTP packets traversing the NAT,
modifying the IP layer header while leaving the SCTP layer information intact.
Implementation Description
The NAT implementation must be able to handle an SCTP association being
initiated from either side of the NAT (ie. initiated from inside or outside
the NAT). An association initiated from outside the NAT will only succeed if
the specified port has been configured to be forwarded to a endpoint inside
the NAT.
Within the INIT chunk of the first SCTP packet of an association is the
Initiation Tag. The INIT responder must use this value to populate the VTag for
every SCTP packet sent as part of that association. The SCTP INIT packet must be
parsed to extract this value and store it in the NAT table.
The response to the INIT is an INIT-ACK, the specified VTag must match the
Initiation Tag stored from the prior INIT. Within the INIT-ACK is a second
Initiation Tag which is used by the sender of the initial INIT to populate the
VTag field for every SCTP packet sent as part of that association. The INIT-ACK
packet must be parsed to extract this value and store it in the NAT table.
At this point VTags, end-point IP addresses and port number pairs for the
association are known. This approach also works for SCTP associations initiated
from outside the NAT as long as an appropriate port forwarding rule is
configured. Note that port forwarding can only be to an internal IP address and
not to a different port number as this would require recalculating the checksum
for each SCTP packet. If an INIT is received where no port forwarding rule
exists, the NAT responds as if the port was not opened. INIT Packet
information:
- The initiator IP Address and Port Number
- The responder IP Address and Port Number
- The responder VTag (from the Initiation Tag)
When the reply INIT-ACK is received, the receiver Port Number and VTag are
checked. The Packet is forwarded only if there is a match in the NAT table.
Information gained from the INIT-ACK packet includes:
- The initiator VTag (from the Initiation Tag)
- Now the NAT table entry is populated
Any future inbound packets with the appropriate external VTag (from any IP
Address) are NATed through to the mapped internal IP Address. Any outbound
packets with the appropriate internal VTag (regardless of the destination IP
Address) are also NATed. This allows the multi-homing feature to work.
Address Management
An SCTP association may have multiple end-points, the NAT should parse INIT
and INIT-ACK packets to extract advertised IP addresses and - if necessary -
perform NAT, update the packets and recalculate the checksum. A proposed
extension whereby address end-points can be dynamically added or removed (see
here)
may need to be treated similarly.
Other Cases
The NAT table must be properly maintained, particularly in the case of an
association terminating. Similarly, SCTP packets where no association exists
within the NAT table should result in the association being terminated via the
use of an SCTP ABORT packet.
|
