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

[Claudio Porfiri <[e-mail]>]

Hi Michael,
about the application involvement, I agree with your points. 
You have stated things in a very clear way.
On the need for NAT to act towards the endpoint, I don't have objections towards ABORT.
The related extensions can be copied from the current draft.
Also about the need to use ASCONF and the reasons behind that I agree with you, it makes things much
easier.

Do you think I can rewrite my proposal based on those observation?
Do you think the structure of the proposal is a good way of presenting it?
I was thinking about the idea that, since the basic concept are similar and the main difference is
whether the NAT take care of parsing chunks and keep the Association state in the legacy and the
timer-based no-parsing proposal, if it's worth to combine both proposal into a single one where SCTP
is compatible with both and the NAT implementor can choose if implementing my proposal as a subset.
I am not 100% sure that compatibility is possible, but it seems to me that they are not diverging.

Best regards,
Claudio.


-----Original Message-----
From: Michael Tuexen <[e-mail]> 
Sent: Thursday, May 6, 2021 2:52 PM
To: Claudio Porfiri <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP

Hi Claudio,

see my comments in-line.

Best regards
Michael

> On 5. May 2021, at 09:40, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> Hi Michael,
> thanks again for your comments.
> I think you are pointing the finger towards the weaknesses of the approach, actually there's room
> for improvement.
> I try to list those here:
> - The application needs to be involved. It's up to the application the decision whether adopting
an
> ephemeral endpoint for the Association where port number is not important. This may or may not be
> demanded to SCTP via socket API, in such case socket needs to be adapted. If the decision is to
add
> the concept of ephemeral endpoint to SCTP, it may be SCTP that tries with different port numbers
> during the Association instantiation attempts.
I'm not sure if we have the same understanding, so for being crystal clear:

(a) An application can request a specific local port number (in the socket API, using bind() with
    a non-zero port number), and in case of a local port number collision, the connection setup has
    to fail. I think we agree here.
(b) An application leaves the local port number selection up to the SCTP stack (in the socket
    socket API by either calling bind() with a zero port number or not calling bind() at all before
    calling connect() or sendto(). However, once the port number is chosen, it can not be changed.
    So in case of a local port number collision, the association setup has to fail. It is up to
    the application to close() the socket and restart from the beginning.
(c) An application leaves the local port number selection up to the SCTP stack (in the socket
    socket API by either calling bind() with a zero port number or not calling bind() at all before
    calling connect() or sendto(). In addition, it indicates the the SCTP can change the local
    port number over time (in the socket API this would be calling an IPPROTO_SCTP level
    new socket option). In this case, the SCTP stack can automatically retry a connection setup
    in case of an local port number collision.

Whether it is easy to implement the rebinding in (c) is implementation specific. But it is
important to say that (b) and (c) require some interaction of the application.
Do we agree on this view?
> - Time for establishing the Association can be really long. The option where NAT sends an ERROR to
> the SCTP Client when experiencing a port collision should be taken as SHOULD. The computational
cost
> added at NAT is reasonable as the SCTP Packet will be parsed only when VTAG == 0 in SCTP Common
> Header. When the endpoint would receive the related ERROR, it will be propagated to the
application
> so that it may decide with another port.
I agree that cooperation with the NAT functions can speed up things. I would suggest to use an ABORT
chunk, since the association will not be established without a port number change. If you use an
ABORT, the local port number collision can be detected in a short time and and SCTP using (c) can
react fast or an application doing (a) or (b) knows fast and can react.
I guess on this point, both ways of doing NAT for SCTP are not that different.
> - SCTP behavior when trying to create the Association. I agree that having the knowledge of the
> public IP address at the endpoint can be difficult. The alternate way exploiting ASCONF as in the
> current ID is preferred, but should the legacy behavior be prohibited?
I'm not sure what you consider to be the 'legacy behaviour'. If you are referring to using IPv[46]
address parameters in the INIT and INIT-ACK chunk, I would not consider it 'legacy' behaviour. It
worked since RFC 2960 and will work in the future. So 'legacy' is not the right term.
The crucial point here is that my understanding is that an SCTP end-point lists in the INIT or
INIT-ACK
chunk addresses this end-point owns, not arbitrary ones.
https://www.ietf.org/archive/id/draft-ietf-tsvwg-rfc4960-bis-11.html#section-3.3.2.1.1
says that the IPv4 address parameter "Contains an IPv4 address of the sending endpoint."
This is an address owned by the end-point, not owned by some NAT functions somewhere as observed
by the peer.
The whole dance with the ASCONF related procedures is done to deal with this case. And I don't
see a way around this.
> - The chance that an SCTP endpoint gets ABORT because the temporary configuration of one of the
NATs
> is causing a packet being forwarded to the wrong host in distributed endpoint case exists.
Currently
> rfc4960 doesn't discriminate ABORT requests, here I think we may improve it: when a multihomed
> association exists and ABORT is received from one of the remote IP addresses but traffic is
ongoing
> from the other IP addresses, is it correct to abort the Association? Should a deeper analysis be
> performed at the endpoint before aborting?
I don't think so. The ABORT indicates that something is wrong and the communication should be
stopped immediately. I think this is the right thing to do.

The problem here is that some mechanism doesn't work right at some time and you want to change
the rest to tolerate this mis-behaviour. I would prefer to make sure this mis-behaviour does not
happen. Or when it happens, the ABORT procedure it the way to stop it from happening.
> 
> Best regards,
> Claudio.
> 
> -----Original Message-----
> From: Michael Tuexen <[e-mail]> 
> Sent: Monday, May 3, 2021 5:35 PM
> To: Claudio Porfiri <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP
> 
>> On 27. Apr 2021, at 13:14, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
>> 
>> 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 using the socket API, where you can specify "ANY PORT" by using 0 as the local port number,
> does mean that the transport layer selects a local port number once. Once it is chosen, it isn't
> changed anymore.
>> 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. 
> Yepp. An application would have to open a socket, try to to connect() and after a timeout (which
> takes a long time) close the socket, create a new one and try again... Basically, the application
> has to deal with local port number collisions and, in particular, has to tolerate long delays.
> This is not required by the method described in the current ID.
> 
> More comments in-line.
> 
> Best regards
> Michael
>> 
>> 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.
> OK, thanks for the clarification. This is also possible using the method described in the ID.
>> 
>>> 
>>> 
>>> 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.
> OK. This means we agree on it. Local port number collisions in your proposal require some action
> by the application. I think the additional delay is also critical...
>> 
>>> 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.
> I understand your view, but I disagree...
>> 
>> 
>>> 
>>> - 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.
> But this takes a loooooong time...
>> 
>>>          *** 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. 
> Hmm. I assumed that a load balancer acts for incoming packets in a deterministic fashion.
>> 
>>> 
>>>  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.
> Ahh, I see.
>> 
>>> 
>>> 
>>> 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.
> I my view, an end-point only lists IP addresses it owns, not addresses it thinks the peer might
> see them. It is very hard to know which addresses are observed by a peer.
>> 
>>> 
>>>  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.
> But then it takes a very long time to deal with local port number collisions.
>> 
>>> 
>>> 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
> OK. I see. Sounds good.
>> 
>>> 
>>> 
>>> 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 
>> 
> 
>