[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