Subject: [tsvwg] Alternative proposal for nat support of SCTP

From: Claudio Porfiri <[email-masked]>
Date: Thu, 22 Apr 2021 06:01:17 +0000

Dear all,
the AD Review to draft-ietf-tsvwg-natsupp-22 has shown some room for improvements. I'd wish to
propose an alternative approach for supporting SCTP in scenarios where NAT and Load Balancers exist.
Please consider my proposal as a way to enhance SCTP and reduce the complexity of previous
proposals.

With best regards,
Claudio Porfiri.

- Background
This proposal is an attempt to solve some of the issues raised in the review of the current
draft-ietf-tsvwg-natsupp-22.
It also deals with implementation of nodes that adopt SCTP as transport protocol in a Cloud
environment, mostly in containerized way, that exploit NAT for redundancy and scalability reasons:
the SCTP Endpoint in those environment is ditributed among SCTP Hosts that expose the same Port but
from the network the SCTP Termination is seen as belonging to a single host. Often those distributed
SCTP Endpoints are multihomed.
A typical example is the AMF node in 5G networks, related to the NG-C interface, (3GPP TS 38.412, TS
38.413), a similar case is the  MME node in 4G network, related to the S1-MME interface (3GPP TS
36.412, TS 36.413).

A NAT supporting SCTP must also be able taking care of simpler scenarios such as SCTP Clients behind
a NAT wishing to create Associations towards the same remote peer, even cases where multiple NAT
exist and/or a transversal scenarios where independent NAT devices deal with the same Associations
in single or multihomed cases.
The case where NAT implements port-forwarding also needs to be considered.

The scenario called Multipoint Traversal is possibly the most complex when distributed SCTP
Endpoint, this cannot be neglected in a SCTP NAT support solution.

- Cornerstones of the proposal
As in draft-ietf-tsvwg-natsupp-22, the main requirement towards NAT is that handling of the SCTP
ports is to be kept at the SCTP Endpoint, thus the NAT devices shall never change SCTP source or
destination ports. In case of collision, it's the source SCTP Endpoints that will take the decision
about adopting a different source port.
The NAT devices will only need to inspect the SCTP common Header of the SCTP packets, all decisions
are based on [Source-IP:Source:Port;Destination-IP:Destination-Port] and VTAG.
The reason why VTAG is read is to check that it's equal to zero, as this means that the packet
transports an INIT chunk.

- Advantages towards natsupp draft version 22
The proposed approach doesn't need the NAT devices to take care of VTAG handling.
The NAT device only needs local rules for creating a NAT Table entry as it doesn't need to trace the
Association establishment.
The NAT table entries are only depending on a timer supervision, not on Association state.
There's no need for synchronization among NAT devices, consistency of NAT Tables among different NAT
devices is kept automatically even in cases of restarts.
NAT doesn't parse SCTP packets, thus NAT behavior doesn't depend on SCTP.
The NAT device doesn't need to send any SCTP packet to the SCTP Endpoints.
Decisions at the SCTP Hosts are taken by means of interpreting the retransmissions and the timeouts,
collisions are solved by the client by choosing a different port numbers rather than a different
VTAG.

- Disadvantages towards natsupp draft version 22
Handling of multiple Associations between the same SCTP Endpoints are not possible (this is not
permitted by RFC 4960 On the same source and destination port pairs ).
The limit of number of Association between hosts is given by the port number, it's not possible from
clients behind NAT to establish more than 64k Associations towards the same remote SCTP Endpoint.
Setup time for Associations in collision case takes longer.

-----------------------------------------------------------------------------------------------

- Scope of the proposal
The scope of the proposal is the use of NAT in networks where SCTP clients and server are
instantiated with neither restrictions on the level of NAT hierarchically or horizontally, nor on
the adoption of multihoming.
In the scoped scenarios, NAT can be used for hiding SCTP clients, servers and for implementation of
Load Balancing in the sense that multiple SCTP servers are hidden and the choice of the one serving
the client is decided by the NAT function implementing Load Balancing at Association Establishment
time and kept for the Association Lifetime.

The proposal doesn't require VTAG handling and the related avoidance/synchronization between server
instances, which the current proposal would require. 
The NAT only does tracking individual paths, the egressing traffic creates return paths towards each
instance avoids the need for VTAG handling.
Tracking is thus handled by a single mechanism that is needed for all cases to deal with multiple
SCTP endpoints sending traffic towards the same remote address.

The following basic scenarios are considered

1) 
                          +-------+
[SCTP client C1]----------+       |
[SCTP client C2]----------+  NAT  +-----
[SCTP client C3]----------+       |     
                          +-------+    
Where SCTP Hosts implementing SCTP Endpoints C1,C2,C3 behave as pure clients, single-homed 

2) 
                          +-------+
[SCTP server S1]----------+       |
[SCTP server S2]----------+  NAT  +-----
[SCTP server S3]----------+       |     
                          +-------+    
Where SCTP Hosts implementing SCTP Endpoints S1,S2,S3 behave as servers, single-homed 

3)
                          +-------+
[SCTP server S1]----------+       |
[SCTP server S1]----------+  LB   +-----
[SCTP server S1]----------+       |     
                          +-------+    
Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving as a server, single-homed

4)

+--------------+          +-------+
|              +          |       |
|SCTP client C1+----------+  NAT  +-----
|              +----+  +--+       |
+--------------+    |  |  +-------+
                    |  |
+--------------+    |  |  +-------+
|              +--- |--+  |       |
|SCTP client C2|    +-----+  NAT  +-----
|              +----------+       |
+--------------+          +-------+
Where SCTP Hosts implementing SCTP Endpoints C1,C2 behave as pure clients, multi-homed 

5)
+--------------+          +-------+
|              +          |       |
|SCTP server S1+----------+  NAT  +-----
|              +----+  +--+       |
+--------------+    |  |  +-------+
                    |  |
+--------------+    |  |  +-------+
|              +--- |--+  |       |
|SCTP server S2|    +-----+  NAT  +-----
|              +----------+       |
+--------------+          +-------+                    
Where SCTP Hosts implementing SCTP Endpoints S1,S2 behave as servers, multi-homed 

6)
+--------------+          +-------+
|              +          |       |
|SCTP server S1+----------+  LB   +-----
|              +----+  +--+       |
+--------------+    |  |  +-------+
                    |  |
+--------------+    |  |  +-------+
|              +--- |--+  |       |
|SCTP server S1|    +-----+  LB   +-----
|              +----------+       |
+--------------+          +-------+     
Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving as a server, multi-homed

7) 
Any complex scenario built with those such as:

                          +-------+
[SCTP client C1]----------+       |
[SCTP client C2]----------+  NAT  +-----+
[SCTP client C3]----------+       |     |
                          +-------+     |    +------+
                                        +----+      |
[SCTP server S1]-----------------------------+  LB  +------- IP A
[SCTP server S1]-----------------------------+      |
                          +-------+  +-------+      |
[SCTP client C4]----------+       |  |       +------+
[SCTP client C5]----------+  NAT  +--+
                     +----+       |
+--------------+     |    +-------+
|              +-----+
|SCTP server S2]          +-------+     
|              +----------+       |
|--------------+          |  NAT  +------------------------- IP B
[SCTP client C6]----------+       |
[SCTP server S4]----------+       |
                          +-------+

In the example above clients C1, C2, C3, C4, C5 and servers S1 and S2 share the same external IP A,
client C6 exploits the external IP B and server S3 is multihomed and exploits IP A and IP B. Server
S4 exploits IP B as well.

Server S1 and S2 are seen as a single, distributed SCTP Endpoint, NAT LB does inspect Association
requests and assigns the serving SCTP host based on a Load Sharing algorithm.

----------------------------------------------------------------------------------------------------
-----

It's important to state that unless being part of a SCTP Distributed Endpoint, the port number used
when defining the SCTP Endpoints of a SCTP server behind a NAT need to be unique.

- What is kept from the draft natsupp v22
Similar to what described in the current draft-ietf-tsvwg-natsupp there's the need of a cooperation
between SCTP Hosts and NAT device in order to allow Association setup and traffic exchange.
The NAT devices will take a lookup table that is meant to keep the state of the Association limited
to what is needed in NAT.
NAT has a functions for searching the lookup table and take a decision based on the results.

The SCTP Endpoint takes the responsibility to take decisions based on the feedbacks received from
the network in order to setup the Association.

An Association is established towards the primary peer interface first, then the other paths that
belong tp a multihomed association are added by means of ASCONF messages.

The following extensions are taken (Only needed for Optional Part)
                                    -----------------------------

Extended ERROR Chunk

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 9    | Reserved  |M|T|           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                   zero or more Error Causes                   /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The ERROR chunk defined in [RFC4960] is extended to add the new 'M
   bit'.  The M bit indicates to the receiver of the ERROR chunk that
   the chunk was not generated by the peer SCTP endpoint, but instead by
   a middle box.

----------------------------------------------------------------------------------------------
Proposal in details
----------------------------------------------------------------------------------------------

The NAT functionality takes care of SCTP packets in EGRESS meaning that the SCTP packet is
originated from an SCTP host that is located behind the NAT itself, as well as SCTP packets in
INGRESS meaning that the SCTP packets are originated from the external network.
NAT learns about Associations by inspecting the SCTP Header only, it has knowledge of
[Source.IP:Source.Port;Dest.IP:Dest.Port]; a timer supervision exists at association level that
removes the Association information from the NAT after a timer expires.
NAT needs to recognize INIT chunks, this is achieved by looking at SCTP header since INIT must be
transported in a SCTP packet with VTag=0.
There's no Signaling between NAT and the SCTP host, rather SCTP host understands the NAT behavior as
it will experience retransmission faults when the NAT device cannot forward the SCTP packets.

In details, the implementation of what proposed in this paper allows:
    * Client in NAT environment to establish multihomed associations towards remote Servers
    * Server in NAT environment to establish multihomed associations from remote Clients
    * Client or Server in NAT environment to establish multihomed associations towards legacy RFC
4960 peers
    * NAT devices to cope with multihomed SCTP traffic
    * NAT devices to cope with restart (with limitations)

Limits of the proposed paper are described below:
    * Network Address and Port Translation (NAPT) is not supported.
    * Limited amount of possible association towards the same remote host (16 bit).
    * Restart in NAT devices under some circumstances can go in race condition.
    * Limited interwork with legacy SCTP Host
    * Multiple Associations between the same SCTP Endpoints are not supported

NAT device SCTP specialization
==============================

NAT need to implement NAT forwarding table for SCTP containing the information related to SCTP
Association as well as the forwarding.
NATTableEntry ::= [Source.IP:Source.Port;Dest.IP:Dest.Port;fwd.IP;NATTimer]

Since Distributed SCTP Endpoint is supported, there are NAT that have multiple choices for
forwarding packets, i.e. there are multiple hosts having an SCTP Server at the same SCTP Port.

SCTP Parsing
------------
In order to handle SCTP packets, NAT needs to discriminate packets containing an INIT chunk. This is
achieved by checking the Destination VTag in the SCTP Header, because SCTP packets containing INIT
chunk have VTag = 0.

Load Balancers
--------------
A Load Balancer is a node in the network that hides the instantiation of an SCTP Endpoint over a set
of SCTP Hosts in a local network.
The Load Balancer at INIT will select one SCTP Host for handling it, the traffic related to the
resulting Association will be NATted towards the chosen host.
When a INIT packet reaches a Load Balancer, there are multiple choices for the selected
Dest.Address:Dest.Port, LB will select one of the SCTP Hosts that can be elected for terminating the
Association. It's out of scope of this paper the description of a selection algorithm. Note that
multiple choices only applies to LB devices when INIT arrives as INGRESS.

SCTP control functions
----------------------
NAT implementations provide the following functions:

boolean lookupNAT(Source.IP, Source.Port, Dest.IP, Dest.Port)
    returns TRUE if an entry in NATTable matches the given 4-tuple

boolean multipleDestination(Dest.Port)
    returns TRUE is multiple hosts exist sharing the given SCTP port

void createNAT(Source.IP,Source.port,Dest.IP,Dest.port)
    creates an entry at the NATTable with the given SCTP Association

void forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port)
    locate the given SCTP association in NATTable, do NAT and forward the packet.
    Reset the NATTimer tied to the entry.

void discardPacket(Source.IP,Source.port,Dest.IP,Dest.port)
    silently discard the packet for the given Association

void destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port)
    removes from NATTable the entry related to the given SCTP Association

void sendINITError(Source.IP,Source.port,Dest.IP,Dest.port)
    sends an ERROR Chunk towards Source.IP,Source.port with parameter "INIT cannot be forwarded"

Meta-code of the NAT behavior

INGRESS Packets :
    if pkt==INIT
        if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port)  
            // This is congestion case, since multiple associations between the
            // same SCTP Endpoints are not supported, the packet is discarded
            discardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
            *** OPTIONAL sendINITError(Source.IP,Source.port,Dest.IP,Dest.port); ***
        else
            if MultipleDestination(Dest.Port)
                // This case applies only on Load Balancers and only with INGRESS                
                // Here LB solves the distributed Endpoint
                Choose a local Host according to the Load Balancer Rules 
                // -----------------------------------------------------
            createNAT(Source.IP,Source.port,Dest.IP,Dest.port);
            forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
    else
        if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port)
            forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
        else
            discardPacket(Source.IP,Source.port,Dest.IP,Dest.port);

EGRESS Packets :
    if pkt==INIT
        if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port) // This is congestion case
            discardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
            *** OPTIONAL sendINITError(Source.IP,Source.port,Dest.IP,Dest.port); ***
        else
            createNAT(Source.IP,Source.port,Dest.IP,Dest.port)
            forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
    else
        if lookupNAT(Source.IP,Source.port,Dest.IP,Dest.port)
            forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port);
        else
            createNAT(Source.IP,Source.port,Dest.IP,Dest.port)
            forwardPacket(Source.IP,Source.port,Dest.IP,Dest.port);

NATTimer Expiration :
    destroyNAT(Source.IP,Source.port,Dest.IP,Dest.port);

NAT behavior with SCTP packets
------------------------------
    In a NAT where the HB packets are EGRESS, according to NAT behavior they can be:
        discarded - in such case the sender will experience rtx timeout
        forwarded to the right SCTP host - in this case the peer will reply with proper SCTP Chunk
        forwarded to the wrong SCTP host - in this case the wrong host will see an OOTB packet.

    In a NAT where the HB packets are INGRESS, according to NAT behavior they can be:
        discarded - in such case the sender will experience rtx timeout
        forwarded to the right SCTP host - in this case the peer will reply with proper SCTP Chunk
        forwarded to the wrong SCTP host - in this case the wrong host will see an OOTB packet

Data Formats:

ERROR Chunk
    New parameter : HB with Inconsistent VTag
    New parameter : ASCONF with Inconsistent VTag
    New parameter : INIT cannot be forwarded

INIT Chunk Parameters: (may appear in INIT, INIT-ACK and ASCONF)
    IP Addresses NOT CONFIRMED

SCTP Endpoint behavior
======================
An SCTP Endpoint receiving an OOTB packet will check:
  - If it's an HB packet, whose 4-uple is consistent with an Association established at that Host
but VTags are not known, an ERROR signal "HB with Inconsistent VTag" will be sent back.
  - If it's an ASCONF packet with "Address 0.0.0.0" and ERROR signal "ASCONF with Inconsistent VTag"
will be sent back.
  - A legacy RFC 4960 SCTP Host on the other hand should send an ABORT, whilst implementations exist
that can be configured for silently discarding OOTB packets.

An SCTP Endpoint receiving an ERROR Chunk with parameter "INIT cannot be forwarded" will check
whether it has been caused by an own INIT by verifying source and destination IP addresses, ports
and VTAG. In case it maps an own INIT Chunk, the SCTP Host will behave as in case of rtx timeout,
otherwise that chunk will be treated as an OOTB chunk.

NAT and port forwarding: we are not considering port forwarding as a valid NAT case, an SCTP Host
behind a NAT that does port forwarding for that SCTP Host is the same as exposing the SCTP Host
directly on the external network, in this case there's no need to change what the NAT does.  

In the following description we assume that all NAT and Load Balancers implement the NAT behavior as
described above. The remote SCTP Host on the other hand may implement legacy rfc4960, this is
considered in the Use Case description.

Use Cases:

Client only cases:
1. Single-homed vs single-homed
    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
number.
    Reason why INIT/INIT-ACK doesn't succeed is assumed to be due to a congestion in any of the NAT
being part of the path between the SCTP Endpoints.

2. Single-homed vs multihomed (public IP addresses known to the multihomed peer)
    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
number.
    INIT-ACK packet contains a new option that indicates the list of IP addresses is NOT CONFIRMED

    Since the set of remote IP addresses is not CONFIRMED, client will start probing with HB.

    According to NAT Behavior above, the peers can experience
      - HB-ACK : the IP address becomes CONFIRMED
      - rtx timeout : the sender keep on probing that path according to RFC 4960
      - ERROR "HB with Inconsistent VTag" : the IP address used for HB is permanently unavailable
and the sender MAY try to probe it again after a certain time
      - ABORT : after checking that the ABORT has been caused by HB by checking the Source.IP, in
case it's confirmed that ABORT has been caused by HB, the sender will threat it in the same mode as
an ERROR "HB with Inconsistent VTag".

    Note that, due to the network configuration, the multihomed Association resulting may not be
complete as a set of paths may be not possible to establish.

3. Multihomed vs multihomed (public IP addresses known to the multihomed peers)
    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
number.
        INIT packet contains a new option that indicates the list of IP addresses is NOT CONFIRMED.
        INIT-ACK packet also contains a new option that indicates the list of IP addresses is NOT
CONFIRMED.

    When succeeding, since the set of remote IP addresses is not CONFIRMED, client and server will
start probing with HB.

    The behavior of the peers is the same as described above in case 2.

    Same as case 2, multihomed Associations may not be completed.

4. Multihomed vs multihomed (public IP addresses unknown to the multihomed peer)
   This case begins as the single-homed vs single-homed case until the Association is established.

   The peers, independently, will start adding further IP addresses to the Association, one at a
time, since the public IP address is unknown, the SCTP Host only knows the local IP addresses it can
use.
   The SCTP Endpoint will use rfc6051, it will send an ASCONF signal with IP-address = 0.0.0.0 using
one of the internal IP address as source towards a CONFIRMED peer's IP address.

     According to NAT Behavior above, the peers can experience
      - ASCONF-ACK : the IP address is added to the Association and path probing can start as in
case 2.
      - rtx timeout : the IP address used for ASCONF is permanently unavailable
      - ERROR "ASCONF with Inconsistent VTag" : the IP address used for ASCONF is permanently
unavailable and the sender MAY try to probe it again after a certain time
      - ABORT : after checking that the ABORT has been caused by ASCONF by checking the Source.IP,
in case it's confirmed that ABORT has been caused by ASCONF, the sender will threat it in the same
mode as an ERROR "ASCONF with Inconsistent VTag".

    Same as case 2, multihomed Associations may not be completed.

5. Server Endpoint vs Server Endpoint
    This is a special case where both Endpoint have a fixed and well-known port number that MUST be
used as Source.port in the Association establishment. In such case, only one host within a NAT zone
can establish one Association towards another host in another NAT zone.

    The Endpoint acting as Client sends INIT packet, if not succeed it will not try again but inform
the application that it's not possible to establish an Association.

6. NAT restart.
    If a NAT restarts, the NAT table is lost and the following events can occur:
    An existing association keeps on sending packets on the set of paths known by the peers.
    According to the NAT rules, those SCTP packets will make NAT re-creating the proper NAT entries
from the EGRESS traffic perspective.

    Race condition may happen when one sctp host will send an INIT packet that will arrive at the
NAT before a traffic packet can restore the NAT entry. In such case INIT has overwritten the NAT
entry that was previously used by the existing association.
    We see this event as very rare to happen, and the reason for it is because NAT is a blocking
mechanism that doesn't provide full capacity. A multihomed configuration can help reducing the
blocking probability.

    The race condition can be partially solved if the NAT waits for a time long enough to cope with
all the associations data or HB transmissions. After that time it can be assumed that all the
Associations using that NAT will have rebuilt the related entries in the NATTable.
    The solution would not handle INIT chunks during that observation time, after that INIT chunks
can be handled.

6. Timing considerations
    SCTP exploits internal retransmission timers for detecting how NAT devices on the paths are
acting and uses timeouts in order to take decisions on how to setup the multihomed association.
Here, the shorter the timers the quicker the setup procedure, still assuming that the initial setup
can go into collision a number of times it may take a significant time to setup associations. RFC
4960 provides a set of recommended values to be used for timers and retransmission attempts, the
adoption of those timers would need to be reconsidered in the scope of the current paper.

    The current paper has a simple state machine at the NAT devices based on a supervision timer,
this is possible because SCTP sends traffic over all the paths at least at HB timing rate for path
probing. Every time an SCTP Packet is forwarded, NATTimer is restarted.
    The choice of NATTimer value SHOULD ensure that there are no rtx timeouts due to NATTimer
expiration, in fact NATTimer needs to cope with the slowest traffic case that is path probing, is
then recommended that NATTimer is larger than 2 times HB timer, but at the same time NATTimer must
release a path as soon as it's not being used by an active Association, this would suggest a value
that is as short as possible.
    A good compromise seems to be 2 * HB timer < NATTimer < 2 * HB timer.

7. Association setup improvement (Optional)
    It is possible to improve the setup time for an association if NAT device could help SCTP host
to take a quick decision in case of collision.
    This feature is optional and MAY be implemented at the NAT device, whilst handling is mandatory
at the SCTP host.
    When a NAT device will receive an INIT chunk, it will check whether it can be forwarded by
inspecting the NAT lookup table. If it cannot be forwarded, it MAY send an SCTP Packet containing an
ERROR Chunk with parameter "INIT cannot be forwarded". Since no association exists yet, and because
VTAG=0 cannot be used, the NAT device need to parse the received INIT chunk and retrieve the
Initiate Tag that will be used as VTAG.

====================================================================================================
========================

Ericsson 
 
Claudio Porfiri
System Developer
 
Developer
BNEW DNEW NSV PPA RAN Infra Architecture
Mobile: +46761498209
[email-masked]

Ericsson
Isafjordsgatan 14E
164 80,Stockholm
Sweden
 
Our commitment to Technology for Good and Diversity and Inclusion contributes to positive change in
the Networked Society.
Follow us on: Facebook LinkedIn Twitter
Legal entity:ERICSSON AB registration number 556056-6258, registered office in  
 This communication is confidential. Our email terms
www.ericsson.com/en/legal/privacy/email-disclaimer

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 24 Apr 2021 14:19:33 +0200

> On 22. Apr 2021, at 08:01, Claudio Porfiri <claudio.porfiri=[email-masked]> wrote:
> 
> Dear all,
Hi Claudio,

the authors of draft-ietf-tsvwg-natsupp-22 have never stated that the document describes the
only way to do NAT for SCTP, but is describes one way. There are definitely other ways to do it
with different pros and cons.

Regarding your proposal, see my comments in-line.

Best regards
Michael
> The case where NAT implements port-forwarding also needs to be considered.
I'm not sure what you mean by referring to 'port-forwarding'. If you refer to a way to add
manually specific entries into the NAT binding table, then it is fine. But we haven't specified
that. If you refer to a way to change port numbers of packets processed by the NAT function,
then this is not covered by NAT variant described in draft-ietf-tsvwg-natsupp.
> about adopting a different source port.
In my view an SCTP end-point can not change its local port number. It is a property of the end-point.
Looking at the socket API (which is only informational, I understand this), you can't "re-bind" an
end-point. You either call bind() explicitly once or it is called implicitly when you call connect()
or sendto().
So in your case you would have to fail the association setup in case of an internal port number collision.
The question is if the probability of this failure is acceptable. My understanding is that NAPT was
introduced to deal with local port number collision, since it was considered too likely. That is the
whole reason why we introduced the method described in draft-ietf-tsvwg-natsupp. The 4-tupel consisting
of both port numbers and port v-tags are used as a connection identifier.
If failing SCTP association setups in case of local port number collisions is acceptable, then the
methode described in draft-ietf-tsvwg-natsupp is not needed.
> transports an INIT chunk.
That is definitely simpler than what is required for draft-ietf-tsvwg-natsupp.
> devices is kept automatically even in cases of restarts.
I don't think draft-ietf-tsvwg-natsupp describes any synchronization methods between NAT functions.
> NAT doesn't parse SCTP packets, thus NAT behavior doesn't depend on SCTP.
I agree that your description does not require any chunk processing of SCTP packet, but is does need
to understand the SCTP common header (you refer to the verification tag). So the NAT does need
to understand SCTP and act in an SCTP specific way.
> collisions are solved by the client by choosing a different port numbers rather than a different
I don't understand that. An SCTP end-point can not change its local port number. A client application
can retry connection setups. But how does the client application know that it has to retry with a
new end-point compared to the peer end-point is not available or there is some temporary network
outage?
> permitted by RFC 4960 On the same source and destination port pairs ).
And I wouldn't consider this a disadvantage. It is just a consequence of the way local port number
collisions are handled. I think handling of local port number collisions is important (I think
we disagree here), but I don't think more than one association between two end-points is 
feature which is required.
> clients behind NAT to establish more than 64k Associations towards the same remote SCTP Endpoint.
That is fine. I don't think any NAT variant must improve this limit.
> Setup time for Associations in collision case takes longer.
I think load balancers are different from NAT function. A load balancer, in my view, gives a single
point of contact, but the actual traffic is managed by multiple other nodes.
This is similar to an any-case service. A good way to deal with this would be that the clients would
send the packets containing the INIT chunks to the IP address of the load balancer. The load balancer
would decide, which endpoint should deal with this particular association (the algorithm does not
need to be specified and I'm sure there are already a bunch of methods with IPRs). Then the actual
end-point would send back an INIT-ACK with a specific parameter indicating the this INIT-ACK belongs
to the INIT which was sent to the address of the load balancer, but that particular address will not
be used anymore. This way the load balancer is not involver in the actual communication anymore.
> Where SCTP Hosts implementing a distributed SCTP Endpoint S1, behaving as a server, single-homed
I do see that different from NAT. There is no NAT necessary for this, just an address change during
the handshake.
Except the the LB, one can argue which scenarios need to be supported. But, except LB, all of them
are fine.
That is the fundamental difference between your proposal and the one in draft-ietf-tsvwg-natsupp.
draft-ietf-tsvwg-natsupp does assume that handling of local port number collisions is required, whereas
your proposal does assume that it is not required.
> The following extensions are taken (Only needed for Optional Part)
Doesn't this mean that a retransmission of an INIT chunk is not possible? So if for whatever
reason the first packet of an association containing an INIT chunk is dropped in the network,
the whole association setup fails?
>                Choose a local Host according to the Load Balancer Rules 
This means that a local port number collision results in permanent packet loss for the
INIT chunks. For the end-point this looks like a long term network outage.
> NAT behavior with SCTP packets
Why would a packet be delivered to the wrong SCTP host? Destination addresses are not translated.
>        forwarded to the wrong SCTP host - in this case the wrong host will see an OOTB packet
Why would that be a wrong entry in the NAT binding table?
>    IP Addresses NOT CONFIRMED
How can that happen?
>    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
Again. This requires the application to create a new end-point and re-try to establish a
new association using the new local end-point. How can the application how that the problem
is a local port number collision and no the peer being currently unreachable?
> being part of the path between the SCTP Endpoints.
The can be congestion on the patch between the SCTP end-points, I agree. But in case of a packet
drop due to congestion or any other reason for packet drop, retransmitting the packet is a
way to handle it. In case of a local port number collision, retransmission is not a way to handle
this. How can the sender distinguish these two scenarios?
>    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
See above.
>    INIT-ACK packet contains a new option that indicates the list of IP addresses is NOT CONFIRMED
I don't understand this. Whether addresses are confirmed or not are a local issue on the sender
side, not something the peer specifies. If a peer using a private address talks to a peer with
public addresses, but can locally decided to run send HBs to ensure NAT binding table entries
are generated. No need to let this being controlled by the peer. The peer does not know if
it is talking to nodes behind a NAT or not.
>    Since the set of remote IP addresses is not CONFIRMED, client will start probing with HB.
This can just be a local decision.
> and the sender MAY try to probe it again after a certain time
Why would this be send?
>    Client sends INIT packet, if it does not succeed it will retry with a different Source.port
See above.
>    When succeeding, since the set of remote IP addresses is not CONFIRMED, client and server will
I do see that the client can put entries into the NAT binding table by sending HB to the public
addresses of the peer. But I don't see how the server does know the public addresses or the client.
The client can not put its private addresses into the INIT chunk due to scoping rules. So even
though the client is multihomed, the peer doesn't know this.
> 4. Multihomed vs multihomed (public IP addresses unknown to the multihomed peer)
Just to be clear: In my view each node only knows its own addresses. These can be public or private
IP addresses (let us not consider link local addresses). So in 1., 2., and 3., the server has
public IP addresses it knows. The client has private IP-addresses it knows, but not its public
addresses seem by it peer.
> one of the internal IP address as source towards a CONFIRMED peer's IP address.
That requires cross routing to be working. This might or might not work. It also requires
specific handling at the sender (it must be able to control the outgoing interface).
> mode as an ERROR "ASCONF with Inconsistent VTag".
I don't understand the vtag mismatch cases. How can they occur?
> the application that it's not possible to establish an Association.
This mean that the single packet loss due to a temporary failure will result in a permanent failure.
>    We see this event as very rare to happen, and the reason for it is because NAT is a blocking
Isn't his a form of a local port number collision? You say it is very rare. Just to be sure,
you agree the the birthday paradoxon considerations apply here.
> adoption of those timers would need to be reconsidered in the scope of the current paper.
I think whatever is written in an RFC would need to give parameters to be used in the Internet.
Parameters to be used in specific application scenarios (signalling networks for nG (n=3,4,5,...))
are not considered in these documents (I agree, that this is bad, but that is a different story).

However, it should be OK to give a timer value for the NAT timer used in the public Internet and
put that in relation to the HB timer. I guess that is the only timer relevant for keeping the
entries in the NAT binding table active.
>    A good compromise seems to be 2 * HB timer < NATTimer < 2 * HB timer.
There is no value for NATTimer which fulfils this constraint. I guess there is a typo?

---

From: Claudio Porfiri <[email-masked]>
Date: Tue, 27 Apr 2021 11:14:41 +0000

Hi Michael,
thank you for the comments.
I think there are some points that I have missed and that need some more work.
I am assuming that there are two families of SCTP users, the ones that act and will always act as a
client where the concept of SCTP Endpoint is not so strong, for those the source port number is not
really important as the user can use any; for those it should be possible to specify a parameter
"ANY PORT" so that SCTP randomly selects a dynamic port as specified by rfc6335. The second family
is tied to the SCTP Endpoint and shall use or be tied to well defined port numbers when acting as
client or server.
When a SCTP user belongs to the first family, SCTP may try itself different port numbers when
experiencing rtx timeout when sending INIT or the user can retry after SCTP failure. 

On your comments, I have answered in-line.

Regards,
Claudio.

-----Original Message-----
From: Michael Tuexen <[email-masked]> 
Sent: Saturday, April 24, 2021 2:20 PM
To: Claudio Porfiri <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP

Hi Claudio,

Best regards
Michael
[teiclap] Yes, port-forwarding is manually specifying entries in the NAT binding table.

> about adopting a different source port.
In my view an SCTP end-point can not change its local port number. It is a property of the
end-point.
Looking at the socket API (which is only informational, I understand this), you can't "re-bind" an
end-point. You either call bind() explicitly once or it is called implicitly when you call connect()
or sendto().
So in your case you would have to fail the association setup in case of an internal port number
collision.
The question is if the probability of this failure is acceptable. My understanding is that NAPT was
introduced to deal with local port number collision, since it was considered too likely. That is the
whole reason why we introduced the method described in draft-ietf-tsvwg-natsupp. The 4-tupel
consisting
of both port numbers and port v-tags are used as a connection identifier.
If failing SCTP association setups in case of local port number collisions is acceptable, then the
methode described in draft-ietf-tsvwg-natsupp is not needed.
[teiclap] By introducing the possibility to choose a different source port when INIT fails, I have
introduced a sort of NAPT with the difference that SCTP is in full control of the port. I agree on
the point that SCTP Endpoint cannot change the port number as the port number is part of the
Endpoint definition. It would be a better description that an SCTP user can choose another SCTP
Endpoint, limited to the kind of user itself. Whether is SCTP selecting alternative Endpoints or the
user to explicitly doing that or even SCTP supporting ephemeral Endpoints is worth to talk about.
  
[teiclap] Agree.

I agree that your description does not require any chunk processing of SCTP packet, but is does need
to understand the SCTP common header (you refer to the verification tag). So the NAT does need
to understand SCTP and act in an SCTP specific way.
[teiclap] Correct. It does depend on SCTP, this part I need to rewrite.

> collisions are solved by the client by choosing a different port numbers rather than a different
I don't understand that. An SCTP end-point can not change its local port number. A client
application
can retry connection setups. But how does the client application know that it has to retry with a
new end-point compared to the peer end-point is not available or there is some temporary network
outage?
[teiclap] Here I assumed that a port collision can be seen as temporary or permanent network outage.

I think load balancers are different from NAT function. A load balancer, in my view, gives a single
point of contact, but the actual traffic is managed by multiple other nodes.
This is similar to an any-case service. A good way to deal with this would be that the clients would
send the packets containing the INIT chunks to the IP address of the load balancer. The load
balancer
would decide, which endpoint should deal with this particular association (the algorithm does not
need to be specified and I'm sure there are already a bunch of methods with IPRs). Then the actual
end-point would send back an INIT-ACK with a specific parameter indicating the this INIT-ACK belongs
to the INIT which was sent to the address of the load balancer, but that particular address will not
be used anymore. This way the load balancer is not involver in the actual communication anymore.
[teiclap] This is a new scenario that I didn't consider. All the Load Balancers I have seen so far
are integrated with a NAT, but having a LB that can redirect without being NAT itself I have to
think and write a Use Case for it. Thanks.

I do see that different from NAT. There is no NAT necessary for this, just an address change during
the handshake.
[teiclap] Correct, this is the integrated LB+NAT. I will fix it.

That is the fundamental difference between your proposal and the one in draft-ietf-tsvwg-natsupp.
draft-ietf-tsvwg-natsupp does assume that handling of local port number collisions is required,
whereas
your proposal does assume that it is not required.
[teiclap] I need to specify it better. One of the problem with SCTP server behind NAT is that
there's no way for selecting which one if the same port is used. I meant that when instantiating
SCTP Endpoints behind NAT, the port number assignment needs to be planed for avoiding clients to be
connected to the wrong server. 

Doesn't this mean that a retransmission of an INIT chunk is not possible? So if for whatever
reason the first packet of an association containing an INIT chunk is dropped in the network,
the whole association setup fails?
[teiclap] INIT chunk wil be retransmitted according to the Endpoint rules. Since NAT will silently
discard those INIT, the Endpoint will experience expiring the retransmission counter.

[teiclap] Correct.

Why would a packet be delivered to the wrong SCTP host? Destination addresses are not translated.
[teiclap] This is a corner case that may happen when the server is a distributed Endpoint in
transversal network, so that there are different NATs on different paths of a multihoming
association. If the Association is closed, the NAT tables will survive in the different NATs for
different times. If a new association is established between the same Endpoints and the Load
Balancer function selects a different SCTP Host, and still the path towards the old SCTP Host exists
because the related NAT hasn't removed the NAT-table entry yet, it's possible that packets are sent
to the old SCTP Host that will see them as OOTB. 

Why would that be a wrong entry in the NAT binding table?
[teiclap] Because it's an old entry belonging to an Association that has been closed.

>    IP Addresses NOT CONFIRMED
How can that happen?
[teiclap] Explained above, due to SCTP and NAT be asynchronous.

Again. This requires the application to create a new end-point and re-try to establish a
new association using the new local end-point. How can the application how that the problem
is a local port number collision and no the peer being currently unreachable?
[teiclap] Correct. The whole part with Endpoints and port number requires rewriting.
[teiclap] The sender cannot distinguish.

See above.
I don't understand this. Whether addresses are confirmed or not are a local issue on the sender
side, not something the peer specifies. If a peer using a private address talks to a peer with
public addresses, but can locally decided to run send HBs to ensure NAT binding table entries
are generated. No need to let this being controlled by the peer. The peer does not know if
it is talking to nodes behind a NAT or not.
[teiclap] The reason behind NOT CONFIRMED is to reduce the check for odd OOTB chunks to HB. I agree
that this part can be improved.

This can just be a local decision.
[teiclap] Yes, this is a local decision. To be improved in the overall description.

> and the sender MAY try to probe it again after a certain time
Why would this be send?
[teiclap] Correct. This is possibly a mistake. I need to check again the Use Case.

See above.
I do see that the client can put entries into the NAT binding table by sending HB to the public
addresses of the peer. But I don't see how the server does know the public addresses or the client.
The client can not put its private addresses into the INIT chunk due to scoping rules. So even
though the client is multihomed, the peer doesn't know this.
[teiclap] This assumes that it's possible to have a local configuration in the SCTP Host where
public IP addresses are stored. It depends on implementation.

This mean that the single packet loss due to a temporary failure will result in a permanent failure.
[teiclap] I was not clear in the description. Retransmissions are kept according to rfc4960.

[teiclap] Yes.

There is no value for NATTimer which fulfils this constraint. I guess there is a typo?
[teiclap] Sure! It's 2 * HB timer < NATTimer < 4 * HB timer