Re: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to Experimental

[Mark Allman <mallman@grc.nasa.gov>]

Yogesh-

> > The nonce prevents receivers from lying and protects the network
> 
> I don't buy this:
> 
> If users want to lie, they don't need to first send a ECN-setup
> SYN and then later start cheating. They have a simpler option: Not
> to send ECN-setup at all.

This case is not "cheating".  Everything is still congestion
responsive in this case.  The cheating that the nonce prevents is
when the receiver can conceal a congestion indication from the
network.

If you don't setup ECN then your packets will not be marked, but
rather dropped -- which means either you have to tell the truth
about congestion or you don't get all your data (if you ACK
something that has not arrived).  I don't think the incentive for
covering up congestion is there in the non-ECN case.

> A cheating TCP receiver is a malicious user (if not a third
> party), and 1 bit nounce can only protect in 50% of the cases.
> That's why I said the security is weak--it's weak even for the
> problem it's trying to solve--not because it cannot protect TCP
> from all possible attacks. I know people have difficulty getting
> good security with even 2048 bits or more...

This is FUD.  The nonce is *much* better than 50%.  You have a 50%
shot at guessing the nonce right on every ACK.  But, if you guess
wrong once then the sender is on to you -- so, the probability of
guessing right is 0.5^N (where N is the number of ACKs
transmitted).  So, clearly as the connection progresses and N grows
large the probability of keeping your game going gets pretty small
pretty quickly.

> Tomorrow if we need those bits for some functionality (instead of
> for protection), the only option would be to have a new
> transport layer protocol.

(Actually, when we run out I am sure that the first thing that will
happen will be someone generating an RFC defining a TCP "more bits"
option.) 

> BTW, just curious to know if someone's designing a protocol
> police=20 to ensure that TCP senders halve their data rate after
> packet loss. To the best of my knowledge, TCP receivers are not
> the only ones who are capable of cheating; even TCP senders can
> cheat. Just curious know.

TCP senders could be an even bigger problem -- because they Just
Control the sending rate (i.e., they don't need manipulative tricks
like the reciever does).  See some of the ICIR/AT&T work on
pushback.  Or, Sally Floyd and Kevin Fall's notion of a penalty
box.

allman


--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/