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