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

[🔓Dan Wing <[e-mail]>]

On 21-Mar-2015 07:10 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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”

Don't all these same things apply to stateful NAPT64 (also known as RFC6144's Scenario 1, "an IPv6 network to the IPv4 Internet" and its Scenario 5, "an IPv6 network to an IPv4 network").

-d


> ---
> 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/


2.2.1 uses the term "active close" and shows FINs.  Does it also work with RST?   I had understood that a lot of browsers enjoy sending RSTs rather than a proper FINs.





> ---
> 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.


I think 2.2.1.2 is referring to port range NAT (where each user is given ports within a range), which Chris Donley popularized as "deterministic NAT".  Not sure.  It would be good if the I-D could use existing terminology, if such exists.

-d


> ---
> “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.”

Yes, please.  As Gorry suggests here, it would be best if the document made clear if it is changing existing standards, re-stating them, or clarifying something that was ambiguous.  Gorry's suggested wording seems to strike the right balance.


> ---
> 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.

It is impossible to do adjust endpoint-independent filtering on a per "application" basis.  We lack a definition of "application", for starters.

Further, it is not the purpose of a NAT (or NAPT) to perform security functions for the host.  That is a firewall function.  Is the IETF ready to go there, and discuss filtering that is appropriate in network devices?   This has caused long discussions in the past.  We can certainly do it again.  But we should start with much more precise wording.  As written, there is no way to build two compatible implementations of NATs -- which was the original purpose of BEHAVE to reduce this sort of wiggle-room so that applications could have better expectations of NAT behavior.  If it's a free-for-all with knobs and settings and application identification, we are not improving interoperability.

Applications are harmed by the restrictions to endpoint-independent filtering in Section 5.  This harm needs discussion on the mailing list and in the I-D.  This harm is real, and we do not want to encourage breaking WebRTC (which this would) or breaking other upcoming peer-to-peer applications (such as cooperative peer-to-peer caching which is ongoing research), or breaking QUIC.  The 'security attacks' are also not specified; are those against the NAT or  the endpoint?  If against the endpoint, we don't really want to say that endpoints need NATs to provide filtering?



> ---
> 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 11 says:

"11.  IP Identification (IP ID)

   A NAT SHOULD handle the Identification field of translated IPv4
   packets as specified in Section 9 of [RFC6864]."

Please add a discussion on the scalability and attack vectors of complying with this SHOULD.

-d


> ---
> 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.
> 
>