Subject: Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC

From: "C. M. Heard" <[email-masked]>
Date: Fri, 23 Nov 2018 08:20:00 -0800

Greetings,

IMHO, this document is NOT READY for publication in its current form.  In

the introduction it says:

The filtering policy typically depends on where in the network such policy
is enforced: when the policy is enforced in a transit network, the policy
typically follows a "black-list" approach, where only packets with clear
negative implications are dropped. On the other hand, when the policy is
enforced closer to the destination systems, the policy typically follows a
"white-list" approach, where only traffic that is expected to be received
is allowed. *The advice in this document is aimed only at transit routers
that may need to enforce a filtering policy based on the EHs and IPv6
options a packet may contain, following a "black-list" approach, and hence
is likely to be much more permissive that a filtering policy to be employed
e.g. at the edge of an enterprise network.* The advice in this document is
meant to improve the current situation of the dropping of packets with IPv6
EHs in the Internet [RFC7872 <https://tools.ietf.org/html/rfc7872>].

while promoting a ***default deny*** policy with respect to unknown

extension headers, experimental extension headers, and experimental

options.  If every transit router followed that advice, it would be

impossible to transmit packets containing these things across the open

Internet.  It is especially egregious to dispense that advice for

unknown extension headers, since that would severely impede deployment

of any new extension headers OR any new transport protocols in the open

Internet (as the document itself notes, unknown extension headers are

indistinguishable from unknown upper-layer protocol headers).  This part

of the document's advice does nothing to improve the situation reported

in RFC 7872; if anything, it makes the situation worse.  It certainly

will not make the Internet work better.

While I would prefer to advise operators of transit routers just to be

transparent to everything other than the Hop-by-Hop extensions header,

as discussed in the trailing message thread, adapting the more nuanced

advice in Section 4.4.5
<https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-4.4.5>
regarding the handling of unknown options to

the cases of unknown EHs and experimental EHs and options would be an

acceptable alternative.  Specific text to that effect follows below.

OLD:

3.5.3 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.3>.
Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.  However, from security standpoint,
   a device should discard IPv6 extension headers for which the security
   implications cannot be determined.  We note that this policy is
   allowed by [RFC7045 <https://tools.ietf.org/html/rfc7045>].

3.5.4 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.4>.
Operational and Interoperability Impact if Blocked

   As noted in [RFC7045 <https://tools.ietf.org/html/rfc7045>],
discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS
<https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#ref-IANA-PROTOCOLS>])
should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.
3.5.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.5>.
Advice

   Intermediate systems should discard packets containing unknown IPv6
   EHs.

NEW:

3.5.3 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.3>.
Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.

3.5.4 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.4>.
Operational and Interoperability Impact if Blocked

   As noted in [RFC7045 <https://tools.ietf.org/html/rfc7045>],
discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS
<https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#ref-IANA-PROTOCOLS>])
should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

   We note that since IPv6 EHs and upper-layer protocols share the same
   numbering space, discarding unknown IPv6 EHs may result in packets
   encapsulating unknown upper-layer protocols being discarded.
3.5.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.5.5>.
Advice

   Enterprise intermediate systems should discard packets that contain
   unknown IPv6 EHs. Other intermediate systems should permit packets

   that contain unknown IPv6 EHs.  We note that this policy is allowed

   by [RFC7045 <https://tools.ietf.org/html/rfc7045>].

OLD:

3.4.10.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.10.5>.
Advice

   Intermediate systems should discard packets containing these EHs.
   Only in specific scenarios in which RFC3692
<https://tools.ietf.org/html/rfc3692>-Style experiments are to
   be performed should these EHs be permitted.

NEW:

3.4.10.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.10.5>.
Advice

   Enterprise intermediate systems should discard packets that contain
   these EHs except in specific environments in which RFC3692
<https://tools.ietf.org/html/rfc3692>-Style
   are meant to be performed.  Other intermediate systems should permit

   permit packets with these EHs.

OLD:

4.3.18.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-4.3.18.5>.
Advice

   Intermediate systems should discard packets that contain these
   options.  Only in specific environments where RFC3692
<https://tools.ietf.org/html/rfc3692>-style
   experiments are meant to be performed should these options be
   permitted.

NEW:

4.3.18.5 <https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-4.3.18.5>.
Advice

   Enterprise intermediate systems should discard packets that contain
   these options except in specific enviromments in which RFC3692
<https://tools.ietf.org/html/rfc3692>-Style
   are meant to be performed.  Other intermediate systems should permit

   permit packets with these options.

NITS: in some places the abbreviations RHT0 and RHT1 are used, while

in other places RTH0 and RTH1 are used.  The usage should be consistent.

IMHO the former abbreviations seem to be more correct.

Thanks and regards,

Mike Heard

---------- Forwarded message ---------
From: C. M. Heard <[email-masked]>
Date: Thu, Oct 5, 2017 at 9:01 PM
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
To: Ron Bonica <[email-masked]>
Cc: OPSEC <[email-masked]>, Joe Touch <[email-masked]>, Bob Hinden <
[email-masked]>, Brian E Carpenter <[email-masked]>

Hello Ron,

I think that the direction you propose will make this a much better
document. Modulo details it would certainly address my concerns.

I do however have come comments to make about router self-protection. RFC
6192 is all about a router filtering traffic addressed to itself, i.e.,
what it should process in its role as a host. A very restrictive "white
list" policy ( as outlined in RC 6192) is quite in order there. If there is
no need or use for extension headers for traffic destined to the control
plane, a very restrictive policy of dropping all packets addressed to the
control place hat have extension headers may indeed be in order.

It's a very different story, I think, for what a router does to protect
itself in its role as forwarding device.  There, if it complies with RFC
8200, the Hop-by-Hop Options header is the only one that can hurt it, if it
is able to forward at line rate at all. The choice boils down to whether to
process all, some, or no packets with Hop-by-Hop options. I think that we
need to loudly broadcast that ignoring all HbH Options headers is a
legitimate policy for this purpose, but dropping all packets with HbH
Options is not. If we can sell this to the world, it may be possible to
actually use the HbH options header, and get rid of abominations such as
the CONEX Destination Option.

The way you characterize the proposed second section sounds right on the
money to me.

I support your proposed way forward. Thank you.

Mike Heard

On Thu, Oct 5, 2017 at 11:04 AM, Ron Bonica <[email-masked]> wrote:

> Mike,
>
>
>
> I think that you just struck the note that Fernando and I missed. Transit
> routers filter extension headers for one of the following reasons:
>
>
>
> -          To protect themselves (as in RFC 6192)
>
> -          To protect downstream devices
>
>
>
> Therefore, the document should contain two clearly marked sections, one
> regarding EH filtering policies that protect the transit router and one
> regarding EH filtering policies that protect downstream devices.
>
>
>
> The first section can:
>
>
>
> -          Be very short (2 pages max)
>
> -          Be guided largely by RFC 8200
>
> -          Speak with some degree of authority (while still INFORMATIONAL)
>
>
>
> The second section should begin with a discussion of the relationship
> between the transit router and the downstream devices. Let’s assume that
> the transit router belongs to an ISP, while downstream devices fall into
> the following three classes:
>
>
>
> 1)      Belong to the ISP
>
> 2)      Belong to parties who want to be protected by the ISP (e.g., its
> customers)
>
> 3)      Belong to other parties
>
>
>
> Therefore, the transit router MAY discard packets that pose a threat to
> the first two classes of downstream device, but MUST NOT discard packets
> that are required by the third class of downstream device.
>
>
>
> From this point, we formulate a policy that **might** satisfy the above
> mentioned requirement. We mark this policy with the following caveats:
>
>
>
> -          It is a best guess
>
> -          If the policy is too permissive, downstream devices belonging
> to the ISP and those who it protects will not receive all of the protection
> possible
>
> -          If the policy is too restrictive, downstream devices belonging
> to other parties will experience collateral damage
>
> -          One size doesn’t fit all
>
>
>
> If we were to rework the document into this shape, would it address your
> concerns.
>
>
>
>                                                                Ron
>
>
>
>
>
>
>
> *From:* OPSEC [mailto:[email-masked]] *On Behalf Of *C. M. Heard
> *Sent:* Wednesday, October 4, 2017 11:08 PM
> *To:* OPSEC <[email-masked]>
> *Subject:* Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
>
>
>
> On Thu, 5 Oct 2017 11:10:06 +1300, Brian E Carpenter wrote:
>
> > On 05/10/2017 02:12, Joe Touch wrote:
>
> >
>
> >> On 9/29/2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>
> >>>
>
> >>> This is to open a two week WGLC
>
> >>> for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dopsec-2Dipv6-2Deh-2Dfiltering-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=M7xHnDuuJxhA21iLVXO_-AZjAhvXwgaN__niQRcoBwc&e=>
> .
>
> >>>
>
> >>
>
> >> I do not agree with the claims of this document. It "informationally"
>
> >> advises against support for key IPv6 capabilities and undermines the
>
> >> extensibility of IPv6 by making recommendations about discarding
>
> >> currently unassigned codepoints.
>
> >
>
> > Here's the problem, Joe. It's a fact of life that many firewalls
>
> > discard a lot of stuff that they shouldn't - that's why we wrote
>
> > RFC 7045 - but in the real world, operators blunder around based
>
> > on folklore and vendors' defaults. We can't change any of that, but
>
> > we can try to issue sensible advice that, overall, will limit the
>
> > resulting breakage. IMHO this document, positioned correctly as
>
> > Informational, will do that: on balance, it makes the world a better
>
> > place.
>
>
>
> I am afraid that I do not agree that the document, in its present form,
>
> will do that. It says:
>
>
>
>    The filtering policy typically depends on where in the network such
>
>    policy is enforced: when the policy is enforced in a transit network,
>
>    the policy typically follows a "black-list" approach, where only
>
>    packets with clear negative implications are dropped.  On the other
>
>    hand, when the policy is enforced closer to the destination systems,
>
>    the policy typically follows a "white-list" approach, where only
>
>    traffic that is expected to be received is allowed.  *The advice in*
>
> *   this document is aimed only at transit routers that may need to*
>
> *   enforce a filtering policy based on the EHs and IPv6 options a packet*
>
> *   may contain, following a "black-list" approach, and hence is likely*
>
> *   to be much more permissive that a filtering policy to be employed*
>
> *   e.g. at the edge of an enterprise network.*  The advice in this
>
>    document is meant to improve the current situation of the dropping of
>
>    packets with IPv6 EHs in the Internet [RFC7872 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=KqV5UiI6Ie51NtocuTw9zMCtHX8aMheboGCPVCzdepA&e=>].
>
>
> while at the same time promoting a ***default deny*** policy with
>
> respect to unrecognized options and unrecognized extension headers.
>
> That is antithetical to the mission of a ***transit router***, which
>
> is to get packets transparently from point A to point B. It is
>
> especially egregious to dispense this advice for unrecognized
>
> extension headers, since they are indistinguishable from unrecognized
>
> transport protocols. If these things are blocked by ***transit routers***
>
> it becomes  impossible to deploy any new options or transport protocols.
>
> But we already know that, don't we?
>
>
>
> If we want to give constructive advice that really will make the
>
> world a better place, we should:
>
>
> 1.) Advise operators of ***transit routers*** to be transparent to
>
> everything other than the Hop-by-Hop extensions header, and provide
>
> detailed advice on what to do (based on the updates in RFC 8200)
>
> about Hop-by-Hop options. The default should be IGNORE unless there
>
> is an option you need to process.
>
>
> 2.) Reserve all the detailed filtering advicee for operators of
>
> firewalls, enterprise routers, and other systems whose mission it
>
> is to protect the end systems behind them (or to prevent misbehavior
>
> by said end systems). A default deny for unrecognized stuff is not
>
> unreasonable for such systems.
>
>
> 3.) Remind implementors of the following requirement from RFC 7045:
>
>
>    Forwarding nodes MUST be configurable to allow packets containing
>
>    unrecognised extension headers, but the default configuration MAY
>
>    drop such packets.
>
>
> and add similar advice for options.
>
>
> Thanks and regards,
>
>
> Mike Heard
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 24 Nov 2018 15:36:58 +0000

C. M. Heard wrote on 23/11/2018 16:20:
> while promoting a **/_default deny_/** policy with respect to unknown

transit operators would generally take the view that any data-plane 
packet which needs to be put through a slow path will be rate limited up 
to 100% loss.  We can argue endlessly at the IETF about the pros and 
cons of this from a protocol development and management point of view 
but at the end of the day, transit operators have networks to run, and 
there is a jarring disparity between data-plane forwarding speed and 
control-plane processing capacity.  If you expect one to bleed into the 
other, something needs to give.  This is often going to be 
silicon-specific; what is slow-pathed on one platform may not be 
slow-pathed on another, so generalised statements are difficult in this 
situation.

Transit operators are going to make their own decisions about what to do 
about packet filtering, and take any specific recommendation in an ID 
like this with a grain of salt.  In that respect, this document needs to 
be seen as a store of information to help people make informed decisions 
about what to do rather than being a prescriptive list.

Nick

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 24 Nov 2018 08:14:35 -0800

> slow-pathed on another, so generalised statements are difficult in this

It's not clear to me what that has to do with the specific comments
that I made (and that you elided).  I would understand if I had brought
up handling of, say, HbH options rather than default drop policies for
unknown (and experimental) header types.  Perhaps you could clarify.

> about what to do rather than being a prescriptive list.

Agreed, that's the most useful part of the document. But it does in
addition give specific advice, and that advice should be reasonable
as a default.

My primary objection is to the advice that says discard unknown
EHs and upper-layer protocols by default.  That advice needs to
be more nuanced -- as is the advice for unknown option types
given in Sec. 4.4.5,   I see no reason why these cases should
get different advice.

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Nov 2018 09:17:53 +1300

> unknown (and experimental) header types.  Perhaps you could clarify.

As background, the *end* of the discussion of HbH in the draft says:

   Finally, when
   packets containing a HBH Options EH are processed in the slow-path,
   and the underlying platform does not have any mitigation options
   available for attacks based on these packets, we recommend that such
   platforms discard packets containing IPv6 HBH Options EHs.

I'm not sure what else a firewall recommendation could say (as a default
configuration, because the whole document is really about defaults). But
it's worth reading the preceding text at
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5
to get the context for that "Finally".

> given in Sec. 4.4.5,   I see no reason why these cases should

Let's see. We have:

3.5.2.  Specification

   The processing of unknown IPv6 EHs is specified in [RFC8200] and
   [RFC7045].

In fact RFC8200 doesn't discuss EH processing by intermediate nodes.
RFC7045 does (see https://tools.ietf.org/html/rfc7045#section-2.1 ).
Again, read the whole section for context, but the key sentence is:

That was a careful compromise between the ideal (a transparent Internet)
and reality (an Internet with security-aware operators). The current draft
changes this MAY into a lower-case should:

3.5.5.  Advice

I'm with Mike Heard. This is an informational document attempting
to override a Proposed Standard. That's not OK.

That doesn't mean Nick Hilliard is wrong. Operators make their own
decisions, so I think that is what the draft should say. Something like:

3.5.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 EHs.

And at the same time, delete the 2nd and 3rd sentences of this:

3.5.3.  Specific Security Implications

   allowed by [RFC7045].

I don't expect these changes to have much impact in the real world,
however.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 24 Nov 2018 20:29:55 +0000

Brian E Carpenter wrote on 24/11/2018 20:17:
> Operators make their own

This looks like a sensible approach.

> I don't expect these changes to have much impact in the real world,

Indeed.  The real world is more complex than can be easily encapsulated 
in a draft like this, and it changes more quickly than rfcs.

Nick

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 24 Nov 2018 12:37:55 -0800

> This looks like a sensible approach.

I could live with that.  Similar changes might be considered for Sec. 4.4.5.

Mike Heard

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 24 Nov 2018 20:44:06 +0000

> unknown (and experimental) header types.  Perhaps you could clarify.

hm yes, it was a bit obtuse.  What I was trying to get at (and 
completely failed to achieve) was:

1. that EHs are largely unusable anyway, so if this draft makes some 
types slightly more unusable, that isn't going to make much of a 
practical difference.  RFC7872 suggests failure rates of ~30% - 50% for 
fragment headers.  Once you're in this territory, nothing you can do 
will make things any worse.

2. transit operators don't like filtering stuff.  They will filter 
traffic if and only if that traffic is a nuisance or forms a threat to 

> given in Sec. 4.4.5,   I see no reason why these cases should

...3. Any recommendation that the IETF makes in this area may, or may 
not, be taken as input into a decision machine, the result of which will 
be to filter, or rate limit, or to forward.  From this perspective, the 
documentation needs to observe and make suggestions.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Nov 2018 04:51:49 -0300

On 24/11/18 17:37, C. M. Heard wrote:
> I could live with that.  

FWIW, I can live with that, too. UNless somebody screams against it, I
will apply the proposed change to the next rev. Thanks!

> Similar changes might be considered for Sec. 4.4.5.

Will do.

Thanks!
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Nov 2018 06:46:29 -0800

> > Similar changes might be considered for Sec. 4.4.5.

Thank you.  There is also related advice in the note to Section 3.1 that
needs similar changes and the matter of experimental EHs and experimental
options that I raised in my original comments. These are all cases where
the security implications cannot be determined. Proposed text for Sections
3.1, 3.4.10.5, 3.5.3 et. seq., 4.3.18.5, and 4.4.5 follows below.

---
OLD:
      NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      IPv6 First-Fragments MUST contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can enforce the
      filtering policies discussed in this document, or resort to simply
      discarding the offending packets when they fail to comply with the
      requirements in [RFC7112].  We note that, in order to implement
      filtering rules on the fast path, it may be necessary for the
      filtering device to limit the depth into the packet that can be
      inspected before giving up.  In circumstances where there is such
      a limitation, it is recommended that implementations discard
      packets if, when trying to determine whether to discard or permit
      a packet, the aforementioned limit is encountered.

NEW:
      NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and
      IPv6 First-Fragments MUST contain the entire IPv6 header chain
      [RFC7112].  Therefore, intermediate systems can enforce the
      filtering policies discussed in this document, or resort to simply
      discarding the offending packets when they fail to comply with the
      requirements in [RFC7112].  We note that, in order to implement
      filtering rules on the fast path, it may be necessary for the
      filtering device to limit the depth into the packet that can be
      inspected before giving up.  In circumstances where there is such
      a limitation, it is recommended that implementations provide a
      configuration option that specifies whether to discard packets if
      the aforementioned limit is encountered.  Operators may then
      determine according to their own circumstances how such packets
      will be handled.

---
OLD:
3.4.10.5.  Advice

   Intermediate systems should discard packets containing these EHs.
   Only in specific scenarios in which RFC3692-Style experiments are to
   be performed should these EHs be permitted.

NEW:
3.4.10.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing experimental IPv6 EHs.

---
OLD:

3.5.4.  Operational and Interoperability Impact if Blocked

   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

3.5.5.  Advice

NEW:

3.5.4.  Operational and Interoperability Impact if Blocked

   As noted in [RFC7045], discarding unknown IPv6 EHs may slow down the
   deployment of new IPv6 EHs and transport protocols.  The
   corresponding IANA registry ([IANA-PROTOCOLS]) should be monitored
   such that filtering rules are updated as new IPv6 EHs are
   standardized.

3.5.5.  Advice

---
OLD:
4.3.18.5.  Advice

   Intermediate systems should discard packets that contain these
   options.  Only in specific environments where RFC3692-style
   experiments are meant to be performed should these options be
   permitted.

NEW:
4.3.18.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing experimental IPv6 options.

---
OLD:
4.4.5.  Advice

   Enterprise intermediate systems that process the contents of IPv6 EHs
   should discard packets that contain unknown options.  Other
   intermediate systems that process the contents of IPv6 EHs should
   permit packets that contain unknown options.

NEW:
4.4.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 options.

EDITORIAL: I believe that the following is simply mis-worded:

---
OLD:
4.3.10.5.  Advice

   Intermediate system should discard packets that contain this option.

NEW:
4.3.10.5.  Advice

   Intermediate systems that are not within a MANET domain should
   discard packets that contain this option.

NITS: These should be fixed prior to publication.

---
OLD:
4.3.1.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 EHs.

NEW:
4.3.1.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 options.

---
OLD:
4.3.2.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 EHs.

NEW:
4.3.2.4.  Operational and Interoperability Impact if Blocked

   Discarding packets that contain this option would potentially break
   any protocol that relies on IPv6 options.

In some places the abbreviations RHT0 and RHT1 are used, while in other
places RTH0 and RTH1 are used. The usage should be consistent;  IMHO the
former abbreviations seem to be more correct.

Mike Heard

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Nov 2018 14:49:49 -0800

Mike,

From your email:

> On Nov 26, 2018, at 6:46 AM, C. M. Heard <[email-masked]> wrote:
> 

. . . .

> . . . .

From reading the email thread, this sentence seems to me to be a good summary of the draft.

I wonder if this is something the IETF needs to tell operators.    Based on the discussion, I suspect it is not.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 26 Nov 2018 23:09:55 +0000

Bob Hinden wrote on 26/11/2018 22:49:
> I wonder if this is something the IETF needs to tell operators.
> Based on the discussion, I suspect it is not.
The draft is useful and should be published with Brian's and Mike's 
wording suggestions: some operators will read it and use it to inform 
themselves.

It's also useful to document how protocol specification choices can 
cause implementation difficulties.

Nick

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Nov 2018 15:38:24 -0800

> Based on the discussion, I suspect it is not.

Probably not :-)

> wording suggestions: some operators will read it and use it to inform

Indeed, I think that the document does a pretty good job of setting
forth operational impacts of filtering policies, and that (rather than
any specific filtering advice) is where most of the utility lies.

> cause implementation difficulties.

That would be a good thing to document. However, since the document
is aimed at operators, not equipment implementors, that would
probably be considered out of scope.

Thanks,

Mike Heard

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Nov 2018 03:36:48 -0300

On 26/11/18 19:49, Bob Hinden wrote:
> .. . . .

Most of the content of this document is about analyzing the implications
of each EH and option, to help folks with the aforementioned analysis --
regardless of what the outcome of scuh analysis is.

THanks,

---

From: Ole Troan <[email-masked]>
Date: Tue, 27 Nov 2018 09:28:06 +0100

Fernando, et al,

> regardless of what the outcome of scuh analysis is.

OK, that’s good to hear.
If that’s the case I would have liked to see more text on explaining the background, give reasons why filtering in the middle of the network is harmful (protocol extensions, ossification, violates Internet arc hitecture principles, packet parsing is costly, might required symmetric paths, etc).

A very unfortunate consequence of this work, is that the IETF appears to send a message that routers in the Internet is now expected to parse deep into packets and perform filtering actions. That’s a big change of the Internet architecture, and our view of layering.

A few comments on the actual advice:

The HBH advice (3.4.1.5) is fine and reflects that I think.
Likewise for the RH advice (3.4.2.5),  FH (3.4.3.5) and DestOpt (3.4.6.5).

* Protocol numbers 253/254

OLD:
3.4.10.5.  Advice

NEW:
3.4.10.5.  Advice
   Intermediate systems should permit packets that contain these EHs.

* New protocol types / extension headers

OLD
3.5.5.  Advice

NEW:
3.5.5.  Advice
   Intermediate systems should permit packets containing unknown IPv6
   EHs.

* MLD
4.3.7.5.  Advice
   Intermediate systems should discard packets that contain this option.
   Only in specific environments where support for RSVP, multicast
   routing, or similar protocols is desired, should this option be
   permitted.

Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links must generally be multicast capable.
A recommendation of a blanket kill of MLD can’t be right.
I don’t know how this recommendation should be formed, perhaps say something to separate MLD as used on-link with hop-limit = 1?

Unknown options types:

OLD:
4.4.5.  Advice

NEW:
4.4.5.  Advice
   Intermediate systems should not discard packets based on the presence
   of unknown options.

Ole

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 Nov 2018 10:12:30 +0000

Ole Troan wrote on 27/11/2018 08:28:
> A very unfortunate consequence of this work, is that the IETF appears
> to send a message that routers in the Internet is now expected to
> parse deep into packets and perform filtering actions. That’s a big
> change of the Internet architecture, and our view of layering.
quite the opposite: parsing deep inside packets has been a prerequisite 
of ipv6 EHs from the beginning and a serious row-back from this position 
was previously standardised in rfc7112. At least this puts us in a 
position that routers now only need to inspect a single packet to 
determine the full ipv6 header chain - previously you would have had to 
inspect all subsequent fragments too, which created the requirement for 
core devices to track packet state.

In practice, most routers will inspect a specific distance - hardware 
dependent - into a packet and will ignore anything following that. 
There's really no point building silicon which will do arbitrary length 
inspection because you end up optimising your hardware for corner cases.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Tue, 27 Nov 2018 07:42:21 -0300

Ole,

On 27/11/18 05:28, Ole Troan wrote:
>> Most of the content of this document is about analyzing the
>> implications of each EH and option, to help folks with the
>> aforementioned analysis -- regardless of what the outcome of scuh
>> analysis is.
> 
> OK, that’s good to hear. If that’s the case I would have liked to see
> more text on explaining the background, give reasons why filtering in
> the middle of the network is harmful (protocol extensions,
> ossification, violates Internet arc hitecture principles, packet
> parsing is costly, might required symmetric paths, etc).

As noted by a number of folks on this thread already, and as discussed
in https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops,
folks may have reasons to filter packets.

I don't think this document is the place to educate folks on whether
packet filtering is a good or a bad thing to do.

> parse deep into packets and perform filtering actions.

That's certainly not the message this document tries to convey, at least.

> That’s a big
> The HBH advice (3.4.1.5) is fine and reflects that I think. Likewise
> for the RH advice (3.4.2.5),  FH (3.4.3.5) and DestOpt (3.4.6.5).
> 
> OLD: 3.4.10.5.  Advice Intermediate systems should discard packets
> containing these EHs. Only in specific scenarios in which
> RFC3692-Style experiments are to be performed should these EHs be
> permitted.
> 
> NEW: 3.4.10.5.  Advice Intermediate systems should permit packets
> that contain these EHs.>
> OLD 3.5.5.  Advice Intermediate systems should discard packets
> containing unknown IPv6 EHs.
> 
> NEW: 3.5.5.  Advice Intermediate systems should permit packets
> containing unknown IPv6 EHs.

So far, the change proposed (and agreed upon) for unknown EHs, is:
"Operators should determine according to their own circumstances
    whether to discard packets containing unknown IPv6 EHs."

thoughts?

> * MLD 4.3.7.5.  Advice Intermediate systems should discard packets
> that contain this option. Only in specific environments where support
> for RSVP, multicast routing, or similar protocols is desired, should
> this option be permitted.
> 
> Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links
> must generally be multicast capable. A recommendation of a blanket
> kill of MLD can’t be right. I don’t know how this recommendation
> should be formed, perhaps say something to separate MLD as used
> on-link with hop-limit = 1?

For packets that you ND and such, wouldn't those packets be directed to
the router, rather than requested to be forwarded?

> Unknown options types:
> 
> OLD: 4.4.5.  Advice Enterprise intermediate systems that process the
> contents of IPv6 EHs should discard packets that contain unknown
> options.  Other intermediate systems that process the contents of
> IPv6 EHs should permit packets that contain unknown options.
> 
> NEW: 4.4.5.  Advice Intermediate systems should not discard packets
> based on the presence of unknown options.

Will do.

Thanks!

Fernando

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 27 Nov 2018 07:01:08 -0800

On Tue, Nov 27, 2018 at 2:12 AM Nick Hilliard <[email-masked]> wrote:
> of ipv6 EHs from the beginning

Just to be historically accurate, looking past the Hop-by-Hop Options
header (which is required to occur first) was not part of the IPv6
architecture at the beginning (RFC 2460 and predecessors).

> and a serious row-back from this position
> was previously standardised in rfc7112.

Which was acknowledgment of the reality that intermediate devices
do for many reasons inspect headers up to and including the upper
layer protocol header.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 27 Nov 2018 11:46:41 -0800

On Tue, Nov 27, 2018 at 12:28 AM Ole Troan wrote:
>> aforementioned analysis -- regardless of what the outcome of [such]
>> analysis is.
>
> OK, that’s good to hear.
>
> If that’s the case I would have liked to see more text on explaining
> the background, give reasons why filtering in the middle of the
> network is harmful (protocol extensions, ossification, violates
> Internet architecture principles, packet parsing is costly, might
> required symmetric paths, etc).
>

Ole, you are in effect saying that the proposed text for Section 3 in
https://mailarchive.ietf.org/arch/msg/opsec/5SF7Q1dNnikQ23sx0nn6Iah1hMU
should have the "operators should determine ..." text replaced by
"intermediate systems should permit ..." (note that I include a portion
of Section 3.1 dealing with the "unable to determine" case, in addition
to the cases you mention above).

I have to admit that I think the Internet would be better served by
the choices that you propose, but the current consensus position of the
IETF, as expressed in RFC 7045 (PS), acknowledges that some systems
will parse deep into packets to perform filtering actions.  In levying
requirement on systems that do so, it is neutral on what the default
action is in the above cases.  Since the status of the current draft is
informational, it seems inappropriate to push the advice one way or
another and thereby turn "MAY" into "should" or "should not."

Hence, I think "operators should determine ..." is probably the way to go.

To make the point about RFC 7045 steering the advice perfectly clear, I'd
actually like to see Section 2.3 expanded along the following lines:

---
OLD:
2.3.  Conventions

   This document assumes that nodes comply with the requirements in
   [RFC7045].  Namely (from [RFC7045]),

   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 recognise 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.

NEW:
2.3.  Conventions

   This document assumes that nodes comply with the requirements in
   [RFC7045].  Namely (from [RFC7045]),

   o  Any forwarding node along an IPv6 packet's path that forwards the
      packet for any reason SHOULD do so regardless of any extension
      headers that are present.  Exceptionally, if a forwarding node is
      designed to examine extension headers for any reason, such as
      firewalling, it MUST recognise and deal appropriately with all
      standard IPv6 extension header types and SHOULD recognise and deal
      appropriately with experimental IPv6 extension header types.

   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 recognise 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.

   o  Experimental IPv6 extension headers SHOULD be treated in the same
      way as standard extension headers, including an individually
      configurable discard policy.  However, the default configuration
      MAY drop experimental extension headers.

   o  Forwarding nodes MUST be configurable to allow packets containing
      unrecognised extension headers, but the default configuration MAY
      drop such packets.

Do you think that this would help?

> must generally be multicast capable. A recommendation of a blanket kill
> of MLD can’t be right. I don’t know how this recommendation should be
> formed, perhaps say something to separate MLD as used on-link with
> hop-limit = 1?

As I look at the advice for specific options more carefully, I find some
inconsistencies in the advice for certain cases, and the Router Alert
option (which is the one that applies to MLD) is one of those. My
general take for Hop-by-Hop options would be:

- If the "act" bits are set to "00" (ignore if you don't support it),
  then the advice should probably be to pass packets with that option
  unless there is vulnerable equipment that needs to be protected (e.g.,
  legacy routers that could be subject to DOS attacks from Router Alert)

- if the "act" bits are set to anything else, then the advice should
  probably be to drop such packets unless part of a domain where the
  feature is used (which is what RFC 8200 says anyway)

>    Intermediate systems should not discard packets based on the presence

I see that Fernando subsequently agreed to this, and I do not object;
but I do questions why unknown options would be permitted while the ones
set aside for RFC3692-style are to be filtered unless such an experiment
is known to be ongoing. Consistent advice seems to be in order for
these two cases.

I will follow up after doing a more thorough review of the specific
advice for each option.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 30 Nov 2018 06:46:26 -0800

On Tue, Nov 27, 2018 at 11:46 AM C. M. Heard wrote:
> As I look at the advice for specific options more carefully, I find
> some inconsistencies in the advice for certain cases [...].
>

Here is the promised/threatened follow up.

Section 3.4.1.2, Specification of the Hop-by-Hop Options extension
header: the deprecated Endpoint Identification Option (Type 0x8A)
should not be listed here. The reference cited for this option states
that it is a Destination Option to convey Nimrod EIDs.

Section 3.4.6.2, Specification of the Destination Options extension
header: the Performance and Diagnostic Metrics (PDM) Option should be
listed here. The reference is RFC 8250.

Section 4: A subsection documenting the PDM Option needs to be added.
Insofar as this is a standard option that is to be ignored by systems
that do not implement it, the advice "should not discard" would be an
appropriate default.

Section 4: The advice for specific options is not conditioned upon
whether they are found in a Hop-by-Hop Options header or a Destination
Options header. However, every defined option (other than padding and
experimental types) is intended to appear in only one of those headers.
At a minimum this needs to be pointed out. It may be appropriate to
advise that packets with defined options that appear within the "wrong"
header should be discarded.

Section 4: The advice for Router Alert (Type=0x05, Proposed Standard)
and SMF_DPD (Type=0x08, Experimental) is "should discard", while the
advice for Quick-Start (Type=0x26, Experimental) is "should not
discard". All of these Hop-by-Hop options are applicable only in limited
domains (RFC 6398 says so for Router Alert), and Quick Start and Router
Alert have substantial security implications. Thus, I have a hard time
wrapping my head around the fact that they do not all get the same
advice. How about something like "intermediate systems should discard
packets that contain this option, except when deployed in an
administrative domain where the option is in use" for all of them?

Section 4: Randall Atkinson has provided detailed comments on CALIPSO.
I support those comments. Note that systems compliant with RFC 8200
that do not implement RFC 5570 would simply ignore the option.

Sections 4.3.18.5 and 4.4.5: as I previously stated, I think the right
strategy is to remain neutral and say that operators should determine
according to their own circumstances whether to discard packets
containing these options. Reiterated only for completeness.

Unused reference: I-D.ietf-6man-hbh-header-handling

Mike Heard