Re: [tcpm] ECN+SYN

Stefanos -

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

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

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

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.

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm