[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