Re: [secdir] SecDir Review of draft-ietf-behave-dccp-03
Rémi Denis-Courmont <rem@videolan.org> Wed, 22 October 2008 07:12 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 9FAA63A6835; Wed, 22 Oct 2008 00:12:57 -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 0DA9628C0FC for <secdir@core3.amsl.com>; Tue, 21 Oct 2008 09:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[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 fH4YLG9k63Fb for <secdir@core3.amsl.com>; Tue, 21 Oct 2008 09:41:15 -0700 (PDT)
Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id B0A4C3A6A70 for <secdir@ietf.org>; Tue, 21 Oct 2008 09:41:14 -0700 (PDT)
Received: from basile.remlab.net (unknown [IPv6:2002:591b:3aef:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTP id D3D347DC; Tue, 21 Oct 2008 18:42:26 +0200 (CEST)
From: Rémi Denis-Courmont <rem@videolan.org>
Organization: VideoLAN project - www.videolan.org
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Date: Tue, 21 Oct 2008 19:42:23 +0300
User-Agent: KMail/1.9.9
References: <A627C94E-3550-46AB-936F-0208AE304014@nrl.navy.mil>
In-Reply-To: <A627C94E-3550-46AB-936F-0208AE304014@nrl.navy.mil>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200810211942.24209.rem@videolan.org>
X-Mailman-Approved-At: Wed, 22 Oct 2008 00:12:56 -0700
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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: secdir-bounces@ietf.org
Errors-To: secdir-bounces@ietf.org
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