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

From: Catherine Meadows <[email-masked]>
Date: Thu, 21 Apr 2011 18:39:38 -0400

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: [email-masked]

---

From: Catherine Meadows <[email-masked]>
Date: Thu, 21 Apr 2011 19:02:46 -0400

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

Cathy

> From: Catherine Meadows <[email-masked]>
> Date: April 21, 2011 6:39:38 PM EDT
> To: [email-masked], [email-masked], [email-masked]
> Subject: Secdir review of draft-paxson-tcpm-rfc2988bis-02
> 

Catherine Meadows

---

From: Catherine Meadows <[email-masked]>
Date: Fri, 22 Apr 2011 17:02:44 -0400

I, on the other hand, would say that if the security considerations section is 11 years old,
it is in need of an update or at least another look.  Judging from the remarks that have been
made so far, there is a lot of wisdom about the security impact of RTO that is not captured in the current security considerations section.
At the very least, I think a reference to the security considerations in RFC5681 would be in order.

Cathy

On Apr 21, 2011, at 10:09 PM, Mark Allman wrote:

> 
> I agree with everything Vern said.  But, two more points.
> 
>> 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.
> 
> First, I don't think this makes sense.  Even if some attacker can
> convince a sender to reduce its RTO and hence trip the RTO early this
> will *reduce* the sender's rate (RFC5681).  That is certainly an
> impairment attack on the connection itself, but that does not "lead to
> congestion".  I.e., it is not somehow an attack on the broader network.
> In fact, the connection would "lead to congestion" with a higher
> probability if it were to continue unimpaired at a higher sending rate.
> 
> Second, I am loathe to change a security considerations section that has
> been good enough for 11 years unless there are actually new security
> considerations.
> 
> allman
> 
> 
> 

Catherine Meadows

---

From: Vern Paxson <[email-masked]>
Date: Thu, 21 Apr 2011 18:52:53 -0700

Here are some comments on the points you raise:

> how hard is it to spoof an acknowledgement?

It requires essentially the same level of information as is needed to
inject data into an established TCP connection.  For modern TCPs, this is
viewed as quite difficult, due to the widespread randomization of initial
sequence numbers.

> What information would the attacker need to know about the packets in
> the connection?

The sequence numbers in both directions, as well as the port numbers.
There's some slop possible for the sequence numbers (they need to be within
the advertised window, per page 26 of RFC 793), but the search space here
for blind spoofing is large.

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

Quite difficult if they are off-path.  This requires that they anticipate
exactly when the sender will send *new* data (can't be a retransmission,
since those aren't used to recompute RTO) and then send a bogus ACK very
shortly after.

If the attacker is on-path *and* near the sender, then they can manipulate
the sender readily.  However, it's very difficult for an attacker to be
near a *lot* of attackers.

If the attacker is on-path but not near, then they can likely at best
manipulate the RTO towards the RTT between the attacker and the sender.
They can do better if they can guess future transmissions with exceptional
accuracy.

> What if the attacker were applying this attack to multiple senders.  Are
> there cases in which an attacker could spoof an acknowledgement without

Per the above, this is presumed very difficult to achieve today.  If it
weren't, then we are in much deeper trouble due to the ability of attackers
to inject data rather than simply manipulate RTO estimates.

		Vern

---

From: Mark Allman <[email-masked]>
Date: Thu, 21 Apr 2011 22:09:21 -0400

allman

---

From: Vern Paxson <[email-masked]>
Date: Thu, 21 Apr 2011 19:28:13 -0700

> ... Even if some attacker can
> will *reduce* the sender's rate (RFC5681).

D'oh, yeah, I should have directly flagged that, because that's pretty much
the argument in a nutshell: any time the sender acts on RTO, its sending rate
is going to near-nil, and the DoS issues get greatly diminished with this.

		Vern