Issues with Network Address Translation for SCTP

David A. Hayes, Jason But, and Grenville Armitage
Appears in: 
CCR January 2009

A Stream Control Transmission Protocol (SCTP) capable Network Address Translation (NAT) device is necessary to support the wider deployment of the SCTP protocol. The key issues for an SCTP NAT are SCTP’s control chunk multiplexing and multi-homing features. Control chunk multiplexing can expose an SCTP NAT to possible Denial of Service attacks. These can be mitigated through the use of chunk and parameter processing limits.

Multiple and changing IP addresses during an SCTP association, mean that SCTP NATs cannot operate in the way conventional UDP/TCP NATs operate. Tracking these multiple global IP addresses can help in avoiding lookup table conflicts, however, it can also result in circumstances that can lead to NAT state inconsistencies. Our analysis shows that tracking global IP addresses is not necessary in most expected practical installations.

We use our FreeBSD SCTP NAT implementation, alias_sctp to examine the performance implications of tracking global IP addresses. We find that typical memory usage doubles and that the processing requirements are significant for installations that experience high association arrival rates.

In conclusion we provide practical recommendations for a secure stable SCTP NAT installation.

Public Review By: 
Chadi Barakat

The number of NAT boxes in the Internet is fast increasing especially with the deployment of home networks by ADSL subscribers. Unfortunately, these boxes are known to cause several problems to end-toend protocols given the fact that they alter the information in the IP address and port number fields of Internet packets. Among the problems caused by NAT boxes and recently identified are the ones relative to the SCTP protocol. Indeed, the SCTP protocol (Stream Control Transmission Protocol) is intended to transmit multiple streams inside the same association and to enable hosts to simultaneously use multiple IP addresses for network path tolerance. All the information on the association is transmitted in an SCTP initialization packet and is then transparent to the NAT box. Later on when packets of new streams are sent within the same association using new port numbers, the NAT box is unable to handle them which causes their drop. The solution proposed to this problem by a recent Internet draft by Stewart and Tuxen consists in parsing the SCTP header by NAT boxes to create all necessary rules upon the initialization and to keep parsing packets to translate the port numbers of the different streams. This solution is shown in the present paper to introduce security threats on NAT boxes and to induce high processing overhead. Indeed, the ease by which streams are created from outside the local network can push attackers to considerably increase the number of these streams to overwhelm the NAT boxes. This problem is carefully analyzed in the present paper both analytically and experimentally and a set of recommendations and guidelines are issued to improve the security of NAT boxes.
Even though the evaluation part in the paper can be made more solid and the presentation can be improved by putting the contribution in a more general context than SCTP and the proposed Internet draft, the paper has the merit of identification a new real problem and analyzing it. The publication of the idea while the standardization of SCTP-enabled NATs is going on can help improving any potential standard around this problem. This also has certainly an impact on the research on NAT boxes in general and on making them more robust against any other attack of the same type.