Re: [tsvwg] draft-ietf-tsvwg-behave-requirements-update comments on rev -01

[Gorry Fairhurst <[e-mail]>]

I have read draft-ietf-tsvwg-behave-requirements-update and have some comments on the document text, see below.

Best wishes,

Gorry (as an individual)

--------------

COMMENTS:
---
In Section 1.1

“It is out of the scope of this document the creation of completely	
 new requirements not associated with the documents cited above.”
- Suggest:
“The scope of this document has been set so that it does not create new requirements beyond those specified in the documents cited above.”
---
Section 1.2.Terminology		
“The reader should be familiar with the terms defined in”
- Suggest: “The reader is assumed to be familiar withe terminology defined in: ”
---
Section 2.
- Please add some few words to define “NAPT44”
---
Section 2.1
“But the document does not clearly states if these can be configured separately.”
Suggest: ““But that document does not clearly state whether these can be configured separately.”
---
Section 2.1
“This document clarifies that a NAT device SHOULD provide different	
 	   knobs “
- “knobs” seems to vague, could we say configurable parameters?
—--
“This document further acknowledges that most TCP flows are very short	
(less than 10 seconds) [FLOWRATE][TCPWILD] and therefore a partially	
 open timeout of 4 minutes might be excessive if security is a	
concern.  Therefore, it MAY be configured to be less than 4 minutes	
in such cases.”
- Let’s discuss this on the list:
- Can you please explain, this since the link between short flows and lower timeout has implications on the design of apps and the rationale for allowing shorter timeouts needs to be justified. 
- The present text suggests no minimal timeout. To me this seems a very odd permission, that could likely result in compliance NAPTs that are unusable. I think this needs to be discussed.
---
Section 2.2
“When a connection request is received with a four-tuple that is in the TIME-WAIT state, the connection request may be accepted if the sequence number or the timestamp of the incoming SYN segment is greater than the last sequence number seen on the previous incarnation of the connection.”

- I’m not sure I understand the term greater, is the sequence number not a modulo number space, hence any sequence number is greater - at least unless you specify a range of acceptable values.
---

“This document specifies that a NAT device should keep TCP connections in TIME_WAIT state unless it implements the proposal described in the following sub-section.”

- This seems like an Upper Case SHOULD??
---

Section 2.2.1
- I am not keen on “proposing” things in standards track documents. To me the document should “allow” this mode, or find other language.
---
“PAWS” 
- needs to be defined, supply RFC please.
---
“To make these mechanisms work, we should concern the case that there are”
-please avoid the word “should” here, maybe the intention is to say “we consider”
---
“These mechanisms are optional.”
- This seems like defining requirements compliance, please use Upper Case “OPTIONAL”.
---
“Rewrite timestamp and sequence number values of outgoings packets at NAT”
- insert /a/ before /NAT/?
---
“When packets come back as replies from remote hosts, NAT rewrite again”
- /as replies/as responses/ 
- /NAT rewrite AGAIN/the NAT again rewrites/
---
Section 2.2.1.2
“Adopt following mechanisms at NAT.”
- Suggest /A NAT performs the following mechanisms:”
“unless there is unassigned port left.”
- I don’t understand the intended meaning of this clause.
---
“Packets from other clients which are not”
-/which/that/
---
“ In the case the remote TCP”
- insert /host/ after /TCP/
---
“This mechanism MAY be used when clients starts closing process”
- Suggest: “Clients may use this mechanism when closing a connection”
---
“the behavior of remote host”
- insert /the/ before /remote/
---
“since NAT may reuse”
- insert /the/ before /NAT/
---
“ does not try standard”
- insert /to/ after /to/
---
“delete the sessions”
- /sessions/ to /session/
---
“This known as EDM”
- insert /is/ after /This/
---
“The mechanism below MAY be one optional implement to NAT”
- This sentence seems mangled. Is it sufficient to state /The mechanism below is OPTIONAL to be implemented in a NAT/
---
“destination port) .”
- remove extra space before “.”.
---
“which enables NAT to work correctly in IP”
- suggest “which allows a NAT to process packets correctly in an IP”
---
“Address Pooling Paired behavior for NAT is recommended in previous documents but behavior when a public IPv4 run out of ports is left undefined”
- Suggest: “The Address Pooling Paired behavior for NAT was recommended in previous documents, but the behavior when a public IPv4 runs out of ports was left undefined.”
---
Replace “knob’ with a more generic term, e.g., configurable parameter
---
“In order to handle this, when possible there MUST be strict filtering checks in the inbound direction.”
- This seems like a contradictory requirement. MUST means always, it can’t mean always, except when you can not. That’s SHOULD. You can strongly recommend that people perform filtering and then state SHOULD.
---
“on a per application basis. ”
- What does this really mean? DO you mean per well-known port? or do you mean per 5-Tupple or what? - This is not clear.
---
Section 6.
“ This document specifies that EIF mappings SHOULD be protocol independent in order allow inbound packets for protocols that multiplex TCP and UDP over the same IP:”
- This seems like a fairly substantial recommendation, has this been confirmed on the list.
---
“This document clarifies that EIM mappings SHOULD be protocol dependent .”
- Remove extra space before “.”.
---
“A NAT devices MAY disable port parity preservation for dynamic mappings. Nevertheless, A NAT SHOULD support means to explicitly request to preserve port parity ”
- remove /devices/
- Is this global switch for all sessions? 
---
Section 12
“are to be maintained by NAT device. ”
- insert /a/ before NAT. Remove /device/?
---
“However, RFC doesn't discuss about the”
- /RFC doesn't discuss about the/ to /This RFC does not discuss/
---
There appear to be more security-related topics than identified in the security considerations section. 
- Maybe add a note here that these will be added in future revisions?
---
FLOWRATE reference
- appears to be missing detailed of where this was published. Please add.
---
TCPWILD reference
- appears to be missing detailed of where this was published. Please add.
—

QUESTIONS TO LIST:

Two terms are in use within the standards community. This document uses the term NAT, but does not refer to NAPT - It seem stop me that the document may actually be discussing NAPT. Is this true?

In section 2 the document describes reception of a RST, etc. It would be really nice if at some point the document reminds the reader that all packets received need to be verified that they belong to a connection, and therefore are not off-path attacks.

“This document further acknowledges that most TCP flows are very short	
(less than 10 seconds) [FLOWRATE][TCPWILD] and therefore a partially	
 open timeout of 4 minutes might be excessive if security is a	
concern.  Therefore, it MAY be configured to be less than 4 minutes	
in such cases.”

- Can you please explain, this since the link between short flows and lower timeout has implications on the design of apps and the rationale for allowing shorter timeouts needs to be justified. 

- The present text suggests no minimal timeout. To me this seems a very odd permission, that could likely result in compliance NAPTs that are unusable. I think this needs to be discussed.

Section 6.

“ This document specifies that EIF mappings SHOULD be protocol independent in order allow inbound packets for protocols that multiplex TCP and UDP over the same IP:”
- This seems like a fairly substantial recommendation, has this been confirmed on the list.