Subject: [Tsvwg] ECN - some fixes requested by IESG

From: Allison Mankin <[email-masked]>
Date: Thu, 17 May 2001 17:35:34 -0400

ECN authors:

Here are some issues with draft-ietf-tsvwg-ecn-03.txt (going to
Proposed) that the IESG identified last week and today.  Once fixed, 
the draft will go forward.  

About A.2 - is this mostly unclarity of language in the draft?
One way of reading what's there is that you require that all 
uses of ECN at tunnel endpoints do limited-functionality, and
if policy allows, then they do full-functionality.  This would
imply that all implementations be capable of both.

Allison

-----------
A.

1. 5-tuple reuse when B is in TIME-WAIT and A is in CLOSED.
What is the scope of the text in section 6.1.1 starting with
   The following rules apply to the sending of ECN-setup packets:
The text refers to multiple SYN and SYN/ACK packets for the same
"connection" and the question is what identifies a connection.
The reason for my question is that many/most implementations
handle in-window SYN packets in time-wait by creating a new
connection, even though I don't think this is specified in any RFC.

The first connection for the tuple
might have a non-ECN-setup SYN but the second connection using
the same 5-tuple might want to use ECN.
Do we want the ECN properties to carry across from the old
connection using the same 5-tuple?)
Or should the ECN state be forgotten when transitioning to time-wait?

2. Section 9.1.1:
      (1) An IP tunnel MUST modify the handling of the DS field octet at
      IP tunnel endpoints by implementing either the limited-
      functionality or the full-functionality option.
and Section 9.2:
   All IPsec
   implementations MUST implement either the limited-functionality or
   the full-functionality alternative in order to eliminate
   incompatibility between ECN and IPsec tunnels, but implementers MAY
   choose to implement either alternative.
I think in the interested of interopearbility (tunnel endpoints from different
vendors) we should make the requirement stronger. Either require that all
implementations support one, or require that all nodes support decapsulation
as both limited and full-functionality so that the encapsulators can do either.

Nits:

The "obsoletes RFC 2481" is hidden deep inside the introduction.
At a minimum we should tell this explicitly to rfc-ed.
It might also make sense to add it to the abstract.

The document treats IPv4 and IPv6 identically (good) but it
doesn't explicitly mention the impact of IPv6 not having a header
checksum. However, section 8 and 18 specify the implications of malicious
modification of the ECN field thus the protocol is presumably capable of
handling undeteced bit errors in the ECN field. But it would be good
to mention this in the document.

In section 12 it says 
>   When ECN (Explicit Congestion Notification [RFC2481]) is used, [...] 
which must be a leftover from merging multiple drafts. ECN is specified 
in this document as 2481 is the old experimental stuff which presumably 
shouldn't be referenced in this context. 

Section 18.2 says "In the case of IPsec tunnels, the IPsec
   tunnel protects the transport header." when in fact IPsec, both tunnel
and transport mode, provides this protection.
Thus this might be better "In the case of IPsec being used, ESP and/or AH
protects the transport header."

Section 18.3 says "this is not a reason to disable ECN within an
   IPsec tunnel." I don't understand what this has to do with IPsec.
Shouldn't the last 4 words be dropped?

B.
-----------
During the transition from 00 to 01, the drfaft lost
its references to the fact that some middleboxes (firewalls,
intrusion detectors) filter or cause a RST to be sent (spoofed)
when the TCP SYN arrives with bits indicating it is ECN-capable.
The IESG requests that information (and workarounds) to be in
this spec.

1. 
Add back the section and put a forward pointer to it (mentioning
firewalls and other middle box issues) in the introduction.

2.
Move down all the sections under 6.1.1.1 so that the first
section under 6.1.1 is a new one.  Here is the language that Sally
has already worked on for the new section and that the IESG
gave thumbs up to.  The IESG requests that Sally's individual draft
(draft-ietf-floyd-reset-00.txt) be aligned with the position here
The IESG's sense was that a new SYN without ECN bits 
was an appropriate workaround to receiving RST to a SYN sent with
ECN bits.

6.1.1.1.  Middlebox Issues

ECN introduces the use of the ECN-Echo and CWR flags in the TCP
header (as shown in Figure 3) for initialization.  There exist some
faulty firewalls, load balancers, and intrusion detection systems
in the Internet that either drop an ECN-setup SYN packet or respond
with a RST, in the belief that such a packet (with these bits set)
is a signature for a port-scanning tool that could be used in a
denial-of-service attack.  Some of the offending equipment has been
identified, and a web page [FIXES] contains a list of non-compliant
products and the fixes posted by the vendors, where these are
available.  The TBIT web page [TBIT] lists some of the web servers
affected by this faulty equipment.  We mention this in this document
as a warning to the community of this problem.

To provide robust connectivity
even in the presence of such faulty equipment, a host that receives a
RST in response to the transmission of an ECN-setup SYN packet MAY
resend a SYN with CWR and ECE cleared. This could result in a TCP
connection being established without using ECN.  

A host that receives no reply to an ECN-setup SYN within the normal
SYN retransmission timeout interval MAY resend the SYN and any
subsequent SYN retransmissions with CWR and ECE cleared.  
To overcome normal packet loss that results in the original
SYN being lost, the originating host may retransmit one or more
ECN-setup SYN packets before giving up and retransmitting the SYN
with the CWR and ECE bits cleared.

We note that in this case, the following example scenario is possible:
 
(1) Host A: Sends an ECN-setup SYN.
(2) Host B: Sends an ECN-setup SYN/ACK, packet is dropped or
delayed.
(3) Host A: Sends a non-ECN-setup SYN.
(4) Host B: Sends a non-ECN-setup SYN/ACK.

We note that in this case, following the procedures above, neither
Host A nor Host B may set the ECT bit on data packets, We further
note that a host NEVER uses the reception of ECT data packets as an
implicit signal that the other host is ECN-capable.

References:

[FIXES] ECN-under-Linux Unofficial Vendor Support Page,
URL "http://gtf.org/garzik/ecn/".
Reference for informational purposes only.

[TBIT] Jitendra Padhye and Sally Floyd, Identifying the TCP Behavior of
Web Servers, ICSI TR-01-002, February 2001.
URL "http://www.aciri.org/tbit/".

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

---

From: Sally Floyd <[email-masked]>
Date: Thu, 17 May 2001 17:06:24 -0700

>the draft will go forward.  

Many thanks.  I have made the requested changes, and should be ready
to send in the revised version of the draft as soon as I
hear back from my co-authors.

- Sally

>imply that all implementations be capable of both.

We didn't say that all IPsec tunnel implementations should support
limited-functionality mode for interoperability reasons, and we
should have.  I have added it.

I am also adding something saying that once TCP enters
TIME-WAIT state, it ignores any previous state about the ECN
status of the connection.