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

[Roman Danyliw via Datatracker <[e-mail]>]

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.