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

Mark Allman <> Fri, 22 April 2011 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 911BDE0756; Thu, 21 Apr 2011 19:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.518
X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TG1sCC8+duhC; Thu, 21 Apr 2011 19:09:23 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU []) by (Postfix) with ESMTP id D3D58E075D; Thu, 21 Apr 2011 19:09:22 -0700 (PDT)
Received: from (jack.ICSI.Berkeley.EDU []) by fruitcake.ICSI.Berkeley.EDU ( with ESMTP id p3M29Lf8018639; Thu, 21 Apr 2011 19:09:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97DF53A92334; Thu, 21 Apr 2011 22:09:21 -0400 (EDT)
To: Catherine Meadows <>
From: Mark Allman <>
In-Reply-To: <>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Nobody Told Me
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="--------ma58193-1"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 21 Apr 2011 22:09:21 -0400
Message-Id: <>
X-Mailman-Approved-At: Sat, 23 Apr 2011 08:08:33 -0700
Subject: Re: [secdir] Fwd: Secdir review of draft-paxson-tcpm-rfc2988bis-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Apr 2011 02:09:23 -0000

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