[secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02

[Catherine Meadows <[e-mail]>]

Begin forwarded message:
 I messed up the tools email address on this My apologies for the resend.

Cathy


> From: Catherine Meadows <[e-mail]>
> Date: April 21, 2011 6:39:38 PM EDT
> To: [e-mail], [e-mail], [e-mail]
> 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: [phone]
> fax: [phone]
> email: [e-mail]
> 

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail]