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

[Claudio Porfiri <[e-mail]>]

Hi Michael,
thanks for the clarification, actually RJ is not needed.
This makes the proposal even simpler.
As a matter of facts, I should update the draft because of this.
Can I do before the discussion, or shall I clarify in the slides and take the update afterwards?

Best regards,
Claudio

-----Original Message-----
From: Michael Tuexen <[e-mail]> 
Sent: Thursday, September 2, 2021 12:30 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 2. Sep 2021, at 12:05, Claudio Porfiri <claudio.porfiri=[e-mail]> wrote:
> 
> 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.
Well, it will process the INIT, send an INIT-ACK and the endpoint does NOT change its
state. So for the "server side", this is OK.

It is the sender of the INIT, who needs to map the INIT-ACK to the INIT and should not
progress with the COOKIE-ECHO, but send an ASCONF. So I think only the side wanting
to add an additional address has to do something special. Or am I missing something?
> The RJ parameter would tell the receiver to handle that INIT as a simple query.
Isn't a received INIT always handled that way?

Best regards
Michael
> 
> 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
>>>