Subject: [BEHAVE] Re: SecDir review of draft-ietf-behave-tcp-05

From: Saikat Guha <[email-masked]>
Date: Wed, 21 Mar 2007 17:50:29 -0400

Thanks Pasi for the SecDir review of behave-tcp.

Comments inline reflect authors consensus. 
Bringing to the list for additional discussion.

On Mon, 2007-03-05 at 14:25 +0200, [email-masked] wrote:
> 1) The document does not seem to mention rewriting of TCP sequence
> numbers, which some NATs do. Among other things, this can break
> SACK (unless the SACK is also rewritten). Perhaps this issue
> should be mentioned, and possibly some recommendation given?

This issue, while a valid concern, is out-of-scope of this document. The
scope currently states "Middlebox behavior that is not necessary for
network address translation of TCP is out-of-scope". NATs are not
_required_ to rewrite TCP Seq# for TCP translation. 

Of course NATs that do have this feature (presumably to hide hosts from
stack fingerprinting etc.) must implement it correctly w/ or without
SACK. AFAIK there is no non-determinism involved in a correct
implementation of such a feature that needs to be resolved making this
concern out-of-scope.

> 2) When a NAT decides to abandon state for a TCP connection (due to
> "established connection idle-timeout", or simply as alternative to
> blocking new connection attempts), it can do so silently, or it can
> try to notify the endpoints (by sending RSTs or something).  Should
> the document have some discussion about the desirability (or
> undesirability) of these alternatives?

Agreed. Notification of abandoned connections is left unspecified (as
per discussion on this list sometime back) since applications cannot
depend on them anyway (failstop NAT crash, packet loss etc). We propose
adding the following text to the end of Section 5 to put that in
writing.

----8<--------------

   NAT behavior for notifying endpoints when abandoning live connections
   is left unspecified.  When a NAT abandons a live connection, for
   example due to a timeout expiring, the NAT MAY either send TCP RST
   packets to the endpoints or silently abandon the connection.  Sending
   a RST allows endpoint applications to recover more quickly than
   silently abandoning the connection because in the latter case the
   detection of the error is postponed to the next time the application
   attempts to communicate over the abandoned connection.  However, as a
   NAT may lose session state due to software and hardware faults,
   applications cannot rely on such notifications.

----8<--------------

cheers,
-- 
Saikat
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Thu, 22 Mar 2007 10:21:28 +0200

Saikat Guha wrote:

> This issue, while a valid concern, is out-of-scope of this
> document. The scope currently states "Middlebox behavior that is 
> not necessary for network address translation of TCP is
> out-of-scope". NATs are not _required_ to rewrite TCP Seq# for TCP
> translation.

No, but for translation of TCP to work, NATs are required to handle
sequence numbers in correct fashion (just like NATs are required to
handle TCP state machine correctly, REQ-2). 

I think prohibiting behavior known to break TCP, which is known to be
implemented by some NATs, should be in scope.  NAT implementors may
not realize that incorrectly implemented seq# rewriting actually
breaks things... and even if SACK is handled correctly, it breaks the
ability to add certain kinds of options to TCP later. So actually
NOT rewriting TCP seq# is required for future-proof correct 
translation of TCP.

IMHO this document should alert NAT implementors that seq# rewriting
is difficult to implement correctly today, and impossible to implement 
correctly in a future-proof way. I'm not suggesting any extensive
changes; 
five lines or something should be quite enough.

Best regards,
Pasi

---

From: Saikat Guha <[email-masked]>
Date: Sun, 25 Mar 2007 20:40:26 -0400

> handle TCP state machine correctly, REQ-2). 

Fair enough. ALGs aside, not supporting SACK when the NAT is munging
seq# for privacy reasons can be viewed as an information leak.

Perhaps adding the following sentence to the security section would
help:

  "NAT implementations that modify TCP sequence numbers for privacy
   reasons or ALG support must ensure that TCP packets with SACK
   notifications are properly handled."

Thoughts?

cheers,