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

Catherine Meadows <catherine.meadows@nrl.navy.mil> Thu, 21 April 2011 22:32 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id 1C42BE0695; Thu, 21 Apr 2011 15:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id tXVyxYCEkauo; Thu, 21 Apr 2011 15:32:44 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil []) by ietfc.amsl.com (Postfix) with ESMTP id 18665E067F; Thu, 21 Apr 2011 15:32:44 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net []) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id p3LMWhDU028628; Thu, 21 Apr 2011 18:32:43 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 []) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id p3LMWhos021078; Thu, 21 Apr 2011 18:32:43 -0400 (EDT)
Received: from siduri.fw5540.net ([]) by chacs.nrl.navy.mil (SMSSMTP with SMTP id M2011042118324228880 ; Thu, 21 Apr 2011 18:32:42 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail-11-848347838"
Date: Thu, 21 Apr 2011 18:39:38 -0400
Message-Id: <0741F726-D534-4C5E-B83C-0701D42B7183@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, draft-paxson-tcpm-rfc2988bis.all@ltools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] Secdir review of draft-paxson-tcpm-rfc2988bis-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Apr 2011 22:32:45 -0000

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@nrl.navy.mil