Hi, Roman,
Thanks a lot for your comments! In-line...
On 13/7/21 10:23, Roman Danyliw via Datatracker wrote:
[....]
> ----------------------------------------------------------------------
> 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).
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
> filtering action of removing the options is presented in Section 4.3.9.4.
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.
?
> 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)?
Router Alerts have known negative implications for intervening systems,
whereas HIP options do not.
> 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.
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"?
> ** 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.
Anecdotal and empyrical evidence suggests that that;s still the case. --
but no, I don't know of a more recent study.
> ** 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?
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
> defaults?
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..")
> ** 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?
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.
> ** 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.
How about simply removing ", and irrespective of
whether the specific filtering action is logged."?
> ** 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.
Any suggestions for a better title?
> ** 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)
Will get this one fixed. Thanks!
> -- [Cisco-EH]. This document was last updated in 2006. Are the design
> descriptions it captures still accurate?
They are. -- we are arounfd the same lines in
draft-ietf-v6ops-ipv6-ehs-packet-drops .
> ** 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 |
> +----------------------------+--------------------------+-----------+
Will do. Thanks a lot!
> ** 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?
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
> security considerations to consider if these practices are adopted?
Not that I know of.
>
> ** 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.
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
> notation.
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
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
