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

[Claudio Porfiri <[e-mail]>]

Hi Michael,
I have done some homework and prepared some material here https://github.com/teiclap/NAT
based on your previous work.
It's still preliminary as it doesn't contain the examples and I have removed all the Yang stuffs.
Please let me know if it's inline with the expectations.

Thanks,
Claudio.

-----Original Message-----
From: Michael Tuexen <[e-mail]> 
Sent: Tuesday, May 11, 2021 10:03 AM
To: Claudio Porfiri <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP

> On 11. May 2021, at 09:57, Claudio Porfiri <[e-mail]> wrote:
> 
> Hi Michael,
> I think your way forward is reasonable.
> Shall you share the source of the current draft, so that I can easily reuse the structure?
Sure:
https://protect2.fireeye.com/v1/url?k=4d556e15-12ce5710-4d552e8e-86d2114eab2f-4dc25852481081fb&q=1&e
=5cd18f46-694d-4e1e-b06d-5908e21321f8&u=https%3A%2F%2Fgithub.com%2Fsctplab%2FNAT

Let me know if you have any problems.

Best regards
Michael
> 
> Thanks,
> Claudio.
> 
> 
> -----Original Message-----
> From: Michael Tuexen <[e-mail]> 
> Sent: Monday, May 10, 2021 10:56 PM
> To: Claudio Porfiri <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Alternative proposal for nat support of SCTP
> 
>> On 10. May 2021, at 13:22, Claudio Porfiri <[e-mail]> wrote:
>> 
>> Hi Michael,
> Hi Claudio,
>> 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.
> I think we are in agreement here.
>> 
>> Do you think I can rewrite my proposal based on those observation?
> Yes, I think so.
>> Do you think the structure of the proposal is a good way of presenting it?
> Let me make a suggestion and let me know what you think about it.
> 
> * I'll update the NAT document to address the comments of Magnus and Martin. This will
>  improve the document.
> * You'll create a separate ID describing the vtag free way of doing NAT. You refer as
>  much as possible to the existing document and use the same structure. Your document
>  doesn't need to be perfect. Just good enough to have the way of doing NAT written
>  down, such that we can discuss and improve it. Especially the multihoming case is
>  not yet clear to me.
> 
> Once we have both documents on the table, we can see if we can merge them (since you
> used the same structure, it should be relatively easy to integrate it) or if the
> WG decides to move forward with only one of the ways doing NAT. In case it is the
> solution you propose, you can then copy over the text you were referring to initially.
> That should also be relatively straight forward, since you used the same structure
> of the document.
>> 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.
> Right now, I don't know how easy it is to combine the both methods. I guess, once both are written
> down, it is much simpler to decide it.
> 
> The above is a suggestion on how to move forward. Please let me know what you think about it,
> 
> Best regards
> Michael
>> 
>> 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 
>>>> 
>>> 
>>> 
>> 
>