Subject: [tcpm] ECN+SYN

From: Stefanos Harhalakis <[email-masked]>
Date: Wed, 20 Feb 2008 01:16:26 +0200

Hello there,

  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.

*  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 SYN/ECN 
packets (as being malicious).

  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.
_______________________________________________
tcpm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tcpm

---

From: Stefanos Harhalakis <[email-masked]>
Date: Wed, 20 Feb 2008 01:26:07 +0200

On Wednesday 20 February 2008, Stefanos Harhalakis wrote:
>   Because of my limited experience I believe that I'm not able to comment
> on reason (3) of page 22 (appendix A).

Correction:

The reason specified in the second paragraph of page 22 (appendix B) regarding 
the use of the extra bit for the ECN-SYN packets
_______________________________________________
tcpm mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tcpm

---

From: Sally Floyd <[email-masked]>
Date: Wed, 20 Feb 2008 17:49:44 -0800

Stefanos -

- Sally
http://www.icir.org/floyd/

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

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.

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

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.

> 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
http://www.icir.org/floyd/

---

From: Stefanos Harhalakis <[email-masked]>
Date: Thu, 21 Feb 2008 23:53:08 +0200

> for TCP SYN packets to be sent as ECN-capable.

Hello Sally and thank you for your detailed and explanatory reply!

(I'm replying to the whole mail as a whole)

  After carefully reading your mail a couple of times, re-examining 
draft-ietf-tcpm-ecnsyn-05.txt and having in mind RFC3168, I still believe 
that the draft should be modified a bit regarding the SYN+ECT case. For the 
rest of the mail I'm using the term ECT when referring to flags in IP packets 
and ECN when referring to TCP flags.

  First of all, partially in contrast with RFC3168, the draft indirectly 
suggests that ECT should be used in SYN/ACK packets as:
a) an improvement for detecting congestion a little bit earlier and starting 
with a reduced window size (smaller initial window) (p.8, bottom)
b) a method of QoS that will result in less SYN/ACK looses when operating on 
an ECN enabled network (p.5, bottom (2)) (p.7, top).

Point (a) has to do with ECN(+ECT) and (b) has to do with ECT. 

  Also, the draft:
a) Proposes ECT for SYN/ACK segments
b) Forbids ECT for SYN segments

  I argue that the exact same reasons specified in point (b) (regarding QoS) 
apply to SYN segments too. In fact, if you imagine an ECN enabled Internet 
that uses RED everywhere then the only dropped segments of a TCP session 
because of congestion may be the SYNs (!!). Also consider that loosing the 
first SYN of a session MAY result in a ECN-less connection (RFC3168 
6.1.1.1) - which increases its importance.

  I suggest that the draft:
a) Do not forbid ECT for SYN segments
b) Propose the usage of ECT for SYN segments

  Since on an ECN enabled Internet that uses AQM everywhere the ECN bits in IP 
will (most probably) also work as a kind of QoS, we should not consider ECT 
only as a congestion indication method. We should have in mind the effects of 
not using ECT which will result in poorer performance. I totally agree that 
most probably we will not benefit from congestion indication in SYN segments 
and I understand that RFC3168 explicitly says that "an ECT codepoint MUST NOT 
be set in a packet unless the loss of that packet in the network would be 
detected by the end nodes and interpreted as an indication of congestion" 
(RFC3168 5.2) but on the other hand, SYN and SYN/ACK segments are not exactly 
data (for normal operations) and (I believe that) they are only a very small 
fraction of the whole internet traffic (either as packet count or byte 
count).

  So, it may be wise and harmless to also propose in this draft that "when a 
host sends a SYN segment it MAY set the ECT codepoint to prevent intermediate 
routers from dropping it instead of marking it"

  Regarding security considerations: I fail to see why ECT+SYN may be a 
threat. Of course a malicious user may use it to prevent intermediate routers 
from dropping those packets but trying to prevent this:
a) Is not what we're doing everywhere else
b) Is like disallowing fast and reliable internet connections to prevent 
malicious users from performing SYN flooding.

  Hope that this clarifies my thoughts... and that they are not (totally) 
wrong :-)

Best regards,
Harhalakis Stefanos