Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03

From: "C. M. Heard" <[email-masked]>
Date: Wed, 4 Oct 2017 20:07:49 -0700

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.

>> 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://tools.ietf.org/html/rfc7872>].

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: Ron Bonica <[email-masked]>
Date: Thu, 5 Oct 2017 18:04:19 +0000

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:
>>> 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=>.
>>>
>>

   traffic that is expected to be received is allowed.  The advice in

   e.g. at the edge of an enterprise network.  The advice in this

   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.

1.) Advise operators of **transit routers** to be transparent to

   drop such packets.

Thanks and regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Oct 2017 11:28:15 -0700

> On Oct 5, 2017, at 11:04 AM, Ron Bonica <[email-masked]> wrote:
> 
A similar dimension includes the impact to the IPv6 standard, ie is the behavior permitted, allowed but discouraged, or in violation. 

Protecting yourself and other devices might not be valid if you break the protocol. Just because a router can’t do something isn’t a reason to say it’s ok not to.  

IPv6 is a ride with a minimum height requirement. 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Oct 2017 08:35:51 +1300

Ron, Mike,

Yes. I'd missed that point.

Regards
   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 5 Oct 2017 21:01:56 -0700

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:
>
>
>
> 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:
>
>
>
> 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
>
> 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
>
> *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
>
>
>
> >>> 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=>
> .
>
> >>>
>
> >>
>
>    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
>
>    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=>].
>
>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 5 Oct 2017 22:48:25 -0700

On 10/5/17 11:04, Ron Bonica 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:
> 
>  
> 

Traffic on a isp either the isp's traffic or a customers (customer is
transitive, a customer of a customer is customer traffic). traffic which
neither to a customer or the isp is party to unwanted, whether it's
there due to malice or intention.

what services one offers to a customer seems entirely like a contractual
detail.

strictly speaking the destination of a packet may not be the destination
address in the ip header as when the TTL is lowered or when hop by hop
options are employed.

> 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
> 
> *From:*OPSEC [mailto:[email-masked]] *On Behalf Of *C. M. Heard
> <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=>.
> 
>>>> 
> 
>>> 
> 
>    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
> 
> <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
> 
> That is antithetical to the mission of a **/_transit router_/**, which
> 
> transport protocols. If these things are blocked by **/_transit routers_/**
> 
> 1.) Advise operators of **/_transit routers_/** to be transparent to
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Oct 2017 18:15:36 +0000

Hi Joel,

I was thinking about ISPs who are transit providers. So, the traffic actually belong to your customers' customers.

                                                                                 Ron

> 
> Traffic on a isp either the isp's traffic or a customers (customer is transitive, a
> customer of a customer is customer traffic). traffic which neither to a
> customer or the isp is party to unwanted, whether it's there due to malice or
> intention.
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 20 Oct 2017 10:30:06 -0300

> -          To protect downstream devices

We're kind of tackling item #2 above, in the hopes of improving the
situation described in RFC7872. -- this is expected to be a default
permissive approach.

For item #1, it would probably boil down to block anything you don't use
(i.e., way more aggressive approach)-- but that would be a different
project.

Thoughts?

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