Re: [tsvwg] Editorial comments on “draft-ietf-tsvwg-natsupp-07.txt"

[Michael Tuexen <[e-mail]>]

> On 21 Mar 2015, at 17:48, Gorry Fairhurst <[e-mail]> wrote:
> 
> I have some minor comments given in the next email (of course individual comments).
Hi Gorry,

thank you very much for the comments. See my answers in-line.

Best regards
Michael
> 
> 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.
Removed from abstract.
> - The abstract also need stop say that the document defines the NAT behaviour required to support SCTP.
Assuming "need stop say" means "needs to say" I changed the text to:

<t>This document describes the protocol extensions required for the SCTP
endpoints and the mechanisms for NATs necessary to provide similar features
of NAPT in the single-point and multi-point traversal scenario.</t>
> ===
> 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?
You are correct. I added:
Please note that this document focuses on the case where the NAT maps multiple
private addresses to a single public address.
> ===
> “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.
Text removed.
> ===
> “much as TCP does today” 
> - I suggest “in the same way that a TCP session can use a NAT”
OK.
> ===
> 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.
I added
Familiarity with the terminology used in
<xref target='RFC4960'/> and <xref target='RFC5061'/> is assumed.
to Section 3, since I think it is a better place for this statement.
> ===
> SECTION 3:
> - It could be worth prefixed “Verification Tag” with “SCTP” in case a NAT implementor does not immediately understand these terms.
Changed to
"The SCTP Verification Tag (VTag) that the internal host has chosen for its
communication."
> ===
> SECTION 4.2:
> “add considerable”
> - Better perhaps as: “considerably adds”
Used "This would considerably add to the NAT computational burden"
> ===
> SECTION 4.2:
> “considered by the authors”
> - should be removed.
Done.
> ===
> SECTION 4.3:
> ”it should be noted that”
> - should be removed.
Done
> ===
> 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
Changed to MUST
> ===
> 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).
Added:
<t>This section defines the formats used to support NAT traversal.
<xref target='chunks'/> and <xref target='errcause'/> describe chunks
and error causes sent by NATs and received by SCTP end points.
<xref target='newparam'/> describes parameters sent by SCTP end points and
used by NATs and SCTP end points.</t>
> ===
> 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?
I think this is an extension to RFC 4960. Nodes that won't operate in a network with NATs
(for example SIGTRAN networks) don't nee to support this.
> ===
> 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”
OK. Normally the RFC Editors changes the sentences "The suggested value of this field for IANA is ..."
> ===
> 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.
Changed to "Procedures for SCTP End Points and NATS" since I think is better fits.
> ===
> Section 6.1:
> - Excess letters after [RFC4960] ???
No idea why there were there...
> ===
> 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.
OK. I added:
<t>The association setup procedure defined in <xref target='RFC4960'/>
allows multi-homed SCTP end points to exchange its IP-addresses by using
IPv4 or IPv6 address parameters in the INIT and INIT-ACK chunks.
However, this can't be used when NATs are present.</t>
> ===
> Section 6.3:
> - Insert “-“ between “TCP” and “like”
Done.
> ===
> 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?
What about:
<t>The sender of the packet containing the INIT chunk or the receiver
of the INIT-ACK chunk, upon reception of an ABORT chunk with M-bit set
and the appropriate error cause code for colliding NAT table state is included,
MUST reinitiate the association setup procedure after choosing a new initiate
tag, if the association is in COOKIE-WAIT state. In any other state, the
SCTP endpoint MUST NOT respond.</t>
> ===
> 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).
OK.
> ===
> “i. e.” should be “i.e.,”
OK. Changed several times.
> ===
> 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.
This is IP level stuff. Just standard IP level fragmentation and reassembly.
> ===
> SECTION 7.
> - I think this section is informative, if it is, it would be nice to have a sentence saying so at the start.
I added:
<t>Please note that this section is informational only.</t>
> ===
> 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.
In particular, SCTP is protected by the verification tags and the usage of
<xref target='RFC4895'/> against off-path attackers.
> ===
> Please consider adding a summary table pointing NAT implementors to the specific sections were there are things that need to be implemented to support SCTP.
I thought about it. But I think it might be better to make the text in section 6
more clear regarding what is needed by NATs and end points.
Maybe it is helpful to include message diagrams as in Section 7 also in Section 6?
>