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

["C. M. Heard" <[e-mail]>]

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 <[e-mail]>
Date: Thu, Oct 5, 2017 at 9:01 PM
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
To: Ron Bonica <[e-mail]>
Cc: OPSEC <[e-mail]>, Joe Touch <[e-mail]>, Bob Hinden <
[e-mail]>, Brian E Carpenter <[e-mail]>


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 <[e-mail]> 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:[e-mail]] *On Behalf Of *C. M. Heard
> *Sent:* Wednesday, October 4, 2017 11:08 PM
> *To:* OPSEC <[e-mail]>
> *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
>
>