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

From: Michael Tuexen <[email-masked]>
Date: Wed, 1 Sep 2021 17:27:43 +0200

> On 27. Aug 2021, at 17:24, Claudio Porfiri <claudio.porfiri=[email-masked]> 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?

* 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?

* 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?

* 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?

* 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?

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
> [email-masked]
> 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
>

---

From: Claudio Porfiri <[email-masked]>
Date: Thu, 2 Sep 2021 08:53:25 +0000

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 <[email-masked]> 
Sent: Wednesday, September 1, 2021 5:28 PM
To: Claudio Porfiri <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line
Internet-Drafts directories

Hi Claudio,

* 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.

* 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.

* 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.

* 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.

* 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.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2021 11:59:03 +0200

> On 2. Sep 2021, at 10:53, Claudio Porfiri <claudio.porfiri=[email-masked]> wrote:
> 
> Hi Michael,
> thanks for the comments.
OK.
> parsing the control chunks. It's not a matter of specification.
OK. Haven't looked at the code... Was only referring to the specification.
> 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?
> [teiclap] Yes, this is my fault. It's a collision, not a congestion.
OK.
> will handle the Association.
OK.

Thanks for the clarifications.

Best regards
Michael

---

From: Claudio Porfiri <[email-masked]>
Date: Thu, 2 Sep 2021 10:05:47 +0000

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 <[email-masked]> On Behalf Of Michael Tuexen
Sent: Thursday, September 2, 2021 11:59 AM
To: Claudio Porfiri <claudio.porfiri=[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line

OK.
OK.
OK.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2021 12:29:57 +0200

> On 2. Sep 2021, at 12:05, Claudio Porfiri <claudio.porfiri=[email-masked]> wrote:
> 
> Hi Michael,
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

---

From: Claudio Porfiri <[email-masked]>
Date: Thu, 2 Sep 2021 10:40:08 +0000

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 <[email-masked]> 
Sent: Thursday, September 2, 2021 12:30 PM
To: Claudio Porfiri <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 2 Sep 2021 12:45:14 +0200

> On 2. Sep 2021, at 12:40, Claudio Porfiri <[email-masked]> wrote:
> 
> Hi Michael,
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