Re: [OPSEC] 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> Mon, 26 November 2018 14:46 UTC

Return-Path: <heard@pobox.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECF5126BED; Mon, 26 Nov 2018 06:46:46 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KP2ClkpcWbF8; Mon, 26 Nov 2018 06:46:45 -0800 (PST)
Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED243130E8F; Mon, 26 Nov 2018 06:46:44 -0800 (PST)
Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 0D4CE1155B7; Mon, 26 Nov 2018 09:46:43 -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=rsEx/g9D/BfNMrnP6WCpHJwreHA=; b=ijm9RS //eTufSpQSVfZbx24Sdv/BppaknuRlYeP+yAFFh26KG1hnMuyY11LnWufrZtt+vM wUoyh9E2HZz+TP2XgBalXobvz0UJWJVHDVjFZp+cBq3kVbmAn0iizQk6eOQnqEvZ HjC30Cxt7zYHzPFRYV9Et4gn3oi7mXWqpaCCM=
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=vYH1yvOmxG3EAoqKMwH0fC8d7noVhBt7 rxl7eGdmIXvvN0CQorF/GgXTjRYGMNi0uaga5h0ABA561Qe/x/QCSCzBTDSoUhoE zHaP/BK2SB+ufsCYalCQJQwIwMcn60sZEGCV1Re8+6pwG2REFKVm8fTd8AIxPEGr X7gD1YEkwDo=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 0564D1155B4; Mon, 26 Nov 2018 09:46:43 -0500 (EST)
Received: from mail-it1-f176.google.com (unknown [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 8B8C21155B2; Mon, 26 Nov 2018 09:46:42 -0500 (EST)
Received: by mail-it1-f176.google.com with SMTP id h65so27985705ith.3; Mon, 26 Nov 2018 06:46:42 -0800 (PST)
X-Gm-Message-State: AA+aEWaMKJnqpQ0lzdpBj0YVv4aDjFr/cFJaOXDd7rDMkCa3DqHVfHC4 KdQ6NU/ktHD50nOtnoESv2qPU2T6gtfKlvUSF/c=
X-Google-Smtp-Source: AJdET5eiO6j6yxJTUobDga1q5ylDcXexg5fQufg6Q0RZQdSEd+bzW7nSAAurl5+LAbeAc8dmQ3kCdYf69lgBLtvKLIc=
X-Received: by 2002:a02:b529:: with SMTP id l38mr22703089jaj.25.1543243601929; Mon, 26 Nov 2018 06:46:41 -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>
In-Reply-To: <40f9b0b3-f9fd-fc09-dad1-3e575df791a3@si6networks.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 26 Nov 2018 06:46:29 -0800
X-Gmail-Original-Message-ID: <CACL_3VHnUZwcG2=QbJ8HZf6nqiYv8qXxK8cOkuBmdX3QsKfPNg@mail.gmail.com>
Message-ID: <CACL_3VHnUZwcG2=QbJ8HZf6nqiYv8qXxK8cOkuBmdX3QsKfPNg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: Nick Hilliard <nick@foobar.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, OPSEC <opsec@ietf.org>, IETF <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 16D7ED68-F18A-11E8-B332-063AD72159A7-06080547!pb-smtp1.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/5SF7Q1dNnikQ23sx0nn6Iah1hMU>
Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 26 Nov 2018 14:46:47 -0000

On Sun, Nov 25, 2018 at 11:55 PM Fernando Gont wrote:
> On 24/11/18 17:37, C. M. Heard wrote:
> > On Sat, Nov 24, 2018 at 12:30 PM Nick Hilliard <nick@foobar.org> wrote:
> >> Brian E Carpenter wrote on 24/11/2018 20:17:
> >>> Operators make their own
> >>> decisions, so I think that is what the draft should say. Something like:
> >>>
> >>> 3.5.5.  Advice
> >>>
> >>>     Operators should determine according to their own circumstances
> >>>     whether to discard packets containing unknown IPv6 EHs.
> >>>
> >>> And at the same time, delete the 2nd and 3rd sentences of this:
> >>>
> >>> 3.5.3.  Specific Security Implications
> >>>
> >>>     For obvious reasons, it is impossible to determine specific security
> >>>     implications of unknown IPv6 EHs.  However, from security standpoint,
> >>>     a device should discard IPv6 extension headers for which the security
> >>>     implications cannot be determined.  We note that this policy is
> >>>     allowed by [RFC7045].
> >>
> >> This looks like a sensible approach.
> >
> > I could live with that.
>
> FWIW, I can live with that, too. UNless somebody screams against it, I
> will apply the proposed change to the next rev. Thanks!
>
> > Similar changes might be considered for Sec. 4.4.5.
>
> Will do.

Thank you.  There is also related advice in the note to Section 3.1 that
needs similar changes and the matter of experimental EHs and experimental
options that I raised in my original comments. These are all cases where
the security implications cannot be determined. Proposed text for Sections
3.1, 3.4.10.5, 3.5.3 et. seq., 4.3.18.5, and 4.4.5 follows below.

---
OLD:
      NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      IPv6 First-Fragments MUST contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can enforce the
      filtering policies discussed in this document, or resort to simply
      discarding the offending packets when they fail to comply with the
      requirements in [RFC7112].  We note that, in order to implement
      filtering rules on the fast path, it may be necessary for the
      filtering device to limit the depth into the packet that can be
      inspected before giving up.  In circumstances where there is such
      a limitation, it is recommended that implementations discard
      packets if, when trying to determine whether to discard or permit
      a packet, the aforementioned limit is encountered.

NEW:
      NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      IPv6 First-Fragments MUST contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can enforce the
      filtering policies discussed in this document, or resort to simply
      discarding the offending packets when they fail to comply with the
      requirements in [RFC7112].  We note that, in order to implement
      filtering rules on the fast path, it may be necessary for the
      filtering device to limit the depth into the packet that can be
      inspected before giving up.  In circumstances where there is such
      a limitation, it is recommended that implementations provide a
      configuration option that specifies whether to discard packets if
      the aforementioned limit is encountered.  Operators may then
      determine according to their own circumstances how such packets
      will be handled.

---
OLD:
3.4.10.5.  Advice

   Intermediate systems should discard packets containing these EHs.
   Only in specific scenarios in which RFC3692-Style experiments are to
   be performed should these EHs be permitted.

NEW:
3.4.10.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing experimental IPv6 EHs.

---
OLD:
3.5.3.  Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.  However, from security standpoint,
   a device should discard IPv6 extension headers for which the security
   implications cannot be determined.  We note that this policy is
   allowed by [RFC7045].

3.5.4.  Operational and Interoperability Impact if Blocked

   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.

3.5.5.  Advice

   Intermediate systems should discard packets containing unknown IPv6
   EHs.

NEW:
3.5.3.  Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.

3.5.4.  Operational and Interoperability Impact if Blocked

   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.

3.5.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 EHs.

---
OLD:
4.3.18.5.  Advice

   Intermediate systems should discard packets that contain these
   options.  Only in specific environments where RFC3692-style
   experiments are meant to be performed should these options be
   permitted.

NEW:
4.3.18.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing experimental IPv6 options.

---
OLD:
4.4.5.  Advice

   Enterprise intermediate systems that process the contents of IPv6 EHs
   should discard packets that contain unknown options.  Other
   intermediate systems that process the contents of IPv6 EHs should
   permit packets that contain unknown options.

NEW:
4.4.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 options.


EDITORIAL: I believe that the following is simply mis-worded:

---
OLD:
4.3.10.5.  Advice

   Intermediate system should discard packets that contain this option.

NEW:
4.3.10.5.  Advice

   Intermediate systems that are not within a MANET domain should
   discard packets that contain this option.


NITS: These should be fixed prior to publication.

---
OLD:
4.3.1.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 EHs.

NEW:
4.3.1.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 options.

---
OLD:
4.3.2.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 EHs.

NEW:
4.3.2.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 options.


In some places the abbreviations RHT0 and RHT1 are used, while in other
places RTH0 and RTH1 are used. The usage should be consistent;  IMHO the
former abbreviations seem to be more correct.

Mike Heard