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

Email sent to list:

https://mailarchive.ietf.org/arch/msg/opsec/-lVuCN94yudp40LRJ4jfupkRrL0/

----
It has been 10+ weeks (79 days) since I sent mail to the authors letting them know that I will be marking the draft DEAD if there was no progress, more than a month since Roman updated his ballot position (https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ballot/#draft-ietf-opsec-ipv6-eh-filtering_roman-danyliw), and almost a year since the last update (> 10 months).


If there is not significant progress by May 1st I will mark the document as dead. 

W
----

[Ballot 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.

See also the text from Ben Kaduk's DISCUSSes which I am taking on.

Closed request for Last Call review by RTGDIR with state 'Overtaken by Events': Document has been through the IESG — waiting on DISCUSS but don’t need the rtg-dir review anymore

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot 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])

[Ballot 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.

[Ballot comment]
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

[Ballot 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.

[Ballot 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.

[Ballot comment]
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

[Ballot comment]
(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.

[Ballot comment]
[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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-ipv6-eh-filtering-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-28):

From: The IESG
To: IETF-Announce
CC: =?utf-8?q?=C3=89ric_Vyncke?= , draft-ietf-opsec-ipv6-eh-filtering@ietf.org, evyncke@cisco.com, opsec-chairs@ietf.org, opsec@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers) to Informational RFC


The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Recommendations on the Filtering of IPv6 Packets Containing IPv6
  Extension Headers at Transit Routers'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Note:
The WGLC was sent to OpSec, 6MAN and V6OPS to get wider review:
https://mailarchive.ietf.org/arch/msg/v6ops/MvzKKTYCDtWVtlIGxb6OfQlUats

In addition, this is the second IETF LC for this document.

Abstract

  This document analyzes the security implications of IPv6 Extension
  Headers and associated IPv6 options.  Additionally, it discusses the
  operational and interoperability implications of discarding packets
  based on the IPv6 Extension Headers and IPv6 options they contain.
  Finally, it provides advice on the filtering of such IPv6 packets at
  transit routers for traffic *not* directed to them, for those cases
  where such filtering is deemed as necessary.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/



No IPR declarations have been submitted directly on this I-D.

(not using the usual template as the first version of this document predates the template)

=== 1. Summary ===

The document shepherd is Eric Vyncke.
The responsible Area Director is Warren Kumari.

The intended status is informational, which is the right one as the I-D does not specify any protocol and only provides recommendations (nothing is normative).

The shepherd (who was OPSEC WG chair at the beginning) has reviewed the document since before its adoption, and has tracked the updates. The shepherd believes this version is ready to forward to the IESG. There are a few nits (see below).

This document recommends what filtering (if any) of extension headers should be applied on *on transit* routers (on purpose nothing is said about nodes at the edge of the network or about packets received by a node). It is based on the data collected by RFC 7872 "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World": in a 2016 measurement, a lot of IPv6 packets with extension headers were dropped during their transit over the Internet.

The document wants to prevent ossification of the Internet by recommending to allow most of the extension headers by using a deny list approach (only a couple of extension headers are recommended to be dropped, all others are recommended to be allowed). Both security and operational considerations are analyzed. The recommendation are not limited to extension headers but also to the options within those extension headers.

In short: it recommends dropping hop-by-hop (or ignoring as it can have a CPU impact), routing header type 0 (RFC 5095), and the two experimental extension headers. All others should be allowed (including fragment header).

=== 2. Review and Consensus ===

At the beginning, there was a controversy about filtering in the Internet. The authors took the right decisions to limit the purpose of the document to transit routers as well as using a deny list approach (in order to prevent the ossification). The I-D was also updated upon the publication of RFC 8200 (IPv6 standard).

The OPSEC WG *rough* consensus is that it is a useful document (albeit informational only) and the approach is the right one.

Note: there were three WG Last Calls on this I-D: 2021-02-10, 2018-05-29, 2017-09-29.
See also Warren Kumari's email summarizing the situation/comments:
https://mailarchive.ietf.org/arch/msg/opsec/8GEvdJCFrK_UVMmMK3NbgTTmMI8/

=== 3. Intellectual Property ===

The document shepherd has asked specifically to the authors on October 25 2018 and a refresh on February 12 2021: both of them replied that they are unaware of any IPR. Same request was sent to opsec@ietf.org, no reply.
Will Liu: https://mailarchive.ietf.org/arch/msg/opsec/WpsUJl2SabNASDV5cuOlG0e-oKE/
Fernando Gont: https://mailarchive.ietf.org/arch/msg/opsec/TR5b_dwiPLka10bkpiKkUKfGYNw/

=== 4. Other Points ===

The current revision -09 has some nits (unused references), the shepherd has requested the authors to fix those before the IETF Last Call. The shepherd also thinks that some normative references (such as RPL) should rather be informative.

There is no IANA section.

=== 1. Summary ===

The document shepherd is Eric Vyncke. The responsible Area Director is Warren Kumari.

This document recommends what filtering (if any) of extension headers should be applied on *on transit* routers (on purpose nothing is said about nodes at the edge of the network or about packets received by a node). It is based on the data collected by RFC 7872 ""Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World": a lot of IPv6 packets with extension headers are dropped during their transit over the Internet.

The document wants to prevent ossification of the Internet by recommending to allow most of the extension headers by using a black list approach (only a couple of extension headers are recommended to be dropped, all others are recommended to be allowed). Both security and operational considerations are analysed. The recommendation are not limited to extension headers but also to the options within those extension headers.

In short: it recommends dropping hop-by-hop (or ignoring as it can have a CPU impact), routing header type 0 (RFC 5095), and the two experimental extension headers. Specificallt, fragment header is allowed.

=== 2. Review and Consensus ===

At the beginning, there was a controversy about filtering in the Internet. The authors took the right decisions to limit the purpose of the document to transit routers as well as using a black list approach (in order to prevent the ossification).

The OPSEC WG consensus is that it is a useful document (albeit informational only) and the current approach is the right one.

=== 3. Intellectual Property ===

The document shepherd has asked specifically to the authors on October 25 2018: both of them replied that they are unaware of any IPR. Same request was sent to opsec@ietf.org, no reply.

=== 4. Other Points ===

None.

After 318 days, I'm returning this to the OpSec WG -- I'm still in favor of this being published, but it has been sufficiently long that it will really needs another WGLC and IETF LC so that I can claim consensus.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-opsec-ipv6-eh-filtering-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-12-03):

From: The IESG
To: IETF-Announce
CC: =?utf-8?q?=C3=89ric_Vyncke?= , warren@kumari.net, opsec@ietf.org, draft-ietf-opsec-ipv6-eh-filtering@ietf.org, evyncke@cisco.com, opsec-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC


The IESG has received a request from the Operational Security Capabilities
for IP Network Infrastructure WG (opsec) to consider the following document:
- 'Recommendations on the Filtering of IPv6 Packets Containing IPv6
  Extension Headers'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-12-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.


Note:
The WGLC was sent to OpSec, 6MAN and V6OPS to get wider review:
https://mailarchive.ietf.org/arch/msg/v6ops/MvzKKTYCDtWVtlIGxb6OfQlUats



Abstract


  It is common operator practice to mitigate security risks by
  enforcing appropriate packet filtering.  This document analyzes both
  the general security implications of IPv6 Extension Headers and the
  specific security implications of each Extension Header and Option
  type.  Additionally, it discusses the operational and
  interoperability implications of discarding packets based on the IPv6
  Extension Headers and IPv6 options they contain.  Finally, it
  provides advice on the filtering of such IPv6 packets at transit
  routers for traffic *not* directed to them, for those cases in which
  such filtering is deemed as necessary.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ballot/


No IPR declarations have been submitted directly on this I-D.

=== 1. Summary ===

The document shepherd is Eric Vyncke. The responsible Area Director is Warren Kumari.

This document recommends what filtering (if any) of extension headers should be applied on *on transit* routers (on purpose nothing is said about nodes at the edge of the network or about packets received by a node). It is based on the data collected by RFC 7872 ""Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World": a lot of IPv6 packets with extension headers are dropped during their transit over the Internet.

The document wants to prevent ossification of the Internet by recommending to allow most of the extension headers by using a black list approach (only a couple of extension headers are recommended to be dropped, all others are recommended to be allowed). Both security and operational considerations are analysed. The recommendation are not limited to extension headers but also to the options within those extension headers.

In short: it recommends dropping hop-by-hop (or ignoring as it can have a CPU impact), routing header type 0 (RFC 5095), and the two experimental extension headers. Specificallt, fragment header is allowed.

=== 2. Review and Consensus ===

At the beginning, there was a controversy about filtering in the Internet. The authors took the right decisions to limit the purpose of the document to transit routers as well as using a black list approach (in order to prevent the ossification).

The OPSEC WG consensus is that it is a useful document (albeit informational only) and the current approach is the right one.

=== 3. Intellectual Property ===

The document shepherd has asked specifically to the authors on October 25 2018: both of them replied that they are unaware of any IPR. Same request was sent to opsec@ietf.org, no reply.

=== 4. Other Points ===

None.