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

Catherine Meadows <> Fri, 22 April 2011 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70486E07C6; Fri, 22 Apr 2011 13:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p70ld8MU9Y+F; Fri, 22 Apr 2011 13:55:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ADF3EE071B; Fri, 22 Apr 2011 13:55:56 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.6) with ESMTP id p3MKtsYk021604; Fri, 22 Apr 2011 16:55:55 -0400 (EDT)
Received: from (sun1 []) by (8.13.8/8.13.6) with SMTP id p3MKtrBS023605; Fri, 22 Apr 2011 16:55:53 -0400 (EDT)
Received: from ([]) by (SMSSMTP with SMTP id M2011042216555330062 ; Fri, 22 Apr 2011 16:55:53 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-3-928933738"
From: Catherine Meadows <>
In-Reply-To: <>
Date: Fri, 22 Apr 2011 17:02:44 -0400
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [secdir] 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 20:55:57 -0000

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.


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
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942