Subject: Re: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00

From: "Tom Petch" <[email-masked]>
Date: Tue, 16 May 2006 15:32:01 +0200

I looked, took a few Paracetamol, looked some more and still think this is not
fit to advance; it is or is likely to be incomprehensible to many intended
readers.

Not surprisingly, then, I find it hard to give specific, tcp-technical reasons
why -  eg REQ-3 is wrong because it does not take cognizance of para x in
RFCyyyy; rather, it is the 'first impressions count', the look and feel that
convinces me that this I-D is not fit.

First page and there are too many editors for the RFC Editor's liking.  Move on
to  'Applicability' and it is very clear: 'Application and OS aspects of  TCP
NAT traversal are out-of-scope'; but wait for section 6,
"6.  Application Level Gateways
   FIXME OPEN ISSUE: Is this out-of-scope?  Do we need to specify all
   TCP ALGs should be off by default?  What about FTP?"
(good questions).

The document is written in an unfamiliar (to me) language of NAT-specific
technical terms, for which the reader is referred to FIXME-BEHAVE-UDP (sic)
which is in fact draft-ietf-behave-nat-udp-06 (the subject of recent criticism
on the main IETF list).  This has a poorly laid out section on Terminology which
urges the reader
"to refer to RFC 2263 [8] for information on NAT taxonomy and terminology"
(in passing, RFC2263 is SNMP Applications from one of the abortive starts on
SNMPv3) and ends with comments that the terminology from RFC3489 {STUN}
"has been the source of much confusion as it has proven inadequate..."
(yes, feels about right).  In between, this section makes no mention of several
of the terms in use (eg Address and Port Dependent Mapping) so the reader of
behave-tcp must read and digest behave-udp (and RFC2263) before starting.

A simple example on terminology; these I-D take terms like internal and external
for granted; well yes, I can deduce what they mean but what is internal to an
ISP is not internal to an ISP's customer and vice versa; it would be so easy to
make the meaning clear (like, a diagram).

This I-D has normative references to NUTSS and NATBLASTER in the shape of
SIGCOMM  Proceedings which suggests to me that the intended audience is rather
esoteric.

As I said, none of this is hard, tcp-related reasons why I regard this I-D as
unfit to advance but I think it does give the flavour.

I note that the only reference to TCP is to RFC793, which, great as it is, is
not the TCP used in most sessions today (are the editors aware of this?).  The
I-D should at least reference the recent Roadmap and say whether or not the many
later additions to TCP are relevant to NATs or not.

Overall, I think that behave is on the wrong track; this I-D reads like an
afterthought tacked onto UDP-related work by someone keen on gaming.  Rather,
they should first produce an update to RFC2263 on NAT in general, with clear
concepts and related terminology, and then produce separate I-D for UDP and TCP
(and DCCP and STCP and etc etc) which refer back to this common work.  The idea
that someone concerned with TCP should first become a master of UDP and NUTSS
is, well nuts:-)

Tom Petch

----- Original Message -----
From: "Mark Allman" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 18, 2006 3:54 PM
Subject: Lars Eggert: [tcpm] draft-ietf-behave-tcp-00

>
> Folks-
>
> Lars sent the attached request a few weeks back and we haven't heard
> anything.  Could a couple of folks volunteer to take a look at this
> document in the next week or two (it's pretty short)?
>
> (And, send along a note to me indicating that you intend to do so, else
> I'll have to try to poll people specifically.)
>
> Thanks!
>
> allman
>
>
>
>

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

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2006 18:12:18 +0200

Tom,

thanks for the review! I forwarded your review to the behave list,  
where any follow-on discussion should take place (in case other TCPM  
folks would like to participate).

Lars

-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 May 2006 14:26:16 -0700

I took a look as well. I agree with Tom's assessment: it doesn't stand 
as a readable document.

I also agree with Tom that:

1. this doc should start with the TCP roadmap as a reference, and should 
address items in there specifically (at least the basic ones, if not the 
recommended ones).

2. this doc should be more stand-alone regarding terminology

---

I'll be more specific than Tom as to TCP-technical errors:

- some of the scope declarations in section 1 are inappropriate.
	this document must declare the limit to which TCP headers can be
	interpreted in their entirety. declaring that anything not
	related to translation of TCP is out of scope begs the question
	of what's related to that translation - options? modification
	of the number of segments (e.g., splitting)? these are all
	definitely in-scope.

	I agree with the doc that above-TCP, below-TCP, and signalling
	beyond IP and TCP can be declared out of scope.

- REQ-2 is overstated; a NAT MUST support translation of any
	packet valid in a pending TCP session, where "pending TCP
	session" is initiated by an outbound TCP SYN

	that means a NAT MUST accept incoming TCP SYNs which match
	current pending sessions. this supports simultaneous open
	*if* after the session is initiated by an internal host

- REQ-3 is incorrect

	TCP defines sessions, sessions are defined by socket pairs,
	and sockets are defined by IP address/port pairs. Period.

	TCP port numbers do NOT identify hosts; they identify
	session demultiplexing points on hosts. To that end, the NAT
	is an early, remapping point for that demuxing, where everything
	behind a NAT (assuming it has only one external IP address)
	functions _exactly_ as if it were on a single host with that
	address.

	That also means that transmissions that differ in any of
	source IP, destination IP, source port, and destination port
	are unrelated from TCP's point of view. It is inappropriate
	for this document to suggest otherwise, or to suggest use
	of a NAT for that purpose. While other documents can refer to
	such 'NAT tricks', this document, from TCP's perspective, should
	recommend against such tricks, IMO.

- REQ-4 is incorrect

	First, the ways in which a NAT would respond to a
	TCP SYN not matching a pending session should be listed,
	e.g., ICMP dest unreachable (3 port unreach, 10 host admin
	unreach) or TCP RST.

	The document is written assuming the desire to support
	simultaneous opens, but ignores the desire to know more
	rapidly when a port is not available. In particular, when
	an ICMP dest unreach/3 port unreach is issued, that would
	be a hard error that would cause the external TCP to quickly
	abort. Not sending the error would impact those hosts and
	cause them to respond less quickly to connection failure.

	While I agree that simultaneous open MUST be supported for
	pending sessions, I disagree that external SYNs should always
	be silently discarded just to support simultaneous open. While
	simultaneous open is OK when it works, the whole notion of a
	NAT is counter to incoming, unsolicited connections.

	I would recommend that incoming SYNs that do not match pending
	sessions MAY be signalled by an ICMP or RST error. I would NOT
	recommend that silence be required.

- regarding ALGs
	FTP is not a relevant issue; FTP is already supported through
	NATs by passive mode; there is no requirement to translate the
	body of an FTP session to support NATs. There are other ALG
	issues, but they are - as noted in Sec 1 - above TCP, and not
	relevant to TCP.

- session refresh
	This section is too messy. TCP can be open and silent if
	neither side has pending data; this must be addressed.
	Discarding state might allow subsequent sessions from other
	hosts to inadvertently receive data from other hosts'
	connections; this is a hazard that MUST be discussed.

	NATs may typically send keepalive TCPs, but *this* document
	should recommend that such behavior be restricted to endpoints.
	This document should be VERY clear on when such state should
	be kept, for how long, and when it can be cleared. The NAT
	must keep state in TIME_WAIT just like any end host to avoid
	reuse of connections and crossed-data. This section is the
	most critical of this document, and currently is both
	too disorganized and incorrect to proceed.

- IPsec is missing
	since IPsec examines TCP headers, it would be useful to address
	IPsec/TCP combined issues here (e.g., transport mode issues)

I didn't bother with addressing the security considerations, given the 
errors above. I'm presuming that a thorough revision of that section 
would be needed, since the doc missed some very obvious issues IMO (above).

Minor nit: 6 authors? from a WG? pick a subset who are editors, please

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 May 2006 14:35:07 -0700

>     *if* after the session is initiated by an internal host

Sorry - minor typo.

This should read "*if* (and only after) the session...

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 May 2006 15:50:21 -0700

Fernando,

This is a very useful and well-written document. I worked
through all of the attack scenarios and recommended
mitigations in detail and found no major problems. The
citations of fielded deployments in major operating
systems added further strength to the recommendations.

Below are the observations I found. They are mostly minor
in nature, and could go as AUTH48 if the document has
already advanced to that stage. I believe this document
is ready for advancement as an RFC.

Fred
[email-masked]

1) Section 1, first reference to the term "blind", perhaps
   add a few words by way of definition so that the term
   is clearly understood throughout the rest of the document,
   e.g., "which include blind (i.e., ...) connection-reset".

2) Section 2.1, second paragraph, first sentence. The term
   "source host" may be too limiting because the source
   could also be an in-the-network tunnel encapsulator at
   a router. Suggest changing to "source system" or simply
   "source". Check also for other occurences of "source host"
   or "sending host" throughout the document.

3) Section 2.1, second paragraph, last sentence. Change:
   "handled to" to: "handed to".

4) Section 2.1.2, first sentence. Change RFC2463 to RFC4443
   here and elsewhere throughout the document.

5) Section 2.2, fourth paragraph, first occurrence of the
   term "four-tuple" should be expanded to tell exactly what
   is meant by "four-tuple", i.e., (src, dst, sport, dport).

6) Section 3, fourth paragraph, possibly change: "signing
   its segments by means of the TCP MD5" to: "signing its
   segments, e.g., by means of the TCP MD5". I leave this
   one up to your judgement.

7) Section 3, sixth paragraph, change: "Current levels of
   deployment of protocols" to "Current levels of protocol
   deployment".

8) Section 4.1, first paragraph, change: "to destination"
   to: "to the destination".

9) Section 5.1, first paragraph, change: "is handled" to:
   "is handed", or: "handles".

10) Section 5.1, second paragraph, change: "[RFC1122]" to:
    "([RFC1122], Section 4.2.3.9)". Also change other
    critical RFC citations to cite specific sections
    throughout the document to give readers clear direction.

11) Section 5.2.1, under "ICMPv6 type 1...", change:
    "Therefore, TCP should" to: "Therefore, TCPs in
    synchronized states should".

12) Section 5.2.1, last sentence, change to: "The Linux
    kernel has also implemented this policy for more than
    ten years [Linux]."

13) Section 7.1, end of first paragraph, strike the
    citation of [RFC1191], and join paragraphs 1 and
    2 together to make for a more unified introduction
    to path MTU discovery.

14) Appendix A, Section A.2, need to tell what MAXSEGRTO
    is set to for the purpose of the example.

15) Appendix B, under "maxsizeacked" and "maxsizesent",
    change: "so for" to: "so far" in both places.

16) Appendix B, under "MINIMUM_MTU", add close-paren ")"
    to end of sentence.

17) Appendix B, end of pseudo-code under "Notes:", add
    paragraph break after: "...sequence number arithmetic."

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 May 2006 02:24:52 -0300

Thanks!

You'll find my comments inline (I skipped some,that I will also 
adress in teh next revision of the draft).

>    e.g., "which include blind (i.e., ...) connection-reset".

Okay. Will do.

>    or "sending host" throughout the document.

Good point. Will do.

[....]
>    here and elsewhere throughout the document.

Yep. Found about this revision not that long ago. Will do.

>    is meant by "four-tuple", i.e., (src, dst, sport, dport).

Okay. Will do.

>    one up to your judgement.

Very good point. For instance, a few weeks ago I posted some feedback 
on Ron Bonica's draft regarding this issue. The same idea applies 
even if the actual algorithm to sign the segment is different from MD5.

>     throughout the document to give readers clear direction.

Good point. Will do.

>     synchronized states should".

Good grief! Will do.

>     is set to for the purpose of the example.

See the introduction of Appendix A. It says that for all the 
following examples, MAXSEGRTO is set to 1.

>     change: "so for" to: "so far" in both places.

Oops!. Will do.

>     paragraph break after: "...sequence number arithmetic."

Will do.

Thanks so much for your very *very* detailed feedback!

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 May 2006 02:24:52 -0300

Thanks!

Okay. Will do.

Good point. Will do.

[....]

Okay. Will do.

Good point. Will do.

Good grief! Will do.

Oops!. Will do.

Will do.

Kindest regards,

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 19 May 2006 08:59:51 -0700

Fernando,

> following examples, MAXSEGRTO is set to 1.

OK, I see it there now; looks fine.

Fred