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
- [secdir] SecDir Review of draft-ietf-behave-dccp-… Catherine Meadows
- Re: [secdir] SecDir Review of draft-ietf-behave-d… Catherine Meadows
- Re: [secdir] SecDir Review of draft-ietf-behave-d… Rémi Denis-Courmont