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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 13 Jul 2021 06:23:35 -0700

Roman Danyliw 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:
----------------------------------------------------------------------

Can the principled approach to making these recommendations be more clearly
explained and documented?  Section 3 primarily establishes a two-option
filtering regime (drop vs. permit), but Section 4 seems to provide more nuance
with a three-option filtering regime which considers the needs of the network
(drop vs. drop if functionality not needed vs. permit).  As an aside, a fourth
filtering action of removing the options is presented in Section 4.3.9.4. 
Additionally, see the comment below which has a summary table for
recommendations in Section 4 analogous to Table 1 of Section 3 to allow
side-by-side comparisons.

Was the three-option filtering regime considered for all recommendations?  For
example, Section 4.3.7.5 , Router Alert (Type=0x05) recommends permitting this
option “in environments where support for RSVP, multicast routing, or similar
protocols is desired.” (i.e., “drop if functionality is not needed”).  However,
Section 3.4.8, HIP (Protocol Number=139) recommend categorically permitted
these packets. If an operator knows that HIP is not a technology they have a
desire to use in an environment, why shouldn’t they block it (just like was
suggested for Router Alerts)?

Consideration for conditional discard based on local needs seems appropriate
for Shim6, Mobility Header, HIP, ILNP Nonce, Tunnel Encapsulation, and all RPL
options if the goal is to minimize traffic which has to go on the slow path.

I read in the shepherd’s write-up that trade-offs were made to minimize
ossification.  However, that rationale is not apparent in the text.

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

** Section 1.  Per “Recent studies (see e.g. [RFC7872) …”, is there an updated
study to reference to support the thesis that widespread dropping of IPv6
packets with extension headers is happening?  RFC7872 is based on data sets
from 2014 and 2015.

** Section 1.
   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.

-- What does the word officially in quotes mean?

-- Is there any reference that supports the assertion of improper configuration
defaults?

-- who is providing inappropriate advice?

** Section 1.  The text calls out the use of “deny-lists” by transit networks
and “accept-lists” that are “enforced closer to the destination systems”.  Is
there any indication that the networks which originate the traffic are doing
filtering of outbound traffic?

** Section 2.1  Per “… and irrespective of whether the specific filtering
action is logged”, no issues with making this distinction.  However, it seems
out of place since none of the previous text said anything about logging as a
discriminator among the permit, drop or reject actions.

** Section 2.3.  This section seems mistitled as “Conventions”.  The text
appears to be describing assumptions for nodes and how the guidance will be
used.

** Section 3.2.  Per the cited references:

-- [FW-Benchmark].  This associated URL returned a 404 error for me
(http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf)

-- [Cisco-EH].  This document was last updated in 2006.  Are the design
descriptions it captures still accurate?

** Section 4.  Table 1 summarized the recommendations of Section 3.  A similar
table would be helpful for the recommendations of this section.  For example:
   +----------------------------+--------------------------+-----------+
   |          Option            |     Filtering policy     | Reference |
   +----------------------------+--------------------------+-----------+
   |             Pad1           |         Permit           |  Section  |
   |         (Type=0x00)        |                          |    4.3.1  |
   +----------------------------+--------------------------+-----------+
   |             PadN           |         Permit           |  Section  |
   |         (Type=0x01)        |                          |    4.3.2  |
   +----------------------------+--------------------------+-----------+
   |        Jumbo Payload       |     Permit based on      |  Section  |
   |         (Type=0xC2)        |   needed functionality   |    4.3.3  |
   +----------------------------+--------------------------+-----------+
   |        RPL Option          |  Router-specific filter  |  Section  |
   |         (Type=0x63)        |                          |    4.3.4  |
   +----------------------------+--------------------------+-----------+
   |           RPL Option       |         Permit           |  Section  |
   |         (Type=0x23)        |                          |    4.3.5  |
   +----------------------------+--------------------------+-----------+
   | Tunnel Encapsulation Limit |         Permit           |  Section  |
   |         (Type=0x04)        |                          |    4.3.6  |
   +----------------------------+--------------------------+-----------+
   |        Router Alert        |       Permit based on    |  Section  |
   |         (Type=0x05)        |    needed functionality  |    4.3.7  |
   +----------------------------+--------------------------+-----------+
   |          Quick Start       |         Permit           |  Section  |
   |         (Type=0x26)        |                          |    4.3.8  |
   +----------------------------+--------------------------+-----------+
   |          CALIPSO           |      Permit based on     |  Section  |
   |         (Type=0x07)        |     needed functionality |    4.3.9  |
   +----------------------------+--------------------------+-----------+
   |    Home Address            |         Permit           |  Section  |
   |         (Type=0xC9)        |                          |    4.3.11 |
   +----------------------------+--------------------------+-----------+
   |    Endpoint Identification |         Drop             |  Section  |
   |         (Type=0x8A)        |                          |    4.3.12 |
   +----------------------------+--------------------------+-----------+
   |          ILNP Nonce        |         Permit           |  Section  |
   |         (Type=0x8B)        |                          |    4.3.13 |
   +----------------------------+--------------------------+-----------+
   |   Line-Identification      |         Drop             |  Section  |
   |         (Type=0x8C)        |                          |    4.3.14 |
   +----------------------------+--------------------------+-----------+
   |        Deprecated          |         Drop             |  Section  |
   |         (Type=0x4D)        |                          |    4.3.15 |
   +----------------------------+--------------------------+-----------+
   ...

** Section 7.  The text doesn’t seem to make a statement about security beyond
reiterating the intent of the document.  Does adopting the practices in this
document improve the security posture of the network?  Are there any new
security considerations to consider if these practices are adopted?

** Editorial

-- Section 2.3.  Editorial.  Per the paragraph that starts with “Finally, we
note that …”, this guidance seems very similar (repetitive) to the explanation
already provided in Section 2.1.

-- Section 3.2.  Editorial.  s/decisions in future/decisions in the future/

-- Section 4.3.9.5.  Editorial.  Recommend removing the unique “RFC-5570” style
notation.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Jul 2021 03:50:27 +0000

Hi, Roman,

Thanks a lot for your comments! In-line...

On 13/7/21 10:23, Roman Danyliw via Datatracker wrote:
[....]
> (drop vs. drop if functionality not needed vs. permit). 

That's not how I read the document myself. Essentially,

* The document takes the approach of only recommending to drop things if
  they are known to be harmful. -- as opposed to whether the feature "is
  needed", which may be hard to tell since the advice is directed at
  transit routers.

* That said, the document notes what would break when such packets are
  dropped, such that folks deciding to drop them can make a more
  informed decision.

> As an aside, a fourth

Good grief about this one! -- Looks like there's some text that we have
somehow dragged from earlier versions of this document.

How about rephrasing Section 4.3.9.4 as:

   Dropping packets that contain a CALIPSO option would prevent
   communication among systems employing CALIPSO for conveying
   sensitivity labels in Multi-Level Secure (MLS) networking
   environments.

?

> suggested for Router Alerts)?

Router Alerts have known negative implications for intervening systems,
whereas HIP options do not.

> ossification.  However, that rationale is not apparent in the text.

Please let me provide some background:

* Originally, the document provided advice for routers in general, and
  was more agressive on the filtering advice (kind of "only allow what's
  needed").

* That idea wasn't welcome, so what we essentially did was this:

  1) Note that Your devices might suffer from EHs, in which case you
     might need to consider dropping such packets (see
     draft-ietf-v6ops-ipv6-ehs-packet-drops). In such cases, this
     document can be of help to figure out what such policy might break.

  2) In other cases, only recommend to drop packets with EHs with well
    -known security implications (notably Router Alert), or that, by
     definition, shouldn't be found in transit networks.

That's what we tried to codify in the document.

Is there anything that you consider that doesn't follow this "philosophy"?

> packets with extension headers is happening?  RFC7872 is based on data sets

Anecdotal and empyrical evidence suggests that that;s still the case. --
but no, I don't know of a more recent study.

> -- What does the word officially in quotes mean?

Maybe "explicitly" would be a better term?  (i.e., they openly say they do).

> -- Is there any reference that supports the assertion of improper configuration

maybe "improper configuration templates" would be a better phrasing?

> -- who is providing inappropriate advice?

Virtually everyone in any security conference where the topic is discussed.

(I realize we might also phrase it as "it is also mpossible that..")

> filtering of outbound traffic?

We mostly meant in-bound accept-list closer to the destination systems.
However, in such cases, such devices block both incoming and outgoing
packets.

And yep, close to the edges you get all sort of filtering.

> discriminator among the permit, drop or reject actions.

How about simply removing ", and irrespective of
   whether the specific filtering action is logged."?

> appears to be describing assumptions for nodes and how the guidance will be

Any suggestions for a better title?

> (http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf)

Will get this one fixed. Thanks!

> descriptions it captures still accurate?

They are. -- we are arounfd the same lines in
draft-ietf-v6ops-ipv6-ehs-packet-drops .

> table would be helpful for the recommendations of this section.  For example:

Will do. Thanks a lot!

> document improve the security posture of the network?  

As noted above, this document just recommends to drops stuff that is
well-known to be harmful. But it also notes that:

   Operators are urged to consider the IPv6 EH and IPv6 options handling
   capabilities of their devices as they make deployment decisions in
   future.

.. which would probably make people analyze their environment... in
which case, if EHs could lead to e.g. DoS attacks, they would probably
decide to drop such packets.

I do believe that this would result in an improvement of the security
posture.

> Are there any new

Not that I know of.

> already provided in Section 2.1.

I'd probably keep it, for clarity sake, since here we're arguing in
favor of reporting the drops,

> -- Section 3.2.  Editorial.  s/decisions in future/decisions in the future/

Will fix it.

> -- Section 4.3.9.5.  Editorial.  Recommend removing the unique “RFC-5570” style

Yep. Will fix this one, too.

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531