Skip to main content

Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
draft-ietf-opsec-ipv6-eh-filtering-10

Note: This ballot was opened for revision 08 and is now closed.

Warren Kumari
Yes
Erik Kline
No Objection
Comment (2021-06-30 for -08) Sent
[S1] [nit]

* "some of the measured packet drops be the result" ->
  "some of the measured packet drops are the result", I think

[S2.3] [comment]

* "o  Discard (and log) packets containing" ->
  "o  Drop (and log) packets containing"

  since the subsequent bullet is about "Reject", and discard is defined
  to mean either drop or reject...I think it only makes that this bullet
  be about dropping a packet.

* "Ignore this IPv6 EH or option type ... and forward the packet"

  I think this might want to say "process the packet according rules
  for the remaining headers" or something, rather than just "forward
  the packet".

  Basically, if the packet would, for example, match some other firewall
  deny rule based on its transport header, that behaviour should be applied
  in this particular case where the IPv6 EH/option is configured to be
  ignored (rather than just saying "and forward the packet").

[S4.3.9.4] [comment]

* It seems fairly clear from RFC 5570 Security Considerations that a
  CALIPSO option is best protected with an AH, and in such cases stripping
  the CALIPSO option would cause the packet to fail validation at the
  (suitably configured) destination.

  Similarly, it might be good to note in S4.3.9.5 that if an AH is present
  presumably the advice from S3.4.5.5 applies.
Murray Kucherawy
No Objection
Comment (2021-07-15 for -08) Sent
I love a good "good advice" document where such advice is missing in an important area.  Thanks for doing this.

General feedback:

* There are several places where "*not*" appears.  Is this necessary?

* There are so few BCP 14 keywords in this document, which is Informational anyway, that you might consider not using it/them at all.

Section 1:

* "... it is possible that some of the measured packet drops be the result of ..." -- s/be/are/

* "... likely to be much more permissive that a filtering policy ..." -- s/that/than/

* "This document completes and complements the considerations for protecting the control plane from packets containing IP options that can be found in [RFC6192]." -- Should this document formally update that one?  It's also Informational.

* "Section 2 of this document specifies the terminology and conventions employed throughout this document.  Section 3 of this document ..." -- You can get rid of "this document" everywhere in this paragraph except at the end of the first sentence.

Section 3.3:

Most of the forward links in the table are broken because the full section numbers got wrapped.  Can this weird rendering get fixed?
Roman Danyliw
(was Discuss) No Objection
Comment (2022-06-16) Sent for earlier
Thanks for address my DISCUSS and COMMENT points.
Zaheduzzaman Sarker
No Objection
Comment (2021-07-15 for -08) Sent
Thanks for the efforts on the document.

I think most of my comments have already been mentioned by my fellow ADs.

I have got one in addition -

* Section 2.3 : says --
      o  Permit this IPv6 EH or IPv6 Option type.

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

   o  Reject (and log) packets containing this IPv6 EH or option type
      (where the packet drop is signaled with an ICMPv6 error message).

  I believe logs are mentioned here for a good reason but I haven't seen any mention of logging in any of the Operational and Interoperability Impact sub sections. I was expecting some discussions somewhere as "log" is mentioned in this section, otherwise this mention of log is out of context in the document. 

  Is there any particular reason for not mentioning (and log) for the permit case?
Éric Vyncke
Recuse
Comment (2021-07-15 for -08) Sent
As I am the doc shepherd... 

But please address the INT directorate review by Tim Chown:
draft-ietf-opsec-ipv6-eh-filtering

Regards

-éric
Benjamin Kaduk Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2021-07-14 for -08) Sent
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])
Alvaro Retana Former IESG member
No Objection
No Objection (2021-07-13 for -08) Sent
(1) §2.3: Using normative language in listing the requirements from rfc7045 is not appropriate without quotes, to make it clear where the rfc2119 keywords come from.  Also, the text is not exactly what rfc7045 says; for example, the last bullet uses "should" while the original text says "SHOULD".


(2) [nit] §3.4.1.2: The list of currently-defined options seems unnecessary given that no type-specific recommendation is made.  [Similar comments apply to other lists.]


(3) §3.4.1.5: "...for obvious reasons, RPL...[RFC6550] routers must not discard packets based on the presence of an IPv6 Hop-by-Hop Options EH."  The reason may not be obvious to everyone -- also, rfc6553 may be a better reference in this case.


(4) §3.4.2.3/§3.4.2.4: Not all routing headers receive the same treatment.  For example, RHT4 is mentioned when talking about both the implications and impact, while RHT3 is not mentioned at all.  Consistent treatment would be nice.


(5) [nit] §4.3.3.5:

   Intermediate systems should discard packets that contain this option.
   An operator should permit this option only in specific scenarios in
   which support for IPv6 jumbograms is desired.

The advice in this case would be complete if only the second sentence is included.


(6) §4.3.4.4: s/(e.g. at an ISP)/outside the RPL instance


(7) §4.3.5.4: "This option is meant to survive outside of an RPL instance."

The option can survive outside the LLN, but as rfc9008 says, the "intention was and remains that the Hop-by-Hop Options header with a RPL Option should be confined within the RPL domain".

Suggestion>  This option can survive outside of an RPL instance.
Lars Eggert Former IESG member
No Objection
No Objection (2021-07-13 for -08) Sent
This is mostly a personal style issue, but I find large parts of the document
hard to read, because of a myriad of very short (1-2 line) subsections, each
with their own repetitive section heading.

Section 2.3. , paragraph 7, comment:
>    We recommend that configuration options are made available to govern
>    the processing of each IPv6 EH type and each IPv6 option type.  Such
>    configuration options should include the following possible settings:

Out of curiosity, is there a reason a "strip option and forward packet" isn't
one of the options below?

Section 3.2. , paragraph 2, comment:
>    In some device architectures, IPv6 packets that contain IPv6 EHs can
>    cause the corresponding packets to be processed on the slow path, and
>    hence may be leveraged for the purpose of Denial of Service (DoS)
>    attacks [I-D.ietf-v6ops-ipv6-ehs-packet-drops] [Cisco-EH]
>    [FW-Benchmark].

Do such device architectures really still exist in 2021? The [Cisco-EH]
reference is from 2006, and the URL in [FW-Benchmark] does not seem to return
content. ([I-D.ietf-v6ops-ipv6-ehs-packet-drops] seemed to only refer to those
two references as well.)

Section 3.4.1.2. , paragraph 2, comment:
>    This EH is specified in [RFC8200].  At the time of this writing, the
>    following options have been specified for the Hop-by-Hop Options EH:

Wouldn't a pointer to the respective IANA registry suffice here, rather than a
list that is going to be inaccurate with time?
(And reading on, I see that other subsections contain similar "at the time of
this writing" lists; I would suggest replacing them all with pointers to the
respective registries.)

Document has Informational status, but uses RFC2119 keywords.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "his"; alternatives might be "they", "them", "their".
   
 * Term "traditional"; alternatives might be "classic", "classical",
   "common", "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread".
   
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.3.3.1. , paragraph 2, nit:
>  This option is meant to survive outside of an RPL instance. As a result, di
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 4.3.8.4. , paragraph 2, nit:
> n intermediate system can know whether or not that particular intermediate s
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Document references draft-ietf-v6ops-ipv6-ehs-packet-drops-06, but -08 is the
latest available revision.

Obsolete reference to RFC2460, obsoleted by RFC8200 (this may be on purpose).

These URLs in the document did not return content:
 * http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf

These URLs in the document can probably be converted to HTTPS:
 * http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.pdf
 * http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
 * http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml
Martin Duke Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2021-07-14 for -08) Sent
Hi,

Thanks for this document, it is useful to try and tame how SPs are filtering IPv6 extension headers.

However, I did find some of this document somewhat surprising in the context of RFC 8200, and this is perhaps just my naivety on how it is actually deployed:

My reading on RFC 8200 extension headers can be summarized as:
 - Hop by hop options default to being off unless you enable them.
 - Other extension headers only have relevance once the packet reaches the destination node, and hence I would have thought that all transit nodes should by default just ignore them.

Given that this document is specifically only for transit nodes where the packets are not destined to them, I was expecting a summary along the lines of:
 - Ignore hop by hop options unless they protocols in the transmit domain are making use of them.
 - Allow, and ignore, all other extension headers.  Maybe filter RH types 0 and 1 because they should not be used, but even this processing could be left until the destination node.

My slight fear with the current draft is that it makes this all seem very complicated and protocol specific which possibly might encourage ISPs to just drop all packets using EHs.

Regards,
Rob