[tsvwg] Editorial comments draft-ietf-tsvwg-natsupp-07.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sun, 22 March 2015 21:03 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03A1A1BBB for <tsvwg@ietfa.amsl.com>; Sun, 22 Mar 2015 14:03:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level:
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 gHhUDq3MsnCg for <tsvwg@ietfa.amsl.com>; Sun, 22 Mar 2015 14:03:45 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4335E1A1BA4 for <tsvwg@ietf.org>; Sun, 22 Mar 2015 14:03:30 -0700 (PDT)
Received: from [IPv6:2001:67c:370:152:bc95:9fc:c1c1:fcd7] (unknown [IPv6:2001:67c:370:152:bc95:9fc:c1c1:fcd7]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A8DC51B0031F; Sun, 22 Mar 2015 21:03:49 +0000 (GMT)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 22 Mar 2015 16:03:27 -0500
Message-Id: <1FBE0ED1-27D7-43B0-80A0-3A424A08AFB4@erg.abdn.ac.uk>
To: tsvwg@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tsvwg/cf0Foxj5B3JayFz1m13Y3gseivA>
Cc: gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: [tsvwg] Editorial comments draft-ietf-tsvwg-natsupp-07.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 22 Mar 2015 21:03:47 -0000

I separately sent some questions on the new draft. The list below contains mainly minor comments on the new test.

Best wishes,

Gorry

-----------

ABSTRACT
“To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT.”
- While I think this text may be very important fro the introduction, it is not really necessary in the abstract. We can just specify the mechanisms.
- The abstract also need stop say that the document defines the NAT behaviour required to support SCTP.
===
1.INTRODUCTION
- I think (am I correct) that the view of a NAT maps to one public IP address. Is this the case? Can we say this?
===
“The authors feel”
- Authors appears more than once. While it may be true, this phrase should’t appear in a WG draft, unless the authors may differ in opinion to the WG. I don’t think this us the case. I suggest we simply make the statement and see if there is working group consensus. If there is any doubt, please raise this at a WG meeting in the presentation and confirm the outcome on the list.
===
“much as TCP does today” 
- I suggest “in the same way that a TCP session can use a NAT”
===
SECTION 2:
- Do you also need to add a clause saying: “The reader is also assumed to be familiar with the terminology in RFC4960, and XXXX.
===
SECTION 3:
- It could be worth prefixed “Verification Tag” with “SCTP” in case a NAT implementor does not immediately understand these terms.
===
SECTION 4.2:
“add considerable”
- Better perhaps as: “considerably adds”
===
SECTION 4.2:
“considered by the authors”
- should be removed.
===
SECTION 4.3:
”it should be noted that”
- should be removed.
===
SECTION 4.3:
Says that an error chunk SHOULD be sent.
- Why SHOULD in this case. I can see that potentially the chunk may not be delivered, but why not say MUST send. This seems in line with other recommendations later to require sending in 6.3
===
SECTION 5:
- Could we add a sentence saying what is in the section, such as:
“This section defines the formats used to support NAT traversal. Section 5.1 and 5.2 describe chunks generated by NATs and interpreted by SCTP end hosts. 5.3 describes parameters set by end hosts and used by NATs and end hosts.” (checking of course these statements are correct).
===
SECTION 5:
- In several places this speaks of extending, rather than updating. This may or may not be the correct term. What is the compliance statement with respect to the SCTP base sec. Are implementations expected to implement the NAT travseral endpoint support, or is this optional? How does the WG wish to handle this and what are reasonable expectations of a “full” SCTP stack?
===
SECTION 5:
- In several places this makes assumptions of the IANA registry update. Can you please add a note, such as this below before each of these to ensure these are not overlooked when we go for publication:
“XXX TO BE CONFIRMED BY IANA”
===
Section 6.
- Would it be possible to rename this section “End host and NAT Procedures”. This could be helpful to ensure readers get to the correct sections.
===
Section 6.1:
- Excess letters after [RFC4960] ???
===
Section 6.2:
- I wonder if a NAT implementor a little unfamiliar with SCTP would benefit from a few short words that explained how SCTP-INIT normally works without a NAT. I found this a sudden change in the expected background of the reader.
===
Section 6.3:
- Insert “-“ between “TCP” and “like”
===
Section 6.3:

“These procedures SHOULD be followed only if the appropriate error cause code for colliding NAT table state is included AND the association is in the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK). If the endpoint is in any other state an SCTP endpoint SHOULD NOT respond.”
- I couldn’t work this out. Following a SHOULD with a condition is always a recipe for making a difficult sentence. Does this mean (or not):
“
If the appropriate error cause code for colliding NAT table state is included and the association is also in the COOKIE-WAIT state (i. e. it is awaiting an INIT-ACK), then these procedures SHOULD be followed.”? Or is it “MUST” under this specific case?
- and the next phrase has a “If” and a SHOULD NOT, that’s not entirely clear to me when and why you would not.
- Could you please think about making the RFC2119 language simpler?
===
SECTION 6.4:
“For the NAT”
-insert comma after “NAT” and before “tracking”
- can we start a new line with the NAT behaviour, I’m keen to see separation between paras that tell NATs what to do and paras that tell host stacks what to so. (more later).
===
“i. e.” should be “i.e.,”
===
SECTION 6.6:
- If this is the same as RFC4960, then please cite, if not explain the difference between this and an SCTP end host fragment reassembly rule.
===
SECTION 7.
- I think this section is informative, if it is, it would be nice to have a sentence saying so at the start.
===
SECURITY
- I think this section should not the possibility of off-path attacks and provide a more or less standard sentence saying how SCTP provides protection from off-path data insertion, stating that this protection remains when NATs are used. This “background” may also help readers understand a little more of SCTP.
===