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

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