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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 09 February 2015 21:41 UTC

Return-Path: <brian.e.carpenter@gmail.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 299EA1A8772; Mon, 9 Feb 2015 13:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 pam5jrhjL0lw; Mon, 9 Feb 2015 13:41:32 -0800 (PST)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA991A1A48; Mon, 9 Feb 2015 13:41:32 -0800 (PST)
Received: by pdbfl12 with SMTP id fl12so9295901pdb.2; Mon, 09 Feb 2015 13:41:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R6NpCq2p8vmOFR2Gw7VkfLSx8T+5GBCjTsm9/Yambnw=; b=0ra2tJDkCd0cYNUKLxt0aHXxU/cZotvzHhLLU59rVG80G/Iiywqi9x1DQ6UPGQnRQS 0y/eUMtcs9jccTTwb2bJQUEpQVW7QNMVtx9/wxb7l9dd7i7UySYlyESOXTuePq0XuB30 e7qEC6XAyEJotSI5iKWw+wMTbWrPxiv5QQZ9c83JNwJbHlELosig9+dMs0I1IFuuFcSp 10tqhbao3RlrbsCLIeP0VzpFVLfHOLp1WIMIXoLyolJtn29yb3g7IBeaNJ/J9ppAMAxi O4jQH6+knJQBTZpAhDORwVQlFR+bJ95yjwX/Pmr3yirfNdnAgnpr+1usm0zt5Gm1AbEk qKHQ==
X-Received: by 10.70.134.97 with SMTP id pj1mr32290566pdb.125.1423518092206; Mon, 09 Feb 2015 13:41:32 -0800 (PST)
Received: from ?IPv6:2406:e007:4f88:1:28cc:dc4c:9703:6781? ([2406:e007:4f88:1:28cc:dc4c:9703:6781]) by mx.google.com with ESMTPSA id v2sm17280261pdm.77.2015.02.09.13.41.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Feb 2015 13:41:31 -0800 (PST)
Message-ID: <54D92987.2080505@gmail.com>
Date: Tue, 10 Feb 2015 10:41:27 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <20150207194616.20651.30892.idtracker@ietfa.amsl.com> <06B01D8E-981D-4D06-B6CC-3B5CE92782C5@nominum.com> <Pine.LNX.4.64.1502080813060.2950@shell4.bayarea.net> <D97E8BB3-0DB3-4B41-8C91-DBB3121DCEF7@nominum.com> <Pine.LNX.4.64.1502081507150.24776@shell4.bayarea.net> <72C73500-E6C4-4D75-9CFA-8FE4B012AB9E@nominum.com> <7516AD5C-1152-4020-B050-FA0383B58DBA@viagenie.ca> <Pine.LNX.4.64.1502081734120.24776@shell4.bayarea.net> <97C8D14E-D440-4625-8F26-83AF26917CF2@nominum.com> <54D83E7F.3040207@gmail.com> <E478028B-8FFC-47B4-B12D-F0A32227A726@nominum.com> <54D83FCE.4070804@qti.qualcomm.com> <Pine.LNX.4.64.1502082137570.16054@shell4.bayarea.net> <96CE509D-3B6E-49B8-98F6-CB8581787D7E@nominum.com> <Pine.LNX.4.64.1502090708270.22936@shell4.bayarea.net> <174AA530-3993-4894-BCE7-2AE8818EB35E@nominum.com> <54D8F98D.1030101@si6networks.com> <B3474476-3FA1-484E-BAAD-E7A6474BA11C@nominum.com> <54D90EE5.2060002@gmail.com> <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com>
In-Reply-To: <5C9CF492-A795-4023-BB91-28B1B52706E4@nominum.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/opsec/nGKwanlQiBfAu2qYlZ6wrc98f-o>
Cc: "draft-ietf-opsec-dhcpv6-shield@ietf.org" <draft-ietf-opsec-dhcpv6-shield@ietf.org>, "C. M. Heard" <heard@pobox.com>, Pete Resnick <presnick@qti.qualcomm.com>, "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>, Fernando Gont <fgont@si6networks.com>, "opsec-chairs@ietf.org" <opsec-chairs@ietf.org>
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: Mon, 09 Feb 2015 21:41:34 -0000

On 10/02/2015 08:52, Ted Lemon wrote:
> On Feb 9, 2015, at 2:47 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> Fair enough. But let's just say that DHCPv6 Shield sees a Next Header
>> value of 253. How does it know where to look for a potential UDP
>> header with port 546?
> 
> Either the next header is an unknown EH conforming to RFC 6564, or else it is a protocol header.   If it is a protocol header, then it is an unknown protocol header, and therefore not a UDP header.   If it conforms to RFC 6564, then it can be successfully skipped, whether or not it is known.

OK Ted, then please provide the pseudo-code for making that
determination:

  if ???? then #it's an unknown extension header conforming to RFC 6564
          else #it's an unknown transport protocol;

    Brian

>> I simply don't believe that any security product designer will do
>> anything except give up and discard the packet. Don't we want RFCs
>> to live in the real world?
> 
> We want RFCs to recommend the right thing.   It is likely true that at present, the implementor of a switch that implements DHCPv6 shield may cut some corners on processing of unknown headers.   However, this is not something the IETF should recommend they do, because our recommendations will last longer than the current state of the art.   There is no reason to cast the limitations of the current state of the art in stone.
>