[tsvwg] Review of draft-ietf-tsvwg-natsupp-13
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 20 September 2019 17:18 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 BB17F1201C6 for <tsvwg@ietfa.amsl.com>; Fri, 20 Sep 2019 10:18:10 -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_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 SLmBiZFwKIsA for <tsvwg@ietfa.amsl.com>; Fri, 20 Sep 2019 10:18:07 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCEF1200FF for <tsvwg@ietf.org>; Fri, 20 Sep 2019 10:18:06 -0700 (PDT)
Received: from [192.168.1.37] (115.152.7.51.dyn.plus.net [51.7.152.115]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id F2F891B00199; Fri, 20 Sep 2019 18:18:02 +0100 (BST)
Message-ID: <5D8509CA.7010206@erg.abdn.ac.uk>
Date: Fri, 20 Sep 2019 18:18:02 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: Michael Tuexen <tuexen@fh-muenster.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/e2DIUQ-o_1tu4dhlJQA66VfGpmw>
Subject: [tsvwg] Review of draft-ietf-tsvwg-natsupp-13
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: Fri, 20 Sep 2019 17:18:11 -0000
Thank you for addressing the issues raised in my last review. This review is of rev 13, and relates to a detailed review of the languange in preparation for publication. There are a still a number of editorial issues with the current version to ensure this is sufficiently clear for a PS RFC. I think most of these are minor, but I would like you to consider a new rev to address the issues. Please see below, best wishes, Gorry Fairhurst --- I think I understand what is intended by “so that only true NAT is available” - but for the avoidance of doubt can you please explain in the introduction what this means with a REF? Similarly, the English could be improves in: “The end result of this is that only one SCTP capable host can be behind a NAT and.. “ - This time to perhaps say that "only one SCTP-capable host can successfully operate behind such a NAT” Is the following always true: “ The only alternative for supporting legacy NAT devices is …” - This seems like a very bold statement - does this mean it is impossible to design other methods? that the IETF has not specified an alternate? what? “will maintain the proper state” is this better as “will maintain the appropriate state“ - or corresponding state? “without needing to change port numbers.” - is that the NAT or the host that does not need to change a port number? Section 2 needs to be updated to conform to the latest boilerplate text. Please add reference to SCTP base spec for the definition of the Verification Tag Section 4.2 please cite a reference to support calculation of the crc32c in SCTP. In section 4.2, please add “a” in the phrase: “is to use pre-defined table” so that this becomes: “is to use a pre-defined table” I did not fully understand the test: “Other mechanisms could make use of NAT to NAT communication. Such mechanisms are not to be deployable on a wide scale base and thus not a recommended solution.” - I couldn’t work out whether this is a recommendations for some reason in this spec, or a statement of history, or what. The present text is confusing. Please insert a hyphen in “The SCTP Specific Variant of NAT” before specific. In 4.2: “ Using classical NAPT may result in changing one of the SCTP port numbers during the processing which requires the recomputation of the transport layer checksum. “ - I think this is recalculation by the NAT - can you clarify which entity needs to recalculate? In text: “ One possible way of doing this is to use pre-defined table” I think “a” needs too be inserted before table. In 4.2: “Other mechanisms could make use of NAT to NAT communication. Such mechanisms are not to be deployable on a wide scale base and thus not a recommended solution. Therefore the SCTP variant of NAT has been developed.” - I couldn’t work out whether this is a recommendations for some reason in this spec, or a statement of history, or what. The present text is confusing. In 4.3: “ In this section it is assumed that there are multiple SCTP capable hosts behind a NAT that has one Public-Address. “ - Is that really the case? - Is try reader to assume there needs to be multiple SCTP hosts or that there CAN be multiple hosts. Please clarify. in 4.3: “ In this case there must be no more than one entry” - please add in the “NAT binding table” to this phrase. “ The entries in the table fulfill some uniqueness conditions. “ should that be: “ The entries in the table need to fulfill some uniqueness conditions. “ Section 4.3 introduces the concept of a NAT control block - but I could not see where that was defined, nor how it relates to the table. IF I understand section 4.3 correctly it specified 3 different procedures that can be involved when an INIT chunk is received - do you think it is possible to highlight that in the text, e.g. labelling the different procedures as (1), (2) (3) so this is very clear? At the end of section 4, I was unclear what enabled the handling of INIT-collision through NAT - can you please add a sentence or two to make this clear? OLD: a 46-bit random number which has to match NEW: a 46-bit random number that has to match “In the TCP-like NAPT case “ - add citation to an RFC? In 6.2.1: “However, in this unlikely event the NAT device MUST send an ABORT chunk with the M-bit set if the collision is triggered by an INIT or INIT-ACK chunk or send an ERROR chunk with the M-bit set if the collision is triggered by an ASCONF chunk. “ - why “this” and is it necessary to say this unlikely as a part of this sentence , to me it makes for a very long and complicated sentence to include an REFC2119 keywords, please consider rephrasing this and forming several sentences. In 6.3.1: The considerations peak of “ its internal table” - which is this, please use the same term throughput to describe the entry in the table - and the name of the table. “If the INIT is destined to an external address and port for which the NAT device has no outbound connection, it MUST allow the INIT” - what does “allow” mean, does it mean the INIT chunk is forwarded (to whom)? or does this mean something else? “it MUST validate that the external server supports the Disable Restart feature and,” - is this verification using the local information in the table, or something else, please be clear? The end of Section 6.3.1 describe stwo error conditions. - It was not clear to me which sequences of events generated these errors. Please associate the text with one of the procedures. “error cause MUST be sent back. “ - this seems too vague to me, to which address is this sent under what conditions? (Section 6.4.1 seems clearer). Final clause of 6.3: “ Servers that support this feature will need to be capable of” - why isn’t that requirement expressed as a “REQUIRED to” statement at the start of the section? I am confused as to whether thus is really a prerequisite or not? “Please note that such a packet containing an ERROR chunk SHOULD NOT” - please remove the “Please note that” text and directly assert that this SHOULD NOT be done, to avoid any ambiguity that this could be a “note”. “When sending the ERROR chunk, the new error cause ’Missing State’ (see Section 5.2.2) MUST be included and the new M-bit of the ERROR chunk MUST be set (see Section 5.1.2).“ -please remove the two occurrences of “new” from this sentence. Section 6.4.2 places there requirements on the receiver, but I would expect more explicit statements about what happens if the SHOULD is not observed. Bullet two was particularly unclear with the clause; “if it does not discard the incoming ERROR chunk” - Please specify what happens. “ Or, if the address is already part of the association, the SCTP endpoint MUST NOT respond with an error, but instead should respond with an ASCONF-ACK chunk acknowledging the address but take no action (since the address is already in the association).” - there appear to be multiple requirements here, please clarify if the MUST NOT is always needed (maybe make that separate clause) and the /should/ us actually a /SHOULD?? “ Or, if the address is already part of the association, the SCTP endpoint MUST NOT respond with an error, but instead should respond with an ASCONF-ACK chunk acknowledging the address but take no action (since the address is already in the association).“ - to which address? “ It MUST validate that the verification tag is reflected by looking at the VTag that would have been included in the outgoing packet.” …and if not verified, discard the message? OLD: NAT device , then NEW: NAT device, then “NAT does need to change the table for second address:” - Insert “The” OLD: NAT 1 does not need to update the table for second address: NEW: NAT 1 does not need to update the table for the second address: OLD: NAT 2 creates complete entry: NEW: NAT 2 creates a complete table entry: OLD: The NAT device cannot find entry for the association. NEW: The NAT device cannot find an entry in the table for the association. OLD: It sends ERROR message with the M-Bit set and the cause "NAT state missing". NEW: It sends an ERROR message with the M-Bit set and the cause "NAT state missing". I’m unclear about the following, please rephrase: “ Host B adds the new source address and deletes all former entries..” Unclear about what was intended by: “If two hosts are behind NAT devices, they have to get knowledge of the peer’s public address. “ - are these two SCTP hosts that try to communicate wit one another? “The naming of the verification tag in the packet flow is done from the sending peer’s point of view.” - what does “naming mean in this context? “Host A send INIT-ACK, which can pass through NAT B:’ OLD send NEW sends
- [tsvwg] Review of draft-ietf-tsvwg-natsupp-13 Gorry Fairhurst
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp-13 Lars Eggert
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp-13 Michael Tuexen
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp-13 Michael Tuexen
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp-13 Lars Eggert
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp Gorry Fairhurst
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp mohamed.boucadair
- Re: [tsvwg] WGLC of draft-ietf-tsvwg-natsupp to C… Gorry Fairhurst
- Re: [tsvwg] WGLC of draft-ietf-tsvwg-natsupp to C… Michael Tuexen
- Re: [tsvwg] WGLC of draft-ietf-tsvwg-natsupp to C… Michael Tuexen
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp Michael Tuexen
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp mohamed.boucadair
- Re: [tsvwg] Review of draft-ietf-tsvwg-natsupp Michael Tuexen