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

[Claudio Porfiri <[e-mail]>]

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 <[e-mail]> 
Sent: Saturday, April 24, 2021 2:20 PM
To: Claudio Porfiri <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP

> On 22. Apr 2021, at 08:01, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> 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.
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
> 
> 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.
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.
[teiclap] Yes, port-forwarding is manually specifying entries in the NAT binding table.

> 
> 
> 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.
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.
  
> 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.
That is definitely simpler than what is required for draft-ietf-tsvwg-natsupp.
> 
> 
> - 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.
I don't think draft-ietf-tsvwg-natsupp describes any synchronization methods between NAT functions.
[teiclap] Agree.

> 
> 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.
[teiclap] Correct. It does depend on SCTP, this part I need to rewrite.

> 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.
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.


> 
> - 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 ).
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.
> 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.
That is fine. I don't think any NAT variant must improve this limit.
> 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.
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.

> 
> 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
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.

> 
> 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.
Except the the LB, one can argue which scenarios need to be supported. But, except LB, all of them
are fine.
> 
>
----------------------------------------------------------------------------------------------------
> -----
> 
> 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.
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. 

> - 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);
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.

>            *** 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);
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.
[teiclap] Correct.

>            *** 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.
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. 

> 
>    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
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.

> 
> 
> 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.
How can that happen?
[teiclap] Explained above, due to SCTP and NAT be asynchronous.

>  - 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.
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.
>    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.
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?
[teiclap] The sender cannot distinguish.

> 
> 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.
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.
[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.

> 
>    Since the set of remote IP addresses is not CONFIRMED, client will start probing with HB.
This can just be a local decision.
[teiclap] Yes, this is a local decision. To be improved in the overall description.

> 
>    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
Why would this be send?
[teiclap] Correct. This is possibly a mistake. I need to check again the Use Case.

>      - 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.
See above.
>        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.
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.

> 
>    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)
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.
>   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.
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).
> 
>     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".
I don't understand the vtag mismatch cases. How can they occur?
> 
>    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.
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.

> 
> 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
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.
[teiclap] Yes.

> 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.
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.
> 
>    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.
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

> 
> 
> 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: [phone]
> [e-mail]
> 
> 
> 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