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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Thu, 02 September 2021 10:30 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA43A0AB6 for <tsvwg@ietfa.amsl.com>; Thu, 2 Sep 2021 03:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAxuOQ4VNCq2 for <tsvwg@ietfa.amsl.com>; Thu, 2 Sep 2021 03:30:08 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D44D3A0AB0 for <tsvwg@ietf.org>; Thu, 2 Sep 2021 03:30:07 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:9469:58bd:450e:39dc]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 8ED3E721BE019; Thu, 2 Sep 2021 12:29:57 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <VI1PR07MB4077E62C1749989E3B2BCE5D87CE9@VI1PR07MB4077.eurprd07.prod.outlook.com>
Date: Thu, 02 Sep 2021 12:29:57 +0200
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA281CCE-59CE-46CC-824D-F0DCE8642D97@lurchi.franken.de>
References: <AM0PR07MB40665310E4A47FAC6BBE768587C89@AM0PR07MB4066.eurprd07.prod.outlook.com> <4EB69E6D-949C-4910-9325-6563683CECCE@lurchi.franken.de> <VI1PR07MB40774003F51C090A2E09DC8687CE9@VI1PR07MB4077.eurprd07.prod.outlook.com> <0B5F5C8D-3D25-4521-BF8A-77B910884E17@lurchi.franken.de> <VI1PR07MB4077E62C1749989E3B2BCE5D87CE9@VI1PR07MB4077.eurprd07.prod.outlook.com>
To: Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ODoI1E2yRcrT9fDrx6Ak0lrk0Oo>
Subject: Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is available from the on-line Internet-Drafts directories
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Sep 2021 10:30:14 -0000

> On 2. Sep 2021, at 12:05, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> 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 <tsvwg-bounces@ietf.org> On Behalf Of Michael Tuexen
> Sent: Thursday, September 2, 2021 11:59 AM
> To: Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org>
> Cc: tsvwg@ietf.org
> 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=40ericsson.com@dmarc.ietf.org> 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 <michael.tuexen@lurchi.franken.de> 
>> Sent: Wednesday, September 1, 2021 5:28 PM
>> To: Claudio Porfiri <claudio.porfiri@ericsson.com>
>> Cc: tsvwg@ietf.org
>> 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=40ericsson.com@dmarc.ietf.org> 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
>>> I-D-Announce@ietf.org
>>> 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
>>>