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

[[e-mail]]

Hi,

Few late comments on the use of ECN Nounce since it's now 
being considered for standards track RFC... 

The level of security provided by ECN nounces is very weak. 
Since only 4 bits are now available in the TCP header, the 
price (25%) to be paid for such a weak form of security is 
too high. 

Although it's good for a TCP sender to know if the receiver 
is cheating, there is nothing *useful* that a TCP sender can 
do in response to that. I enlist a few policies and describe 
the threat models based on these policies. The draft does 
not provide any policies, but without a useful policy there 
is no point in using ECN-Nounces. Regardless of what policy 
is used, in at least 50% of the attempts, It will work to 
the advantage of an attacker. (Please let me know of other possible policies) 

Lets say Alice (TCP receiver) wants to communicate with Bob (TCP sender), and Trudy (the intruder) is an attacker. 
Following are a few of the possible policies (and the 
associated threats) that bob can use when the nounces fail 
to match:

Policy-1:    Don't do anything after nounce failed to match; 
just wait for real loss to trigger congestion control. In 
this case, nounces are not needed. This is the default TCP 
behavior and it's by default unfair.

Policy-2:		Half the congestion window. This superficially 
sounds like the right policy, but in reality it's as bad 
(unfair) as Policy-1. Trudy can exploit this policy to deny 
services to Alice. 

Let's say Trudy can somehow snoop packets that are destined 
to Alice (If Trudy and Alice are on the same LAN, then it's 
a piece of cake ...). If Trudy were to be a passive attacker, she can construct the ACK for packets destined to 
Alice and deliberately set a random value for the nounce and 
send it back to Bob. Since there is 50% chance that this ACK 
is wrong, Trudy can force Bob to reduce data rate for Alice 
50% of the time. Please note that if Alice uses delayed 
ACKs, then Trudy will have enough time to send her fake ACK 
before Alice can send. In addition, Trudy knows that 
alternate ACKs are delayed, and she can try to 
synchronize her attacks.

If Trudy and Alice are both communicating with Bob, 
Trudy can benefit from the reduced resource usage(so it's 
more than just having fun). Trudy's congestion window will 
always be bigger. So ECN nounces don't prevent any unfairness in this case--except to a dumb attacker.

If Trudy were to be an active attacker, she can construct 
the real nounce, and deliberately send an ACK with a wrong 
value of Nounce. This is worse than Policy-1 and 
definitely worse than a passive attack. Please note that by 
induction one can prove that any such policy will work to 
the advantage of the attacker in *at least* 50% of cases. 

Policy-3:		Start with Policy-2 and if you detect too many duplicate ACKs, then go back to Policy-1. Well, this policy is no better than Policy-1. An overzealous Alice can send duplicate ACKs to enter Policy-1.

I guess the threat model assumed in this draft is that the attacker is stupid and does not have much resources. But historically, this assumption has been found to be wrong. Attackers are far more sophisticated in most of the cases (Imagine Trudy sending a Trojan horse/worm to a Yahoo employee who inadvertently replicates this on all the web servers. Trudy can then deny access to anyone who wants to access Yahoo web sites, since the worm will be able to snoop all packets as it's sitting right on the web server. This may sound harder than it really is... In addition, Trudy can 
her self be that employee... Trudy can send a worm to sit on multiple users on the internet, and selectively attack some users... It will be nightmare to identify the attacker)

I do understand that there isn't much one can do 
with a one bit nounce, but if we cannot do much, we should 
not do it at all. In addition, it's possible to have a cryptographically safe TCP communication without having to change anything in the TCP header (or by adding one bit to indicate that the meaning of sequence numbers are not the same traditional meaning). If we are willing to change the 
meaning of sequence numbers (the connection setup will still be robust) of the SYN and SYN|ACK packet, then Alice and Bob can do a key exchange using the SYN and SYN|ACK as key-
generator token fields in the packets and use the key to 
both authenticate/encrypt/sign (these cookies are 
essentially signing the message) the sequence numbers/TCP 
header. I am not going elaborate the details of the protocol 
here, but it can easily be done (I am not clear about the 
value added by doing this though...)


I would also recommend that IP-Sec working group should 
take a look at this draft. To me 50% security at the cost 
of 25% usage of TCP header bits is too much price to pay 
for.

I however don't see any problems with ECN-Nounces if TCP 
uses some TCP option to carry them. Please note that the 
nounces can also be carried by changing the meaning of NOP. Essentially the NOP will not be the string 0000 (or 
whatever it is right now), but it will be a cookie sent by 
the server (the attacks remain the same, but the precious bit finds a Shrek...).

Thanks
--Yogesh


> -----Original Message-----
> From: ext Mark Allman [mailto:[e-mail]]
> Sent: Wednesday, December 11, 2002 10:07 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Allison Mankin; Scott Bradner
> Subject: [Tsvwg] Re: Last Call: Robust ECN Signaling with Nonces to
> Experimental
> 
> 
>  
> Folks-
> 
> I asked a couple of questions about why this document is slated for
> experimental earlier today.  After some useful discussion I was
> asked to state my opinion on this matter in public (for the record
> and for others to shoot at, I presume).
> 
> > The IESG has received a request from the Transport Area Working
> > Group Working Group to consider Robust ECN Signaling with Nonces
> > <draft-ietf-tsvwg-tcp-nonce-04.txt> as an Experimental Protocol.
> 
> I think this document should go forward as a proposed standard
> rather than experimental.
> 
> I see the role of experimental as for things that we are just not
> sure about.  The recent byte-counting I-D is a good example.  From
> everything we know about it, consensus seems to be that it should be
> OK.  But, it seems to me that the change is non-trivial enough and
> the direction of the questions are in the behavior of TCP in shared
> networks and what sorts of effects the change will have on traffic
> patterns.  So, going through a period of experimental status seems
> fine and prudent to me.
> 
> But, it seems to me that the ECN nonce is pretty straightforward.  I
> have good confidence that it will not fail in ways that are unsafe
> to the global network.  Of course, there is always the possibility
> of unforeseen interactions, but my own opinion is that the nonce is
> ready for proposed standard (which is not a full standard and we can
> still tweak things later).
> 
> allman
> 
> 
> --
> Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 
_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg