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

[Michael Tuexen <[e-mail]>]

> On 2. Sep 2021, at 12:40, Claudio Porfiri <[e-mail]> wrote:
> 
> 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?
From my perspective, doing it in the slides is perfectly fine. Updating the ID
the interim would allow you to include also the feedback you get via the interim.

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