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

[Yogesh.Swami@nokia.com]

Hello,

[Sorry about the delay in responding]

> The security concerns you mention are cetainly valid.  But, one does
> not need the nonce to exploit things if some man-in-the-middle is
> willing to simply generate ACKs indicating "congestion experienced"
> for the end receiver.  

Yes, I agree there are other ways to do DoS attacks (none of
the attacks in my previous e-mail was Man in the Middle attack
though; they are active/passive eavesdroppers). When people
are trying to orchestrate a DoS attack, they need as many DoS
vulnerabilities as possible so that they can generate an innocent
looking DoS attack-traffic that will be harder even for a human
observer to distinguish from a non-attack traffic. For example, if
a web site sees 1000 SYN packets per seconds, it can easily figure
out that the server is under attack (unless it's CNN or New York
Times's web site). On the other hand, however, if the same web 
server sees 100 false nounce, 100 ECN-experienced, 100 run-away 
SYN messages, etcetera, it cannot immediately conclude if it 
is under attack or if the receivers just happen to be on a bad 
network path...

(ECN nounce + ECN) is therefore worse than ECN alone. That's
the point I was trying to make. [I guess I was not very clear]

BTW, IPSec is not an option here. The present key exchange
protocol (IKE) takes 3-5 round-trips to just establish a shared
secret (newer protocols like JFK are better--2 round
trips--but they are still heavyweight). On top of that, the users
will have to wait for at least another 3/2 round trip before they
can see the first byte of "data." This is just not a viable option
for many servers (it would require 3 IPSec enabled servers where
one tradition TCP server would have done--by Little's  theorem
assuming short lived connections). In addition, IPSec does a whole
lot of "other things" (identity protection, non-repudiation ...)
which are not needed in most of the cases.

If we are serious about security, we should stop solving the problem
in an ad hoc manner and make TCP self-secure once and for all. Or we 
can wait until there is a spectacular attack (after which 
every web server will have a hack to prevent such attacks. Then 
we can design protocols to make these hacks work together...).  
 
> 
> And, if the penalty imposed by the sender is worse for blowing the
> nonce than for receiving "congestion experienced" then I might agree
> that the nonce allows for a bigger and better attack than without


As I said in the last paragraph, the penalty is higher because 
any non-trivial policy will open *one more* door for DOS attack.


<...>

> 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. Every operating system provides a way to
do this. Every OS *has to* provide this because there are some ultra 
smart firewalls which drop all packets with CWR bit set and never 
bother to even information the receiver with a reset. Besides, to 
cheat this way, one will need the source code of the operating system.
(If operating system vendors want to cheat, they will just not 
implement ECN, and probably even save a few pennies too) 

I am of course assuming here that packets with ECT code points
share the same network queues as traditional TCP packets 
(if they don't, then there are other related problems which 
need to be solved by DiffServ framework. I don't know all the 
details :-( ).

So, I don't see how ECN nounces are helping. The only place where 
it might help is with crazy middle boxes. But that problem is again 
a generic problem that DiffServ should solve (at IP layer)--not TCP.

> there are bugs in boxen in the network.  The nonce does not protect
> against malicious third-parties, I agree -- it was not intended to.
> But, I don't think it hurts that case either.
> 

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


If people are happy with the nounce placebo, that's fine with me.
My only suggestion is that we should not waste (I'm sorry, I could
not come with a better word) the bit in the TCP header.
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. In addition, putting the nounce in a TCP option 
is better since one can use more bits and detect cheating receivers
with a higher confidence level than 50%. I bit entropy is too little.


--yogesh


BTW, just curious to know if someone's designing a protocol police 
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.