Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line Internet-Drafts directories

[Claudio Porfiri <[e-mail]>]

Hi Michael,
on the reason why RJ parameter, my understanding is that the remote peer receiving an INIT with new
source IP address
would treat it as a normal INIT, thus it will try to establish a new association.
The RJ parameter would tell the receiver to handle that INIT as a simple query.

Best regards,
Claudio

-----Original Message-----
From: tsvwg <[e-mail]> On Behalf Of Michael Tuexen
Sent: Thursday, September 2, 2021 11:59 AM
To: Claudio Porfiri <claudio.porfiri=[e-mail]>
Cc: [e-mail]
Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line
Internet-Drafts directories

> On 2. Sep 2021, at 10:53, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> Hi Michael,
> thanks for the comments.
> I am adding details in the slides, at the same time I am trying to answer your questions below.
> 
> Best regards,
> Claudio
> 
> -----Original Message-----
> From: Michael Tuexen <[e-mail]> 
> Sent: Wednesday, September 1, 2021 5:28 PM
> To: Claudio Porfiri <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line
> Internet-Drafts directories
> 
>> On 27. Aug 2021, at 17:24, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
>> 
>> Hi,
>> I've just submitted this draft.
>> Please review it for discussing at the next Transport Area Working Group (tsvwg) WG Virtual
> Meeting:
>> 2021-09-03
> Hi Claudio,
> 
> thank you very much for writing your suggested way of doing NAT for SCTP up.
> 
> Sorry for being late, but I have some high level comments, which you might
> be able to address in your presentation on Friday. It would at least help
> me to get a better understanding of your proposal.
> 
> * According to Section 4.3, all outgoing packets can establish a new state at
>  the NAT function. So why do you need the INIT/INIT ACK exchange before the
>  corresponding ASCONF/ASCONF ACK exchange?
> [teiclap] The outgoing packets will establish a new state at the NAT function, but when those
> packets are out of the Source NAT scope and arrive at the Destination NAT scope they are seen as
> incoming packets, those incoming packets are silently discarded if no NAT state exists. That's why
> INIT must go through the whole path and make NAT creating states.
OK.
> 
> * Section 4.4 states that
>  "The main difference is in the NAT to be stateless rather than following
>  the status of the association."
>  I don't see how the solution described in draft-ietf-tsvwg-natsupp stores
>  the state of the association. Could you elaborate on that?
> [teiclap] That's my fault. When reading the source code in Linux and BSD I've found out that in
both
> implementation the NAT mechanism takes a copy of the internal SCTP state machine and updates it by
> parsing the control chunks. It's not a matter of specification.
OK. Haven't looked at the code... Was only referring to the specification.
> 
> * Section 5.3.1 introduces the Repetitiva Juvant parameter in the INIT chunk.
>  Why is it needed since the NAT functions does not care about verification tags?
>  Isn't this only required for handling incoming SCTP associations? Isn't this
>  a way of load balancing? Isn't this a different problem than NAT? How can
>  the Repetitiva Juvant parameter be considered if the packets are not parsed?
> [teiclap] RJ parameter is for peer-to-peer communication. It tells the remote peer that the INIT
is
> not a new one, as it comes from an unknown source address and transports a vTAG that belongs to an
> existing association. RJ parameters tells the receiver to answer with an INIT-ACK and doing
nothing
> else. INIT with RJ is only needed for creating a path in the NAT devices, those devices don't need
> to know that it transports RJ parameter.
Why does it need to know that it belongs to an existing association. As long as an INIT-ACK
is sent back, everything is OK. Wouldn't this work just without the RJ parameter?
> 
> * Section 7.2 describes an example with congestion. Why do you use a different
>  connection setup in case of congestion? How do you know that there is congestion?
>  Or is this an example of a local port number collision and not about congestion?
> [teiclap] Yes, this is my fault. It's a collision, not a congestion.
OK.
> 
> * How does in Section 7.3 NAT know, that it needs to forward the incoming packet
>  containing the INIT chunk to B1 and not B2?
> [teiclap] This is another fault. In such cases I need to explain that in cases of distributed
> Endpoint the NAT device needs support from a Load Balancer mechanism that decides what SCTP Host
> will handle the Association.
OK.

Thanks for the clarifications.

Best regards
Michael
> 
> Best regards
> Michael
> 
>> 
>> Thanks and best regards,
>> Claudio Porfiri
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 
>> 
>>       Title           : Stream Control Transmission Protocol (SCTP) Network Address Translation
>> Support
>>       Author          : Claudio Porfiri
>> 	Filename        : draft-porfiri-tsvwg-sctp-natsupp-00.txt
>> 	Pages           : 34
>> 	Date            : 2021-08-27
>> 
>> Abstract:
>>  The Stream Control Transmission Protocol (SCTP) provides a reliable
>>  communications channel between two end-hosts in many ways similar to
>>  the Transmission Control Protocol (TCP).  With the widespread
>>  deployment of Network Address Translators (NAT), specialized code has
>>  been added to NAT functions for TCP that allows multiple hosts to
>>  reside behind a NAT function and yet share a single IPv4 address,
>>  even when two hosts (behind a NAT function) choose the same port
>>  numbers for their connection.  This additional code is sometimes
>>  classified as Network Address and Port Translation (NAPT).
>> 
>>  This document describes the protocol extensions needed for the SCTP
>>  endpoints and the mechanisms for NAT functions necessary to provide
>>  similar features of NAPT in the single point and multipoint traversal
>>  scenario.
>> 
>>  Finally, a YANG module for SCTP NAT is defined.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-porfiri-tsvwg-sctp-natsupp/
>> 
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-porfiri-tsvwg-sctp-natsupp-00.html
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>