Last Call Review of draft-paxson-tcpm-rfc2988bis-
review-paxson-tcpm-rfc2988bis-secdir-lc-meadows-2011-04-30-00

Request Review of draft-paxson-tcpm-rfc2988bis
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-04-26
Requested 2011-04-14
Draft last updated 2011-04-30
Completed reviews Secdir Last Call review of -?? by Catherine Meadows
Assignment Reviewer Catherine Meadows
State Completed
Review review-paxson-tcpm-rfc2988bis-secdir-lc-meadows-2011-04-30
Review completed: 2011-04-30

Review
review-paxson-tcpm-rfc2988bis-secdir-lc-meadows-2011-04-30

Begin forwarded message:

 I messed up the tools email address on this My apologies for the resend.

Cathy

From: 

Catherine Meadows <

catherine.meadows at nrl.navy.mil

>

Date: 

April 21, 2011 6:39:38 PM EDT

To: 

iesg at ietf.org

, 

secdir at ietf.org

, 

draft-paxson-tcpm-rfc2988bis.all at ltools.ietf.org

Subject: 

Secdir review of draft-paxson-tcpm-rfc2988bis-02

I have reviewed this document as part of the security directorate's

ongoing effort to review all IETF documents being processed by the

IESG.  These comments were written primarily for the benefit of the

security area directors.  Document editors and WG chairs should treat

these comments just like any other last call comments.

This draft describes the algorithm that a TCP sender uses to manage its retransmission timer.  The sender uses the algorithm to keep track of

round-trip times of sent packets and acknowledgements, so it can determine when a packet is likely to have been lost and needs to be resent.

As the draft points out, the retransmission timing algorithm is very important to the efficient operation of the Internet, since it is necessary for

the avoidance of congestion arising from too many re-sent messages.  Thus, it is a natural target for exploitation for a denial of service attack, in which

an attacker convinces a sender to lower its RTO to an unsafe value, causing it to retransmit its packets that are not really lost, and thus lead to congestion.

The Security Considerations section is devoted to discussing these and their potential impact, which is not considered to be great.  The main crux of the argument is that an attacker would need to be able to

spoof acknowledgements from the receiver, and if it could do this there are much more devastating attacks it could implement.

Moreover, congestion would lead to genuinely lost packets, which means that the RTO would increase.

I had some trouble with this argument, since it is rather high-level and depends on assertions that I can't verify.  On the other hand, I don't

think you should have to have a whole essay on this topic in this ID.  But I kept on asking questions as I read: how hard is it to spoof an acknowledgement?  What information would the attacker need to know about the packets in the connection?

If the sender backed off once a packet was genuinely lost, how hard would it be for the attacker could bring the RTO down again?  What if the attacker were applying this attack to multiple senders.  Are there cases in which an attacker could spoof an acknowledgement without

having actually have seen a packet?

These questions may have obvious answers to people who are more expert in TCP than I.

But I think it might be helpful to provide guidance on how implementations of TCP or possible changes to TCP could affect the vulnerability of RTO to DOS attacks.  In particular, anything that would make it easier for a receiver to acknowledge a packet without having seen it would be undesirable.




Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil










Catherine Meadows

Naval Research Laboratory

Code 5543

4555 Overlook Ave., S.W.

Washington DC, 20375

phone: 202-767-3490

fax: 202-404-7942

email: 

catherine.meadows at nrl.navy.mil