< draft-porfiri-tsvwg-sctp-natsupp-02.txt   draft-porfiri-tsvwg-sctp-natsupp-03.txt >
Network Working Group C. Porfiri Network Working Group C. Porfiri
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Standards Track 25 March 2022 Intended status: Standards Track 29 April 2022
Expires: 26 September 2022 Expires: 31 October 2022
Stream Control Transmission Protocol (SCTP) Network Address Translation Stream Control Transmission Protocol (SCTP) Network Address Translation
Support Support
draft-porfiri-tsvwg-sctp-natsupp-02 draft-porfiri-tsvwg-sctp-natsupp-03
Abstract Abstract
The Stream Control Transmission Protocol (SCTP) provides a reliable The Stream Control Transmission Protocol (SCTP) provides a reliable
communications channel between two end-hosts in many ways similar to communications channel between two end-hosts in many ways similar to
the Transmission Control Protocol (TCP). With the widespread the Transmission Control Protocol (TCP). With the widespread
deployment of Network Address Translators (NAT), specialized code has deployment of Network Address Translators (NAT), specialized code has
been added to NAT functions for TCP that allows multiple hosts to been added to NAT functions for TCP that allows multiple hosts to
reside behind a NAT function and yet share a single IPv4 address, reside behind a NAT function and yet share a single IPv4 address,
even when two hosts (behind a NAT function) choose the same port even when two hosts (behind a NAT function) choose the same port
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 September 2022. This Internet-Draft will expire on 31 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6 4. Motivation and Overview . . . . . . . . . . . . . . . . . . . 6
4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6 4.1. SCTP NAT Traversal Scenarios . . . . . . . . . . . . . . 6
4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6 4.1.1. Single Point Traversal . . . . . . . . . . . . . . . 6
4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8 4.1.2. Multipoint Traversal . . . . . . . . . . . . . . . . 8
4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 8 4.2. Limitations of Classical NAPT for SCTP . . . . . . . . . 9
4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9 4.3. The SCTP-Specific Variant of NAT . . . . . . . . . . . . 9
4.4. Differences with Current NAT Support Draft . . . . . . . 13 4.4. Compatibility and increamental deployment . . . . . . . . 14
5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Differences with Current NAT Support Draft . . . . . . . 15
5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 14 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 14 5.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 14 5.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 16
5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 15 5.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 16
5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 15 5.1.3. Extended INIT-ACK Chunk . . . . . . . . . . . . . . . 16
5.2.1. Port Number Collision Error Cause . . . . . . . . . . 15 5.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 17
5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 16 5.2.1. Port Number Collision Error Cause . . . . . . . . . . 17
5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 16 5.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 18
6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 16 5.3.1. Repetita Juvant Parameter . . . . . . . . . . . . . . 18
6.1. Association Setup Considerations for Endpoints . . . . . 17 6. Procedures for SCTP Endpoints and NAT Functions . . . . . . . 18
6.2. Association Setup Considerations for NAT . . . . . . . . 17 6.1. Association Setup Considerations for Endpoints . . . . . 19
6.3. Handling of Internal Port Number Collisions . . . . . . . 18 6.2. Association Setup Considerations for NAT . . . . . . . . 19
6.3.1. NAT Function Considerations . . . . . . . . . . . . . 19 6.3. Handling of Internal Port Number Collisions . . . . . . . 19
6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 19 6.3.1. NAT Function Considerations . . . . . . . . . . . . . 20
6.4. Handling of Missing State . . . . . . . . . . . . . . . . 19 6.3.2. Endpoint Considerations . . . . . . . . . . . . . . . 21
6.4.1. NAT Function Considerations . . . . . . . . . . . . . 19 6.4. Handling of Missing State . . . . . . . . . . . . . . . . 21
6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 20 6.4.1. NAT Function Considerations . . . . . . . . . . . . . 21
6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 20 6.4.2. Endpoint Considerations . . . . . . . . . . . . . . . 22
6.6. Multipoint Traversal Considerations for Endpoints . . . . 21 6.5. Handling of Fragmented SCTP Packets by NAT Functions . . 22
6.6.1. NAT Function Considerations . . . . . . . . . . . . . 21 6.6. Multipoint Traversal Considerations for Endpoints . . . . 22
6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 21 6.6.1. NAT Function Considerations . . . . . . . . . . . . . 23
6.7. Path Probing considerations . . . . . . . . . . . . . . . 22 6.6.2. Endpoint Considerations . . . . . . . . . . . . . . . 23
7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 22 6.7. Path Probing considerations . . . . . . . . . . . . . . . 24
7.1. Single Homed Association Setup . . . . . . . . . . . . . 23 7. Examples of Operation . . . . . . . . . . . . . . . . . . . . 24
7.2. Single Homed Association Setup with Collision . . . . . . 23 7.1. Single Homed Association Setup . . . . . . . . . . . . . 25
7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 24 7.2. Single Homed Association Setup with Collision . . . . . . 25
7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 25 7.3. Multi Homed Association Setup . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.4. Multi Homed Association Setup . . . . . . . . . . . . . . 26
8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 27 8.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 28
8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 28 8.2. Four New Error Causes . . . . . . . . . . . . . . . . . . 29
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 30
10. Normative References . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . 29 10. Normative References . . . . . . . . . . . . . . . . . . . . 31
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Informative References . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Stream Control Transmission Protocol (SCTP) [RFC4960] provides a Stream Control Transmission Protocol (SCTP) [RFC4960] provides a
reliable communications channel between two end-hosts in many ways reliable communications channel between two end-hosts in many ways
similar to TCP [RFC0793] . With the widespread deployment of Network similar to TCP [RFC0793] . With the widespread deployment of Network
Address Translators (NAT), specialized code has been added to NAT Address Translators (NAT), specialized code has been added to NAT
functions for TCP that allows multiple hosts to reside behind a NAT functions for TCP that allows multiple hosts to reside behind a NAT
function using private-use addresses (see [RFC6890] ) and yet share a function using private-use addresses (see [RFC6890] ) and yet share a
single IPv4 address, even when two hosts (behind a NAT function) single IPv4 address, even when two hosts (behind a NAT function)
skipping to change at page 4, line 27 skipping to change at page 4, line 27
messages by NAT functions easier. messages by NAT functions easier.
An SCTP-aware NAT function will need to follow these procedures for An SCTP-aware NAT function will need to follow these procedures for
generating appropriate SCTP packet formats, this is needed under generating appropriate SCTP packet formats, this is needed under
circumstances detailed in this document and only triggered by the circumstances detailed in this document and only triggered by the
detection of an SCTP packet containing an INIT chunk. detection of an SCTP packet containing an INIT chunk.
When considering SCTP-aware NAT it is possible to have multiple When considering SCTP-aware NAT it is possible to have multiple
levels of support. At each level, the Internal Host, Remote Host, levels of support. At each level, the Internal Host, Remote Host,
and NAT function does or does not support the procedures described in and NAT function does or does not support the procedures described in
this document. The following table illustrates the results of the this document.
various combinations of support and if communications can occur
between two endpoints. The reference configuration for NAT support is depicted in the
following figure:
Internal Network | External Network
|
Internal | External Remote
Address | Address /--\/--\ Address
+--------+ +-----+ / \ +--------+
| Host A |=========| NAT |=======| Network |==========| Host B |
+--------+ +-----+ \ / +--------+
Internal | \--/\--/ Remote
Internal Port | Port Remote
VTag | VTag
Figure 1: Basic Network Setup
In the above Figure 1 the NAT hides Host A whereas Host B is directly
connected to the public internet. Host A has a private IP address,
NAT and Host B have public IP addresses.
The following table illustrates the results of the various
combinations of support and if communications can occur between two
endpoints with reference to Figure 1, the NAT adaptation is the one
described in the current document.
+===============+==============+=============+===============+ +===============+==============+=============+===============+
| Internal Host | NAT Function | Remote Host | Communication | | Internal Host | NAT Function | Remote Host | Communication |
+===============+==============+=============+===============+ +===============+==============+=============+===============+
| Support | Support | Support | Yes | | Support | Support | Support | Yes |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| Support | Support | No Support | Limited | | Support | Support | No Support | Yes |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| Support | No Support | Support | None | | Support | No Support | Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| Support | No Support | No Support | None | | Support | No Support | No Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | Support | Support | Limited | | No Support | Support | Support | Limited |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | Support | No Support | Limited | | No Support | Support | No Support | Limited |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | No Support | Support | None | | No Support | No Support | Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
| No Support | No Support | No Support | None | | No Support | No Support | No Support | None |
+---------------+--------------+-------------+---------------+ +---------------+--------------+-------------+---------------+
Table 1: Communication possibilities Table 1: Communication possibilities
From the table it can be seen that no communication can occur when a From the table it can be seen that no communication can occur when a
NAT function does not support SCTP-aware NAT. This assumes that the NAT function does not support SCTP-aware NAT. This assumes that the
NAT function does not handle SCTP packets at all and all SCTP packets NAT function does not handle SCTP packets at all and all SCTP packets
sent from behind a NAT function are discarded by the NAT function. sent from behind a NAT function are discarded by the NAT function.
In some cases, where the NAT function supports SCTP-aware NAT, but
one of the two hosts does not support the feature, communication can In some cases, where the NAT function supports SCTP-aware NAT but the
possibly occur in a limited way. For example, only one host can have local host does not support the feature, communication can possibly
a connection when a collision case occurs. occur in a limited way. For example, only one host can have a
connection when a collision case occurs.
When a SCTP host is deployed behind a NAT and both support SCTP-aware
NAT, the communication will suceed independently from the remote
peer.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
skipping to change at page 6, line 9 skipping to change at page 6, line 40
Remote-VTag (Rem-VTag) Remote-VTag (Rem-VTag)
The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that The Verification Tag (VTag) (see Section 3.1 of [RFC4960] ) that
the host holding the Remote-Address has chosen for an association. the host holding the Remote-Address has chosen for an association.
The VTag is a unique 32-bit tag that accompanies any outgoing SCTP The VTag is a unique 32-bit tag that accompanies any outgoing SCTP
packet for this association to the Remote-Address. packet for this association to the Remote-Address.
External-Address (Ext-Addr) External-Address (Ext-Addr)
An external address assigned to the NAT function, that it uses as An external address assigned to the NAT function, that it uses as
a source address when sending packets towards a Remote-Address. a source address when sending packets towards a Remote-Address.
Internal Network | External Network
|
Internal | External Remote
Address | Address /--\/--\ Address
+--------+ +-----+ / \ +--------+
| Host A |=========| NAT |=======| Network |==========| Host B |
+--------+ +-----+ \ / +--------+
Internal | \--/\--/ Remote
Internal Port | Port Remote
VTag | VTag
Figure 1: Basic Network Setup
4. Motivation and Overview 4. Motivation and Overview
4.1. SCTP NAT Traversal Scenarios 4.1. SCTP NAT Traversal Scenarios
This section defines the notion of single and multipoint NAT This section defines the notion of single and multipoint NAT
traversal. traversal.
4.1.1. Single Point Traversal 4.1.1. Single Point Traversal
In this case, all packets in the SCTP association go through a single In this case, all packets in the SCTP association go through a single
skipping to change at page 13, line 32 skipping to change at page 14, line 32
forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port) forwardPkt(Ext-Addr, Int-Port, Rem-Addr, Rem-Port)
Translates To: Translates To:
Int-Addr:Int-Port <------ Rem-Addr:Rem-Port Int-Addr:Int-Port <------ Rem-Addr:Rem-Port
Int-VTag Int-VTag
In the case where the Lookup function fails because it does not find In the case where the Lookup function fails because it does not find
an entry, the SCTP packet is dropped. an entry, the SCTP packet is dropped.
4.4. Differences with Current NAT Support Draft 4.4. Compatibility and increamental deployment
The current proposal for adding SCTP-capable NAT function is meant to
provide backwards compatibility in both involved functionality and
being compatible with legacy SCTP remote terminations that doesn't
implement it.
The compatibility at NAT tracking mechanism allows the NAT functionto
be able hiding also SCTP stack that doesn't implement the current
specfication, at the same time an SCTP stack implementing the current
specification canbe deployed in a NAT scenario where the NAT doesn't
implement it. In either cases the SCTP termination will be
accomplished with limitations as described earlier.
The compatibility at network level is proposed in a way that makes it
possible deploying a cluster of SCTP termination behind a NAT
function still with full compatibility towards legacy networking. As
an example, the scenario described in Figure 2 shows Host A being
hidden by NAT and Host B being directly connected to the internet.
In such case only Host A and NAT need to implement the current
specification whilst Host B can neglect it. The same applies to more
complex scenarios such as the ones shown in Figure 4 or in Figure 5.
4.5. Differences with Current NAT Support Draft
This section describes the differences with the existing draft-ietf- This section describes the differences with the existing draft-ietf-
tsvwg-natsupp. tsvwg-natsupp.
The main difference is that the NAT function is simpler and doesn't From a functional perspective, the major difference between is in the
require explicit handling of NAT missing states. Actually in this compatibility towards legacy SCTP hosts. The NAT-adaptation
proposal NAT doesn't need to parse all the SCTP payloads. NAT only specified in this document allows interoperability between SCTP hosts
parses INIT chunks, filtering of SCTP packets containing INIT chunks even when the remote peer hasn't implemented it. Not even is
is based on checking the SCTP Common Header and discriminate the mandatory that all the NAT devices in the path do implement it as
behavior based on Verification Tag = 0, that indicates the SCTP long as they allow SCTP packets to pass through transparently. On
the existing draft-ietf-tsvwg-natsupp, the specification needs to be
implemented on all SCTP Hosts and all NAT devices in the network in
order to work.
The main technical difference is that the NAT function is simpler and
doesn't require explicit handling of NAT missing states. Actually in
this proposal NAT doesn't need to parse all the SCTP payloads. NAT
only parses INIT chunks, filtering of SCTP packets containing INIT
chunks is based on checking the SCTP Common Header and discriminate
the behavior based on Verification Tag = 0, that indicates the SCTP
packet contains an INIT chunk. The NAT supervises the association by packet contains an INIT chunk. The NAT supervises the association by
means of a timer, if no SCTP packets are seen within a certain time, means of a timer, if no SCTP packets are seen within a certain time,
NAT assumes that the association is closed and will remove the NAT assumes that the association is closed and will remove the
related NAT-entry. related NAT-entry.
The other difference is in the role of the SCTP User. In the current The other difference is in the role of the SCTP User. In the current
proposal it's up to the SCTP User to change the originating Endpoint proposal it's up to the SCTP User to change the originating Endpoint
(i.e. choose a different port number) if collision is detected. The (i.e. choose a different port number) if collision is detected. The
current proposal guarantees that at each node being in a path current proposal guarantees that at each node being in a path
belonging to an association, there will be only one 4-uple describing belonging to an association, there will be only one 4-uple describing
skipping to change at page 31, line 21 skipping to change at page 33, line 21
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>. <https://www.rfc-editor.org/info/rfc8900>.
Acknowledgments Acknowledgments
The author wishes to thank Michael Tuxen , and Magnus Westerlund for The author wishes to thank Michael Tuxen , and Magnus Westerlund for
their invaluable comments. their invaluable comments.
In addition, the author wishes to thank , for their suggestions. In addition, the author wishes to thank Sriram Yagnaraman , for their
suggestions.
The author also wishes to thank the authors of draft-ietf-tsvwg- The author also wishes to thank the authors of draft-ietf-tsvwg-
natsupp-22 which this document is based. natsupp-22 which this document is based.
Author's Address Author's Address
Claudio Porfiri Claudio Porfiri
Ericsson AB Ericsson AB
Torshamnsgatan 21 Torshamnsgatan 21
16440 Stockholm 16440 Stockholm
 End of changes. 13 change blocks. 
73 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/