[OPSEC] Benjamin Kaduk's Discuss on draft-ietf-opsec-ipv6-eh-filtering-08: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 15 July 2021 03:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C53A1919; Wed, 14 Jul 2021 20:31:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-opsec-ipv6-eh-filtering@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Éric Vyncke <evyncke@cisco.com>, evyncke@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <162631991585.27321.13333251204123967428@ietfa.amsl.com>
Date: Wed, 14 Jul 2021 20:31:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/HzrGs7WyAv50SaYBlDBF5-2nmUM>
Subject: [OPSEC] Benjamin Kaduk's Discuss on draft-ietf-opsec-ipv6-eh-filtering-08: (with DISCUSS and COMMENT)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 15 Jul 2021 03:31:57 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsec-ipv6-eh-filtering-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

It seems that we accumulated some factual errors by letting this draft
sit mostly idle since 2018, as the world evolved around us.  Hopefully
these are easy to remedy...

Section 3.4.1.2 claims to have a list of options that have been
specified as Hop-by-Hop options, and Section 3.4.6.2 a list of options
that have been specified as Destination Options, each respectively "at
the time of this writing".  IANA has a single registry for both
Destination and Hop-by-Hop options, and assessing which ones are defined
as Hop-by-Hop vs Destinationmay require following each reference, but it
seems that the PDM option from RFC 8250 has been allocated and is in
neither list, and the early allocations for IOAM and Path MTU Record may
need to be considered as well.  I suppose that we do attempt to go into
the individual optiosn in detail in Section 4.3, so perhaps this is not
quite so simple to remedy after all.

(Note: while it is not the preferred outcome, merely changing the
statement from "time of this writing" and "so far been specified" to "as
of 2018" ought to be sufficient to resolve the discuss, as would Lars'
suggestion of just referring to the IANA registry without incorporating
the registry contents.)

Section 3.4.8.1 refers to HIP as an "experimental protocol", but as of
RFC 7401, HIP is on the standards track.

Also, there seems to be some skew between Table 1 and Section 3.4.10.5
regarding the recommended filtering policy for the experimental/testing
EH types (drop vs [no recommendation])


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

   Recent studies (see e.g.  [RFC7872]) suggest that there is widespread
   dropping of IPv6 packets that contain IPv6 Extension Headers (EHs).
   In some cases, such packet drops occur at transit routers.  While
   some operators "officially" drop packets that contain IPv6 EHs, it is
   possible that some of the measured packet drops be the result of
   improper configuration defaults, or inappropriate advice in this
   area.

The "it is possible that some" is not very confidence-inspiring; do we
have much reason to think that there is any significant proportion of
the packet drops that are due to these reasons?

   This document is similar in nature to [RFC7126], which addresses the
   same problem for the IPv4 case.  [...]

It is interesting to note that RFC 7126 has BCP status, while this
document targets only Informational status.

   This document completes and complements the considerations for
   protecting the control plane from packets containing IP options that
   can be found in [RFC6192].

I see that RFC 6192 claims to provide "a method for protecting a
router's control plane from undesired or malicious traffic" and in
particular only claims applicability to traffic destined for the router
itself (as opposed to traffic that is passing through the router).  Is
the claim here that fully protecting the router's control plane also
requires filtering traffic that is not destined for the router itself?
I'm not sure in what other sense this document would be "complet[ing]
and complement[ing]" RFC 6192.  In particular, protecting the network as
a whole seems like a different goal than just protecting the router
control plane.

Section 2.3

   The advice provided in this document is only meant to guide an
   operator in configuring forwarding devices, and is *not* to be
   interpreted as advice regarding default configuration settings for
   network devices.  That is, this document provides advice with respect
   to operational configurations, but does not change the implementation
   defaults required by [RFC7045].

In light of the rtgdir reviewer's remarks (to which I cannot find a
response in the mailarchive), I wonder if we might include a statement
in here somewhere along the lines of "the network operator will need to
make pragmatic engineering and business decisions about how to configure
their routers, as constrained by the configuration options that the
router vendor has made available and the nature of the traffic they are
receiving.  This document does not prescribe any specific configuration
or course of action, but rather provides information and analysis
regarding potential configuration options and the consequences thereof".

   o  Discard (and log) packets containing this IPv6 EH or option type.

Should this be "drop" to more properly contrast with the subsequent
bullet that explicitly "reject"s (recalling that "discard" is claimed to
be used for "either drop or reject without specification of which"?

Section 3.3

I can't tell whether or not it's intentional that Table 1 has no entry
for unregistered EH types (which do get discussion in the body of the
document).

Section 3.4.2.3

Would this be an appropriate place to include the discussion suggested
by the rtgdir reviewer, that security issues with RHTs have been
discovered in the past that required urgent action to disable them
globally, and thus that devices should offer the ability to configure
the discard of packets bearing RH on a per-RHT basis?

Also, RFCs 6275 and 6554 seem to (respectively) have discussion of the
security implications of their routing header types, and it's not clear
why those references are not included in addition to the references for
RHT0 and RHT4.

Section 3.4.8.3

   The security implications of the HIP header are discussed in detail
   in Section 8 of [RFC6275].

RFC 6725 is "Mobility Support in IPv6" and does not specifically mention
HIP.  While Mobile IPv6 and HIP are similar in some regards, it's not
entirely clear to me that this is the correct reference.  (Section 8 of
RFC 7410 is its security considerations, so maybe that's the only change
that's needed.)

Section 3.4.10.5

I'm a bit surprised that the advice does not include a recommendation to
allow the experimental-use/testing EHs with a rate limit, to give small
experiments some chance of working across the Internet.

Section 4.3.3.5

The previous subsections do not give much indication of harm caused by
jumbograms so as to justify a recommendation to discard packets
containing them.

Section 4.3.4.5

As for jumbograms, the evidence of harm presented is sparse.
Mention (in both places?) that their presence is indicative of
unexpected traffic escaping from a controlled domain and that such
unexpected traffic would potentially have harmful consequences when
delivered might be helpful (if appropriate).

Section 4.3.6.5

   Intermediate systems should not discard packets based on the presence
   of this option.

Is that synonymous with "ignore"?
(I'll mention this just once, and skip the other places that use this
phrasing.)

Section 4.3.9.5

   For Intermediate systems that DO NOT implement RFC-5570, there should
   be a configuration option to EITHER (a) drop packets containing the
   CALIPSO option OR (b) to ignore the presence of the CALIPSO option
   and forward the packets normally.  In non-MLS environments, such
   intermediate systems should have this configuration option set to (a)
   above.  In MLS environments, such intermediate systems should have
   this option set to (b) above.  The default setting for this
   configuration option should be set to (a) above, because MLS
   environments are much less common than non-MLS environments.

This is getting a fair bit closer to prescribing default behavior than
the introductory material of the document had led me to expect.
(Similarly for the following paragraph.)

Section 4.3.14.3

   Those described in [RFC6788].

The security considerations of RFC 6788 are pretty slim ... though I
don't really expect us to have to document things more thoroughly in
this document.

Section 4.4.5

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

Is there any guidance to give on whether to offer configuration on a
per-option-type basis?

Section 7

As the rtgdir reviewer notes, situations where a packet is rejected
(with notification) result in traffic directed at the "sender"; in at
least the case of spoofed source addresses this can be an attack in its
own right.  Routers that reject packets should probably rate-limit such
notifications.

Section 9.1

Some of these references may not actually need to be normative, e.g.,
when we're just referring to protocols that might be broken if an EH
and/or option is blocked, such as RFC 2205.

Section 9.2

Is [NIMROD-DOC] or RFC 1992 the better reference?
We also have [draft-ietf-nimdor-eid] listed, but AIUI that's
sufficiently different to be separate.

NITS

Section 2.3

   o  If a forwarding node discards a packet containing a standard IPv6
      EH, it MUST be the result of a configurable policy and not just
      the result of a failure to recognize such a header.

   o  The discard policy for each standard type of EH MUST be
      individually configurable.

   o  The default configuration should allow all standard IPv6 EHs.

If we're endeavoring to retain the normative language as used in RFC
7045, the last "SHOULD" should be capitalized.

   is of use for trouble-shooting purposes.  However, throughout this
   document (when recommending that packets be discarded) we generically
   refer to the action as "discard" without specifying whether the
   sender is signaled of the packet drop.

This bit is arguably redundant with the definition in §2.1 and thus a
candidate for removal.

Section 3.4.1.2

   o  Type 0x63: RPL Option [RFC6553]

IANA has this as "RPL Option (DEPRECATED)" and also citing RFC 9008.