Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC
"C. M. Heard" <heard@pobox.com> Fri, 30 November 2018 14:46 UTC
Return-Path: <heard@pobox.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6881200B3; Fri, 30 Nov 2018 06:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 4YjNax-dH0Ew; Fri, 30 Nov 2018 06:46:41 -0800 (PST)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630CA126CC7; Fri, 30 Nov 2018 06:46:40 -0800 (PST)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AB495115BE5; Fri, 30 Nov 2018 09:46:38 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=ov94pdnocaH0WIUghb2J2zZcGsM=; b=Og1IHb 2z+B6AJsS8oIXuwTOj9G7cmdW12e+ab+4+UCkN9BsNbMwb50xehQ9DNp+UG7SafX xzZc/cScMLNYIfxsOvYBsdjDA6USF0+WLVk7tTKCGgXTcx2yAswHG7Vztf//atZU np1hU2ln5ukEaccmA/65QZWqbCrYLUt2kjALM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=HrQwEFOMjVX8vakJ71Yx+ocQm6iYoh5y or9fIez6wW+y2qvTLhNY/pQ5+9u+Zw+y9Dxno6/t8uEspF0QAnxQqYO8Y5oE43ly wbDMH0nqQzu14uGmolPvjQnBInXlj+YbR8s3HQeiWalxsAxjCJ8GCwGvED4im84U /yhWZ3ABP+g=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id A3FCE115BE4; Fri, 30 Nov 2018 09:46:38 -0500 (EST)
Received: from mail-io1-f43.google.com (unknown [209.85.166.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 393E2115BE0; Fri, 30 Nov 2018 09:46:38 -0500 (EST)
Received: by mail-io1-f43.google.com with SMTP id m19so4721309ioh.3; Fri, 30 Nov 2018 06:46:38 -0800 (PST)
X-Gm-Message-State: AA+aEWZqXfvcnz0ki0Rbi+8TgYZJMT3oI/oWHc2DOydwqMamjWf5AYJj wiEo+FpIJhrbBUqX5gqrTyknVN7Qbatgn1RiV0w=
X-Google-Smtp-Source: AFSGD/WroL1YygQhaCstD6c6vhqhr7V4WV/jmR5pEThFB6sMVO50wvb2eUtFgM3ESFyk27UHy5SZPzH9wPrI6MQ7umA=
X-Received: by 2002:a6b:d618:: with SMTP id w24mr3580258ioa.24.1543589197652; Fri, 30 Nov 2018 06:46:37 -0800 (PST)
MIME-Version: 1.0
References: <CACL_3VExxwN6z-WHbp3dcdLNV1JMVf=sgMVzh-k0shNJFeADbQ@mail.gmail.com> <BLUPR0501MB2051A8FFB1DAFDCA9873B9E6AE700@BLUPR0501MB2051.namprd05.prod.outlook.com> <CACL_3VFSHqU-D+NJu=k2-p4tbjZukT7i7WEoX+5kdUtdHB4Rjw@mail.gmail.com> <CACL_3VGk0CsHObEgSwLdCp8agOWrjccB94-aynEz3Bv0w+EU+w@mail.gmail.com> <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org> <CACL_3VGHWW8fCDo8Q9br2fwXn5zBi+kN_5a1sOTX7m7QaU8iyg@mail.gmail.com> <3dc898de-6a18-4106-52fd-36cb8f60b19b@gmail.com> <f2784abe-d5b5-a556-3cfa-63481a7a8929@foobar.org> <CACL_3VGqhc-gFhbGJNm9XjZRXHpv9yZ3e4CurmT2P-VpQuVi3w@mail.gmail.com> <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com> <CACL_3VHnUZwcG2=QbJ8HZf6nqiYv8qXxK8cOkuBmdX3QsKfPNg@mail.gmail.com> <12480906-A488-477E-BAE9-B7E22FD34060@gmail.com> <65e96716-48d3-a26c-905a-a5e47deea683@si6networks.com> <16F94EAB-CE40-4A4A-BAB3-4DDAC44980B0@employees.org> <CACL_3VHntGacF6B=L6ZmjPVhWBPbGQBpE8n5VYjA+URFhWRwYA@mail.gmail.com>
In-Reply-To: <CACL_3VHntGacF6B=L6ZmjPVhWBPbGQBpE8n5VYjA+URFhWRwYA@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 30 Nov 2018 06:46:26 -0800
X-Gmail-Original-Message-ID: <CACL_3VHP+4qKaOiOsMj27io_oEPS1ptkSeGqXFB9KDaS9CPkTQ@mail.gmail.com>
Message-ID: <CACL_3VHP+4qKaOiOsMj27io_oEPS1ptkSeGqXFB9KDaS9CPkTQ@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC
To: Fernando Gont <fgont@si6networks.com>
Cc: OPSEC <opsec@ietf.org>, IETF <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: BDE8ED9C-F4AE-11E8-B629-BFB3E64BB12D-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IbKu1fsnpj6itoXbvFKj9UtzkNI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2018 14:46:44 -0000
On Tue, Nov 27, 2018 at 11:46 AM C. M. Heard wrote: > As I look at the advice for specific options more carefully, I find > some inconsistencies in the advice for certain cases [...]. > > I will follow up after doing a more thorough review of the specific > advice for each option. Here is the promised/threatened follow up. Section 3.4.1.2, Specification of the Hop-by-Hop Options extension header: the deprecated Endpoint Identification Option (Type 0x8A) should not be listed here. The reference cited for this option states that it is a Destination Option to convey Nimrod EIDs. Section 3.4.6.2, Specification of the Destination Options extension header: the Performance and Diagnostic Metrics (PDM) Option should be listed here. The reference is RFC 8250. Section 4: A subsection documenting the PDM Option needs to be added. Insofar as this is a standard option that is to be ignored by systems that do not implement it, the advice "should not discard" would be an appropriate default. Section 4: The advice for specific options is not conditioned upon whether they are found in a Hop-by-Hop Options header or a Destination Options header. However, every defined option (other than padding and experimental types) is intended to appear in only one of those headers. At a minimum this needs to be pointed out. It may be appropriate to advise that packets with defined options that appear within the "wrong" header should be discarded. Section 4: The advice for Router Alert (Type=0x05, Proposed Standard) and SMF_DPD (Type=0x08, Experimental) is "should discard", while the advice for Quick-Start (Type=0x26, Experimental) is "should not discard". All of these Hop-by-Hop options are applicable only in limited domains (RFC 6398 says so for Router Alert), and Quick Start and Router Alert have substantial security implications. Thus, I have a hard time wrapping my head around the fact that they do not all get the same advice. How about something like "intermediate systems should discard packets that contain this option, except when deployed in an administrative domain where the option is in use" for all of them? Section 4: Randall Atkinson has provided detailed comments on CALIPSO. I support those comments. Note that systems compliant with RFC 8200 that do not implement RFC 5570 would simply ignore the option. Sections 4.3.18.5 and 4.4.5: as I previously stated, I think the right strategy is to remain neutral and say that operators should determine according to their own circumstances whether to discard packets containing these options. Reiterated only for completeness. Unused reference: I-D.ietf-6man-hbh-header-handling Mike Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… R. Atkinson
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… Fernando Gont
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… R. Atkinson
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… C. M. Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… Nick Hilliard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… C. M. Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… Brian E Carpenter
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… Nick Hilliard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… C. M. Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Bob Hinden
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Ole Troan
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… C. M. Heard
- Re: Last Call: <draft-ietf-opsec-ipv6-eh-filterin… C. M. Heard