[tsvwg] Review of draft-ietf-tsvwg-natsupp-20

Timo Völker <timo.voelker@fh-muenster.de> Tue, 04 August 2020 08:19 UTC

Return-Path: <timo.voelker@fh-muenster.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 ABF603A0FCE for <tsvwg@ietfa.amsl.com>; Tue, 4 Aug 2020 01:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 m0MrfaYdcTUG for <tsvwg@ietfa.amsl.com>; Tue, 4 Aug 2020 01:19:42 -0700 (PDT)
Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133123A0FCB for <tsvwg@ietf.org>; Tue, 4 Aug 2020 01:19:41 -0700 (PDT)
Received: from fhad-ex03.fhad.fh-muenster.de (unknown [10.40.11.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.fh-muenster.de (Postfix) with ESMTPS id A8CED2854C4 for <tsvwg@ietf.org>; Tue, 4 Aug 2020 10:19:39 +0200 (CEST)
Received: from fhad-ex04.fhad.fh-muenster.de (10.40.11.27) by fhad-ex03.fhad.fh-muenster.de (10.40.11.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 4 Aug 2020 10:19:39 +0200
Received: from fhad-ex04.fhad.fh-muenster.de ([fe80::c97a:37b6:5abe:2799]) by fhad-ex04.fhad.fh-muenster.de ([fe80::c97a:37b6:5abe:2799%2]) with mapi id 15.01.1979.003; Tue, 4 Aug 2020 10:19:39 +0200
From: =?iso-8859-1?Q?Timo_V=F6lker?= <timo.voelker@fh-muenster.de>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: Michael Tuexen <tuexen@fh-muenster.de>
Thread-Topic: Review of draft-ietf-tsvwg-natsupp-20
Thread-Index: AQHWajf/d7+pE+ecxEqrJOwuUta6bg==
Date: Tue, 4 Aug 2020 08:19:39 +0000
Message-ID: <5D42569D-959F-406E-A587-A520029C8257@fh-muenster.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.40.10.32]
Content-Type: multipart/signed; boundary="Apple-Mail=_E59456E8-BF43-43B3-80C6-99141F7B0AE5"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IP0evATN76ySeVE7nzykw8M9DxI>
Subject: [tsvwg] Review of draft-ietf-tsvwg-natsupp-20
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: Tue, 04 Aug 2020 08:19:45 -0000

Hi,

here is my review for the SCTP NAT Support draft (draft-ietf-tsvwg-natsupp-20). I found only minor issues.

I'll start with typos and wording, followed by suggestions to rearrange or rewrite some text. 

*Typos, wording, etc.* (syntax: /old text/new text/)

Section 1
... "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 /functions/function/ using internal addresses (see [RFC6890]) and yet share //a /single IPv4 address, even when two hosts (behind a NAT function) choose the same port numbers for their connection." ...
... "/The/This/ document also specifies a set of data formats for SCTP packets and a set of SCTP endpoint procedures to support NAT traversal." ...

Section 4.3
... "Furthermore//,/ this section focuses on the single point traversal scenario." ...

Section 6 
"/When/If/ an SCTP endpoint is behind an SCTP-aware NAT a number of problems may arise as it tries to communicate with its peer:" ...
... "/When/If/ an SCTP endpoint is a server communicating with multiple peers and the peers are behind the same NAT function, then /the two endpoints/these peers/ cannot be distinguished by the server. This case is discussed in Section 6.3." ...
... "/Each of these mechanisms requires/The mechanisms to solve these problems require/ additional chunks and parameters, defined in this document," ...

Section 6.2.2
... "upon reception of a packet /containign/containing/ an ABORT chunk with M bit set and the appropriate error cause code for colliding NAT binding table state is included," ...
... "The sender of// the/ packet containing the ASCONF chunk, upon reception of a packet containing an ERROR chunk with M bit set, MUST stop adding the path to the association."

Section 6.3.1
... "If the packet containing the INIT chunk is originating from an internal port to /an/a/ remote port for which the NAT function has no matching NAT binding table entry," ...

Section 6.4.1
... "If the NAT /device/function/ receives a packet// from the internal network/ for which it has no NAT binding table entry and the packet contains an ASCONF chunk with the VTags parameter," ...

Section 6.4.2
... "The peer SCTP endpoint receiving such a packet containing an ASCONF chunk SHOULD/ either// add the address and respond with an acknowledgment/,// if the address is new to the association (following all procedures defined in [RFC5061]). /Or, if/If/ the address is already part of the association, the SCTP endpoint MUST NOT respond with an error, but instead SHOULD respond with// a/ packet containing an ASCONF ACK chunk acknowledging the address and take no action (since the address is already in the association)." ...
... "It MUST validate that the peer of the SCTP association supports the dynamic address extension. If the peer does not support /it/this extension/, /the NAT function/it/ MUST discard the incoming packet containing the ERROR chunk." ...


*Rearranging, rewriting, etc.*

Definition of incoming and outgoing.
Sometimes an incoming packet for a NET function just means that the NAT function receives a packet (from any direction). Sometimes it means implicit, that the packet came from the public internet. The term outgoing packet is used for the other direction. It might makes the text clearer if either the incoming and outgoing terms are described in the Terminology section or if the direction is described explicitly in the text (e.g. /incoming packet/packet coming from the public internet/).

Uniqueness of NAT binding table entries (section 4.3)
I'm not sure if I understand this correctly. Two entries with the same Internal-Port and Remote-Port are OK, if the hosts *disabled* the restart procedure and used different VTags, right? If yes, then the fifth paragraph in section 4.3 needs to be changed.
"This rule can be relaxed, if all NAT binding table entries with the same Internal-Port and Remote-Port have the support for the restart procedure /enabled/disabled/."

Motivation (section 4.3)
Section 4.3 seems a bit overloaded for a motivation. I would remove the edge cases here and describe them in section 6.
* remove everything from (incl.) "Normally a NAT binding table entry will be created." to (excl.) "The processing of outgoing SCTP packets containing no INIT chunks is described in the following figure.".
* remove the paragraph that starts with "For an incoming packet containing an INIT chunk a table lookup is made only based"
-> The NAT binding table collision is already described in 6.2 and 6.3.
-> The part about NAT table entry exists when INIT or ASCONF received and the lookup when an INIT received (i.e. only by ports) could be added to 6.1 (e.g. in a subsection NAT function considerations)
The section 4.3 should then end with a note that more details can be found in section 6.

SCTP NAPT? (section 6.2)
The last sentence of the first paragraph of section 6.2 mentions a NAPT device. This confuses me. Is there a NAPT specification for SCTP that can do better here? If not, how about removing this sentence?

ASCONF chunk integration (section 6.4.1)
In the first paragraph of section 6.4.1 there is a sentence that says when not to send an ERROR chunk. The ASCONF chunk is not mentioned here. How about:
... "Such a packet containing an ERROR chunk SHOULD NOT be sent if the received packet contains// an ASCONF chunk with the VTags parameter or/ an ABORT, SHUTDOWN COMPLETE or INIT ACK chunk." ...
Also, it seems better to switch the position of paragraph 2 and 3, because the following section (6.4.2) starts with a reference to a packet containing an ERROR chunk, which is described in paragraph 2. Switching the position brings it closer together.

Wildcard address? (section 6.6)
I don't understand the last sentence of section 6.6.
"The address to add is the wildcard address" - which address is to be added and why has it to be the wildcard address?
"the lookup address SHOULD also contain the VTags parameter" - what is the lookup address?

Timo