Re: [tcpm] ECN+SYN

Sally Floyd <> Thu, 21 February 2008 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0335028C6F4; Wed, 20 Feb 2008 17:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tOm-G9NKIFat; Wed, 20 Feb 2008 17:49:55 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 001D63A6B54; Wed, 20 Feb 2008 17:49:54 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECB653A6BD1 for <>; Wed, 20 Feb 2008 17:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1TsfnuT2iBDR for <>; Wed, 20 Feb 2008 17:49:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DF7DA3A6B54 for <>; Wed, 20 Feb 2008 17:49:51 -0800 (PST)
Received: from (asmtp001-s []) by (Xserve/smtpout005/MantshX 4.0) with ESMTP id m1L1nm94000125; Wed, 20 Feb 2008 17:49:48 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (Xserve/asmtp001/MantshX 4.0) with ESMTP id m1L1nhTL023814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2008 17:49:44 -0800 (PST)
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <>
From: Sally Floyd <>
Date: Wed, 20 Feb 2008 17:49:44 -0800
To: Stefanos Harhalakis <>
X-Mailer: Apple Mail (2.753)
Subject: Re: [tcpm] ECN+SYN
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefanos -

- Sally

>   I've just read the proposal regarding ECN and SYN/ACK packets and  
> I cannot
> understand why not to allow ECN in SYN packets too. Let me  
> elaborate a bit
> further:
>   In paragraph 4, page 10 you mention two reasons which I find  
> incorrect:
> *  First reason claims that there is no guarantee that the other  
> TCP endpoint
> is ECN-capable. AFAICT this is exactly the case as in ECN in SYN/ 
> ACK packets.
> I fail to see why there is a difference when "the connection"  
> looses the SYN
> instead of the SYN/ACK packet.

When a TCP initiator sends a SYN packet, the initiator does not
know if the TCP at the other end is willing to use ECN in this  

In contrast, when a TCP responder sends a SYN/ACK packet, that
responder has already received a SYN packet from the TCP initiator,
indicating whether or not the TCP initiator wishes to use ECN
with this connection.

The goal is for all ECN-capable TCP connections to be able
to deal with an ECN-marked SYN/ACK packet.  When this goal is
reached, then if the TCP responder receives a SYN packet
agreeing to use ECN for this connection, then the TCP responder
would know that the TCP initiator is able to respond properly
to an ECN-marked SYN/ACK packet.

> *  Next paragraph says that SYN packets can be missused. IMHO, this  
> is already
> possible. A malicious host can send IP packets with the ECT  
> codepoint set
> that include non-ECN TCP SYN packets, or even SYN/ECN+ECT packets.  
> There is
> no guarantee that an endpoint will drop SYN/ECN+ECT packets and I  
> believe
> there is no valid reason for having an ECN capable endpoint drop  
> packets (as being malicious).

Yep, a malicious host could set the ECT codepoint on a TCP SYN
packet now, or on any other packet, and there is no reason to assume
that an ECN-capable router would look at anything other than the
ECN field in the IP header before ECN-marking the packet instead
of dropping it.  Such concerns are discussed in Section 7 of RFC 3168,
on "Non-compliance by the End Nodes".

However, now, any host that would set the ECT codepoint on a
TCP SYN packet would be clearly violating the protocol specified
in draft-ietf-tcpm-ecnsyn-04.txt.  And this violation would be clearly
visible to any routers or TCP responder that cared to check.

Thus, at some point there could be *policers* in the network
that check to find end-nodes that are cheating about ECN and other
matters.  And such policers could easily identify cheaters that set
the ECT codepoint on TCP SYN packets (and deal with them

And a popular and busy web server *might* be configured not to
respond to TCP SYN packets from initiators that don't bother
to follow the specified protocols.

It might be that something can be misused now.  However,
that does not necessarily justify opening the door for even
greater misuse (by standardizing the use of ECT with TCP
SYN packets).

In summary, I would be *strongly* opposed to any proposal
for TCP SYN packets to be sent as ECN-capable.

>   Because of my limited experience I believe that I'm not able to  
> comment on
> reason (3) of page 22 (appendix A).
> Best regards,
> Harhalakis Stefanos
> p.s. Please excuse me if I'm wrong. I'm new in this area.

Well, you would read this email, and see what you think.

Take care,
- Sally

tcpm mailing list