[secdir] secdir review of draft-ietf-6man-oversized-header-chain-08
Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 16 October 2013 21:09 UTC
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C1511E82B4 for <secdir@ietfa.amsl.com>; Wed, 16 Oct 2013 14:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.99
X-Spam-Level:
X-Spam-Status: No, score=-94.99 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddjxeQVra07O for <secdir@ietfa.amsl.com>; Wed, 16 Oct 2013 14:09:04 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1691011E81D7 for <secdir@ietf.org>; Wed, 16 Oct 2013 14:08:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=B32CdyjXkz64U0tG6N2MB4CLMJ7olVXd7yJP7wKQsypC75E0sn7fWrK1VvtE20GJdcF7FY9pTBMVckhrWXE0PkI93GUUPkRC4+WxL/8/Qxys0oEoKLu9UiIU+ByfYun6; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type;
Received: (qmail 13726 invoked from network); 16 Oct 2013 23:08:51 +0200
Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.100?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Oct 2013 23:08:51 +0200
Message-ID: <525F0063.202@gondrom.org>
Date: Wed, 16 Oct 2013 22:08:51 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-oversized-header-chain.all@tools.ietf.org
References: <51D41722.8080900@gondrom.org>
In-Reply-To: <51D41722.8080900@gondrom.org>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/alternative; boundary="------------060207080108070808050904"
Subject: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 16 Oct 2013 21:09:10 -0000
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 ust like any other last call comments. This ID is Standards Track and and updates RFC 2460 such that the first fragment of a packet MUST contain the entire IPv6 header chain. The security considerations section is good. In fact the whole draft's objective is to solve a potential security problem with super-large IPv6 header chains and enable reliable stateless packet filtering for IPv6. COMMENTS: 1. A question, less from a security, but interoperability perspective: is there any deplyoment data on any potential backwards compatibility issues with current IPv6 deployments? Namely are there noteworthy deployments with large IPv6 header chains beyond the first fragment currently in deployment? 2. section 5 third paragraph: I wonder whether we should be more strict and replace the "MAY" with a "SHOULD"? This would make intermediate behavior consistent with the host from the previous paragraph and should avoid inconsistencies within the network topology? Best regards, Tobias
- [secdir] secdir review of draft-ietf-appsawg-rfc5… Tobias Gondrom
- [secdir] secdir review of draft-ietf-6man-oversiz… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-6man-ove… Fernando Gont
- Re: [secdir] secdir review of draft-ietf-6man-ove… Tobias Gondrom
- Re: [secdir] secdir review of draft-ietf-6man-ove… Fernando Gont
- Re: [secdir] secdir review of draft-ietf-6man-ove… Tobias Gondrom