[secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02
Catherine Meadows <catherine.meadows@nrl.navy.mil> Mon, 23 August 2010 22:23 UTC
Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A3A3A6AF2; Mon, 23 Aug 2010 15:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG9BDGsLWSTE; Mon, 23 Aug 2010 15:23:24 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A52B23A6960; Mon, 23 Aug 2010 15:23:23 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o7NMNu4i020084; Mon, 23 Aug 2010 18:23:56 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o7NMNt0h009510; Mon, 23 Aug 2010 18:23:55 -0400 (EDT)
Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010082318235401822 ; Mon, 23 Aug 2010 18:23:54 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary="Apple-Mail-12--647387733"
Date: Mon, 23 Aug 2010 18:28:10 -0400
Message-Id: <AA2DD522-84A2-48BF-AA4A-072CBB41B97A@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 23 Aug 2010 22:23:27 -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 document proposes an algorithm to make TCP more robust to long connectivity disruptions. Currently TCP has no way of distinguishing disruptions due to connectivity loss from disruptions due to congestion. Thus, TCP will back off when faced with connectivity loss, which will lead to further delays. The proposed algorithm uses the ICMP destination unreachable messages as indications of a connectivity disruption, and alters the behavior of TCP accordingly. My impression from reading this draft is that the behavior and utility of this algorithm will depend on further research and experimentation. There are a number of situations in which it will still be possible to confuse congestion and long connectivity disruptions that may need further exploration. The authors of the document do a good job of pointing these out, but I would have liked to have seen more evidence that the solutions recommended are the optimal ones, and under what situations. This is especially the case for the security issues, although it is not limited to those. For example, in the discussion of probing frequency in Section 5.4 the authors make a claim that in their belief the approach of their algorithm is preferable to others that would give higher probing frequency, but they need to provide more evidence to back this up. The security considerations section itself is rather sketchy, and doesn't support that authors' assertions that the algorithm is "considered to be secure." The greatest security threat posed by this algorithm is that an attacker could exploit it to persuade a TCP sender that communication problems due to congestion are actually due to a connectivity problem, leading the sender to further contribute to the congestion. However, the authors mention only one possible attack: forging ICMP destination unreachable messages, which they present only as an "example" of an attack. I would recommend a more complete discussion, considering each of the potential ambiguity cases discussed in the document, and discussing how an attacker could exploit them and how such exploitation could be prevented or mitigated. You might also want to discuss the opposite problem: how an attacker could convince a sender that a connectivity problem is a congestion problem. This is less serious, at least for the moment, since in the current situation that is exactly what happens, but it could be more of a threat further down the line if people come to rely more on this ability to disambiguate. 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
- [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd… Catherine Meadows
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Lars Eggert
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Catherine Meadows
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Lars Eggert
- Re: [secdir] Secdir review of draft-ietf-tcpm-tcp… Alexander Zimmermann