Re: [secdir] SecDir Review of draft-ietf-behave-dccp-03

Catherine Meadows <catherine.meadows@nrl.navy.mil> Tue, 21 October 2008 20:39 UTC

Return-Path: <secdir-bounces@ietf.org>
X-Original-To: secdir-archive@ietf.org
Delivered-To: ietfarch-secdir-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A903A6804; Tue, 21 Oct 2008 13:39:15 -0700 (PDT)
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 CC0653A67E2 for <secdir@core3.amsl.com>; Tue, 21 Oct 2008 13:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 HEibfgGF4BCE for <secdir@core3.amsl.com>; Tue, 21 Oct 2008 13:39:13 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 8BF1D3A6804 for <secdir@ietf.org>; Tue, 21 Oct 2008 13:39:13 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id m9LKe7Gr019136; Tue, 21 Oct 2008 16:40:07 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id m9LKe1ME001652; Tue, 21 Oct 2008 16:40:07 -0400 (EDT)
Received: from enkidu.fw5540.net ([10.0.3.64]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2008102116400708376 ; Tue, 21 Oct 2008 16:40:07 -0400
Message-Id: <2925A3D3-BAAD-4C6C-A950-BD89031AF9C4@nrl.navy.mil>
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
To: Rémi Denis-Courmont <rem@videolan.org>
In-Reply-To: <200810211942.24209.rem@videolan.org>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 16:39:00 -0400
References: <A627C94E-3550-46AB-936F-0208AE304014@nrl.navy.mil> <200810211942.24209.rem@videolan.org>
X-Mailer: Apple Mail (2.929.2)
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, dwing@cisco.com, dthaler@microsoft.com, secdir@ietf.org
Subject: Re: [secdir] SecDir Review of draft-ietf-behave-dccp-03
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/pipermail/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>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes"
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org

Yes, that is much clearer.  Just one small thing:  from the wording it  
looks like it is the NAT that is letting the NAT
administrator reconfigure it.   I would instead have

To protect against denial-of-service attack filling its state storage
  capacity, a NAT
     may attempt to actively determine the liveliness of a DCCP
  connection, or  the NAT administrator could configure more  
conservative
  timeouts.

Cathy

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



On Oct 21, 2008, at 12:42 PM, Rémi Denis-Courmont wrote:

> 	Hello,
>
> Le mardi 21 octobre 2008 18:45:51 Catherine Meadows, vous avez écrit :
>>  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 gives a set of behavioral requirements for network address
>> translation for DCCP.
>> In the secure considerations section, the authors discuss the
>> requirements that have security considerations,
>> and give recommendations.   This mostly looks in good shape, but I
>> have trouble understanding the discussion of
>> Requirement 5 in this section.  It reads, in its entirety:
>>
>>  REQ-5 recommends that a NAT that passively monitors DCCP state keep
>>    idle sessions alive for at least 124 minutes or 4 minutes  
>> depending
>>    on the state of the connection. it may attempt to actively  
>> determine
>>    the liveliness of a DCCP connection or let the NAT administrator
>>    configure more conservative timeouts.
>
> The text was supposed to be as follow, but the first proposition got  
> cut out
> during edition:
>
>  If a NAT is undergoing a denial-of-service attack,
>  it may attempt to actively determine the liveliness of a DCCP
>  connection or let the NAT administrator configure more conservative
>  timeouts.
>
>> It's unclear what the relationship is to security is here.  The
>> discussion needs to make that explicit.
>
> The wording comes from BEHAVE-TCP. I can hardly imagine the NAT  
> administrator
> rush to his NAT to reconfigure it, so this might be better... ?
>
>  To protect against denial-of-service attack filling its state storage
>  capacity, a NAT
>     may attempt to actively determine the liveliness of a DCCP
>  connection or let the NAT administrator configure more conservative
>  timeouts.
>
> Thanks for the review
>
> -- 
> Rémi Denis-Courmont
> http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary
>

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir