Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)

Ted Lemon <Ted.Lemon@nominum.com> Sun, 08 February 2015 19:24 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C01ACD80; Sun, 8 Feb 2015 11:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGPZ4TsObAOC; Sun, 8 Feb 2015 11:24:27 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75401ACD7F; Sun, 8 Feb 2015 11:24:26 -0800 (PST)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 869AFDA0285; Sun, 8 Feb 2015 19:24:26 +0000 (UTC)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 3CCD753E07D; Sun, 8 Feb 2015 11:24:26 -0800 (PST)
Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (64.89.235.66) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sun, 8 Feb 2015 11:24:25 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <Pine.LNX.4.64.1502080813060.2950@shell4.bayarea.net>
Date: Sun, 08 Feb 2015 14:24:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <D97E8BB3-0DB3-4B41-8C91-DBB3121DCEF7@nominum.com>
References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <D5B607FA-9B47-4F1B-A0C1-FB0C94A97CDB@bogus.com> <Pine.LNX.4.64.1502071930100.25761@shell4.bayarea.net> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <Pine.LNX.4.64.1502080813060.2950@shell4.bayarea.net>
To: "C. M. Heard" <heard@pobox.com>
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsec/nZApgfiBQcfmPUjI44cYP_OaAx8>
Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" <draft-ietf-opsec-dhcpv6-shield@ietf.org>, "opsec@ietf.org" <opsec@ietf.org>, "draft-ietf-opsec-dhcpv6-shield.ad@ietf.org" <draft-ietf-opsec-dhcpv6-shield.ad@ietf.org>, "draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org" <draft-ietf-opsec-dhcpv6-shield.shepherd@ietf.org>, The IESG <iesg@ietf.org>, "opsec-chairs@ietf.org" <opsec-chairs@ietf.org>, "brian.e.carpenter@gmail.com" <brian.e.carpenter@gmail.com>
Subject: Re: [OPSEC] Ted Lemon's Discuss on draft-ietf-opsec-dhcpv6-shield-05: (with DISCUSS and COMMENT)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Feb 2015 19:24:28 -0000

On Feb 8, 2015, at 1:47 PM, C. M. Heard <heard@pobox.com> wrote:
> It is not necessarily true that an unknown upper layer protocol 
> header will look like a malformed extension header to a device that 
> assumes it is an extension header following the format in RFC 6564.  
> If the value of the 2nd octet of the unknown header is v, then it 
> won't appear malformed if at least 8*(v+1) bytes remain in the 
> packet, starting from the beginning of the unknown header.  At that 
> point the device would be interpreting the payload of the unknown 
> upper layer PDU as an extension header chain.  In the benign case 
> where the packet is a legitimate one with an upper layer protocol 
> unknown to the device, it is likely (but not assured) that the chain 
> would quickly terminate in something that looks like a malformed 
> extension header.  However, it would not be difficult to craft a 
> packet that makes a very long apparent header chain.  Depending on 
> how the device processes header chains, that could easily be a 
> vector for DOS attacks -- e.g., by consuming processing resources or 
> by exercising a rarely used processing path.  That is why I think it 
> is UNSAFE to continue processing a header chain after encountering 
> an unknown next header value.

This may or may not be true, but to the extent that it's true, it's already addressed in RFC 7045, and it's addressed correctly there.   There is no need to strengthen the advice in RFC 7045 here, which this document currently does, and indeed this is completely unrelated to the supposed purpose of the document, which is to prevent DHCP packets sent by unauthorized servers from reaching clients.

If indeed RFC 7045 is too weak and needs to be strengthened, the place to do that is in 6man, not in opsec.   Fernando tried to do that in 6man and got no traction.   If we were to allow that to be done here, it would effectively be an end-run around the 6man working group.