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 >>>
- [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 is av… Claudio Porfiri
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Michael Tuexen
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Claudio Porfiri
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Michael Tuexen
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Claudio Porfiri
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Michael Tuexen
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Claudio Porfiri
- Re: [tsvwg] draft-porfiri-tsvwg-sctp-natsupp-00 i… Michael Tuexen