Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Dec 2018 15:17:33 -0500

On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <[email-masked]> wrote:

> Take that to the standards wg. Don’t stick your head in the sand and try
> to do an end run in ops. And don’t call any of this a security issue that
> it isn’t.
>
>
>
Joe, I think one of the 3 pillars of security is: "Availability" (the other
two are 'Confidentiality' and 'Integrity')

I think the point that Nick and Gert are outlining is that if the case is
that the hardware available will have no fast-path processing for packets
with obtuse patterns or sets of extension headers those packets will get
sent to the control-plane (slow-path). That slow-path being congested will
cause availability problems.

Actually, whether or not the control-plane fails under such load may not
even matter, if the rate-limiting of the packets here is such that (as gert
said) all but a trickle of the interesting packets are forwarded.

A solution might be to have a mode where  a router may just ignore all
headers except the src/dst-ip and simply forward all packets, trusting that
the conversing adults will sort out problems with unknown/new/experimental
headers or with a tortured ordering of headers (for instance). This will
also cause some operational headaches: "Please drop all traffic toward ipX
with protoY and dst-port Z" but perhaps it's still acceptable to some folk
to operate like this?

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 17:10:03 -0800

> On Dec 4, 2018, at 12:17 PM, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 
> 
> 
> On Tue, Nov 27, 2018 at 5:40 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> Take that to the standards wg. Don’t stick your head in the sand and try to do an end run in ops. And don’t call any of this a security issue that it isn’t. 
> 
> 
> 
> Joe, I think one of the 3 pillars of security is: "Availability" (the other two are 'Confidentiality' and 'Integrity’)

It is...

>  
> I think the point that Nick and Gert are outlining is that if the case is that the hardware available will have no fast-path processing for packets with obtuse patterns or sets of extension headers those packets will get sent to the control-plane (slow-path). That slow-path being congested will cause availability problems.

If that happens, the packets with these headers can easily be throttled - thus avoiding a security issue.

However, what you’re basically saying is that “it is a security risk to send packets to a router because it might have to do work”. Yeah, big surprise. Either do the work or limit the impact. But that’s not the kind of security risk we associate with availability - a good example of which would be that sending a single packet would cause the work of 1000.

But none of that is happening here.

> 
> Actually, whether or not the control-plane fails under such load may not even matter, if the rate-limiting of the packets here is such that (as gert said) all but a trickle of the interesting packets are forwarded.

But then that’s not a security problem.

> 
> A solution might be to have a mode where  a router may just ignore all headers except the src/dst-ip and simply forward all packets, trusting that the conversing adults will sort out problems with unknown/new/experimental headers or with a tortured ordering of headers (for instance). This will also cause some operational headaches: "Please drop all traffic toward ipX with protoY and dst-port Z" but perhaps it's still acceptable to some folk to operate like this?

That works only for HBH options of type 00. Others require particular actions when not supported.

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Dec 2018 23:11:54 -0500

On Tue, Dec 4, 2018 at 8:10 PM Joe Touch <[email-masked]> wrote:

> Joe, I think one of the 3 pillars of security is: "Availability" (the
> other two are 'Confidentiality' and 'Integrity’)
>
>
> It is...
>
>
So, perhaps I'm not expressing my point properly... I'll try again in a
different way.
I don't think that they can be meaningfully throttled, no. I think that
they will 'always' be throttled if they can not go on the fast-path,
because the difference between 'fast-path' and 'not fast-path' is ~9 orders
of magnitude. There's not a sane "welp, 50% of bandwidth" or anything like
that possible in this scenario. Except: "meh, just pass along all packets
unchecked, no HBH checking/evaluation nothing".

> However, what you’re basically saying is that “it is a security risk to
> send packets to a router because it might have to do work”.
>

I don't think that's what I said, what i said is that loss of control-plane
functionality is a security risk, because you lose availability.
Yes, that's not a 'big surprise', it's just a fact of life on the public
network, to operate a network connected to the public you don't let things
poke at your control-plane.

> Yeah, big surprise. Either do the work or limit the impact. But that’s not
> the kind of security risk we associate with availability - a good example
> of which would be that sending a single packet would cause the work of 1000.
>
>
'you' (the royal, not you in particular) may not consider loss of
availability to be a security concern, but I expect all network operations
folk to consider it such.
I expect that, by and large, folk who operate networks aren't trying to
make 'your' (royal again) life hard here, 'we' (royal) are just saying:
"there's a tradeoff, let's be sure we agree what the costs are going to be"

> But then that’s not a security problem.
it's a loss of availability for the users of the expected packets. It's not
really "my" concern, unless I'm trying to do some new protocol thingy.

> actions when not supported.
can you expand on this some?

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Dec 2018 20:32:11 -0800

> can you expand on this some?

Nobody deprecated the flags that require HBH options to be processed or dropped if not supported. 

And if there is a security risk to the control plane, it is using that place for slow path processing without properly limiting its use of shared resources. 

This idea that packets processed as intended are a security risk is like saying big packets are a security risk to small packets. It may be a bad design but it doesn’t mean such packets are inherently a security risk. 

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Dec 2018 17:46:14 +1300

On 2018-12-05 17:32, Joe Touch wrote:
> 
> 
> On Dec 4, 2018, at 8:11 PM, Christopher Morrow <[email-masked] <mailto:[email-masked]>> wrote:
> 

Intentionally. If a forwarding node is transparent to HbH options,
it is not looking at those flags. If it is looking at HbH options,
it will obey those flags. Why is that a problem?

    Brian

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 5 Dec 2018 00:37:25 -0500

> dropped if not supported.
Oh, you are highlighting the difference between the 'theory' and
'practice'. ok.

> And if there is a security risk to the control plane, it is using that
> place for slow path processing without properly limiting its use of shared
> resources.
>
>
sure, that's a fine point. Doesn't actually change the state of the world
where: "If your control-plane collapses, you have an unavailability event"
which is a security problem. It's also an operational problem and likely a
cost problem :( but... maintaining availability is part of what a good isp
security group will do for the isp.

> This idea that packets processed as intended are a security risk is like
> saying big packets are a security risk to small packets. It may be a bad
> design but it doesn’t mean such packets are inherently a security risk.
>
>
it seems weird that in this case 'this is not a security problem', but
sending a packet that breaks some assumptions in the applications at the
end points and causes unexpected problems with the end point(s) (say sql
injection in a web server or breaking some ssh server through some
vulnerability) is a security problem?

Instead of rat-holing on this point though, don't you actually care that
the end points can do their work regardless of the network devices? (smart
edges, dumb core ... that sort of thing)

-chris

---

From: Mark Andrews <[email-masked]>
Date: Wed, 5 Dec 2018 17:14:11 +1100

> On 5 Dec 2018, at 4:37 pm, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 
> Oh, you are highlighting the difference between the 'theory' and 'practice'. ok.
>  
> sure, that's a fine point. Doesn't actually change the state of the world where: "If your control-plane collapses, you have an unavailability event" which is a security problem. It's also an operational problem and likely a cost problem :( but... maintaining availability is part of what a good isp security group will do for the isp.

And the correct thing to do is to FIX THE BROKEN PRODUCT.  

If a ssh implementation is broken we don’t drop SSH packets.  We fix the broken implementation of ssh.

If there is a SQL injection problem we fix that problem rather than dropping HTTP
and HTTPS packets.

If a router can’t handle all legal packets at line rate the router needs to fixed.

Punting stuff to be processed by the same CPU that process the routing table worked
for a while.  There is no rule that says routers can’t have multiple CPUs some of
which are dedicated to handling the control plane and other that deal with everything
else that has been punted.  Design the router so that the control plane doesn’t get
overloaded and the exceptional packet get handled.

Generating PTB’s shouldn’t be seen as exceptional.  Fragmented packets shouldn’t be
seen as exceptional. 

> it seems weird that in this case 'this is not a security problem', but sending a packet that breaks some assumptions in the applications at the end points and causes unexpected problems with the end point(s) (say sql injection in a web server or breaking some ssh server through some vulnerability) is a security problem?

> Instead of rat-holing on this point though, don't you actually care that the end points can do their work regardless of the network devices? (smart edges, dumb core ... that sort of thing)
> 
> -chris

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Dec 2018 01:00:30 -0600

> Generating PTB’s shouldn’t be seen as exceptional.  Fragmented packets

Even if agree that is the way routers SHOULD be designed today. I'm not
aware of any that are designed that way.

Further, even if all new router shipped from today on were designed that
way, which they are not. It would easily take a decade or more for all the
old legacy routers to fade away on the Internet. Those are facts we have to
work with.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 04:13:47 -0800

On Dec 4, 2018, at 11:00 PM, David Farmer <[email-masked]> wrote:

> Even if agree that is the way routers SHOULD be designed today. I'm not aware of any that are designed that way. 
> 
> Further, even if all new router shipped from today on were designed that way, which they are not. It would easily take a decade or more for all the old legacy routers to fade away on the Internet. Those are facts we have to work with.  

Then THAT is the security issue.  Not the packets that cause a broken implementation to have problems.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 04:16:18 -0800

> it will obey those flags. Why is that a problem?

What exactly does ‘transparent to HbH options mean’ if not ‘not supported’?

In that case, the flags have exactly no meaning anywhere. But they’re not deprecated.

That makes no sense at all.

Joe

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 13:21:42 +0100

Hi,

> Then THAT is the security issue.  Not the packets that cause a broken implementation to have problems.

Can we declare folks at IETF that have no idea about operational realities
to be a security issue?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 04:31:17 -0800

> On Dec 5, 2018, at 4:21 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

As long as we can do the same for operators that blame protocols for vendor issues.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Dec 2018 12:48:28 +0000

Joe Touch wrote on 05/12/2018 12:13:
> Then THAT is the security issue..  Not the packets that cause a broken 
> implementation to have problems.

In this specific case:

1. the protocol definition states that HBH packets should be processed 
per intermediate node.

2. even small routers can now handle terabits of data plane throughput.

What do we do?

1. declare that these routers should be able to process terabits of HBH 
packets (or experimental EHs because we don't know whether experimental 
EHs are required to be processed HBH or by end points only).

2. formally drop the requirement for intermediate routers to process HBH 
headers

3. build routers which will take some HBH headers at low packet rates 
and drop the rest (+ update rfcs to make this formally compliant).

4. something else.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Dec 2018 13:02:34 +0000

Christopher Morrow wrote on 04/12/2018 20:17:
> I think the point that Nick and Gert are outlining is that if the case 
> is that the hardware available will have no fast-path processing for 
> packets with obtuse patterns or sets of extension headers those packets 
> will get sent to the control-plane (slow-path). 

in this case, yes, but there is a more general issue, namely that 
protocols are often written without the benefit of hindsight or 
experience.  Implementation of specifications will usually throw up 
problems and it almost never happens that a protocol specification is 
defined so jesuitically that ambiguity doesn't happen.

Looking at this from another angle, engineering is about optimisation of 
conflicting input parameters.  The IETF needs to understand how and why 
this happens, because it can provide useful feedback on the rfcs that 
are churned out, ranging from ambiguity to gap analysis to impracticality.

Nick

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 05:12:48 -0800

The choices below don’t include declaring this a security risk and turning it off.

If you want to change the standard, do so. But this isn’t a step isn’t that direction. And the previous attempts only show why IPv6 has adoption problems.

The standard can still be changed, but regardless, this simply is not a security issue and shouldn’t be sold as one.

Joe

> On Dec 5, 2018, at 4:48 AM, Nick Hilliard <[email-masked]> wrote:
> 
>> Then THAT is the security issue..  Not the packets that cause a broken implementation to have problems.
> 
> In this specific case:
> 
> 1. the protocol definition states that HBH packets should be processed per intermediate node.
> 
> 1. declare that these routers should be able to process terabits of HBH packets (or experimental EHs because we don't know whether experimental EHs are required to be processed HBH or by end points only).
> 
> 2. formally drop the requirement for intermediate routers to process HBH headers
> 
> 3. build routers which will take some HBH headers at low packet rates and drop the rest (+ update rfcs to make this formally compliant).
> 
> 4. something else.
> 
> Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 14:38:21 +0100

Hi,

> As long as we can do the same for operators that blame protocols for vendor issues.

If a protocol cannot be implemented in a way that can be paid by real world 
participants, it's not a vendor issue.

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 05:45:02 -0800

Vendors are not required to lie when claiming IPv6 support.

> On Dec 5, 2018, at 5:38 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 05:48:43 -0800

> On Dec 5, 2018, at 5:02 AM, Nick Hilliard <[email-masked]> wrote:
> 
> there is a more general issue, namely that protocols are often written without the benefit of hindsight or experience

Yet we had that experience by 8200 and did not remove HBH options or their flags.

I agree there is a problem her, but it is not a security problem.  We cannot continue to claim that the options exist if they can be silently ignored at will while being marked Sa ‘drop if not supported’. 

Fix the problem. But let’s not perpetuate the lies.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Dec 2018 13:54:26 +0000

Joe Touch wrote on 05/12/2018 13:12:
> If you want to change the standard, do so. But this isn’t a step
> isn’t that direction. And the previous attempts only show why IPv6
> has adoption problems.
> 
> The standard can still be changed, but regardless, this simply is not
> a security issue and shouldn’t be sold as one.
If J Random Hacker in his mom's basement can launch an attack which 
takes down your network core because your management planes can't handle 
1Tbit, or more realistically 10gbit, of HBH packets, then that is 
categorically a network security issue, even if it is a secondary effect.

Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 14:57:23 +0100

Hi,

> Vendors are not required to lie when claiming IPv6 support.

So you prefer that vendors just do not deliver IPv6 at all?

Let me repeat that: what you want will not be paid by the marketplace.

Chained EHs are a relict from a time when everybody was nice and 
cooperative, bandwith was sparse, routers used CPUs to forward packets,
and money came from governments to research networks in huge amounts.

This is not today's Internet anymore.

You can accept that or not, but nothing you can say will magically make 
the necessary amount of money and development resources (let alone 
"interest") appear to build and deploy routers that can do what you want 
all across the Internet.

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 06:30:49 -0800

> On Dec 5, 2018, at 5:54 AM, Nick Hilliard <[email-masked]> wrote:
> 
> If J Random Hacker in his mom's basement can launch an attack which takes down your network core because your management planes can't handle 1Tbit, or more realistically 10gbit, of HBH packets, then that is categorically a network security issue, even if it is a secondary effect.

So every SNMP packet is an attack as well? As is every routing packet?

A security issue is created when a packet can cause *disproportionate* load. Otherwise it’s just called load.

The security issue is the implementation not throttling such packets to avoid having 10G of them shutting down the control plane. Yes, that’s a security issue, but it’s not the fault of the HBH packets.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 5 Dec 2018 14:31:42 +0000

As far as I see, this thread illustrates that there is a significant gap 
between the protocol designers, the protocol implementers and the 
protocol users. This is something that needs to be addressed if the IETF 
is not to loose its reason to exist.

Best regards

Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 06:32:33 -0800

> On Dec 5, 2018, at 5:57 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

I’m only saying:
- implement what IP requires or don’t call it IP
- if we can’t implement what IP requires, then change the STANDARD

But this isn’t an operational issue and it isn’t a security issue.

> have you enabled IPv6 on something today...?

No, but you haven’t either.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 06:35:46 -0800

There are gaps here, but there in other places:
- the gap between what a protocol needs and what is in the spec
	if HBH isn’t needed and can’t be implemented, remove them
	if HBH is needed, then we need to find a way to have the requirement mean something

A similar problem exists with fragmentation. NIMBYisnm won’t fix it, nor will operator declarations, nor false security declarations.

I don’t have a problem with fixing the STANDARD. I have a problem with an end-run in ops.

Joe

> On Dec 5, 2018, at 6:31 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> As far as I see, this thread illustrates that there is a significant gap between the protocol designers, the protocol implementers and the protocol users. This is something that needs to be addressed if the IETF is not to loose its reason to exist.
> 
> Best regards
> 
> Stewart
> 
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Dec 2018 15:53:35 +0100

Gert,

> "interest") appear to build and deploy routers that can do what you want 

This is the exact reason we have layering in the Internet protocols.
IPv6 routers are not meant to parse further into packets then the IPv6 header (with one exception (1)).

That network devices find it hard to parse deep into user’s traffic is a feature.
I find the argument that we should then change upper layer protocols to accommodate that, hard to digest.

I agree with Joe, this isn’t a security issue.

Ole

(1) The exception is the HBH header which is intended as a hook for forwarding devices to do further processing of the packet.
To Joe’s point, RFC8200 specifies that the header is to be ignored unless the device is specifically configured to handle the header.
There is obviously no security risk for the router itself in ignoring the NH=0 and forwarding the packet.
There might be a risk if and when an actual HBH option is specified. But that specification should have security considerations.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Dec 2018 15:17:19 +0000

> So every SNMP packet is an attack as well? As is every routing

snmp packets are either directed at a router or else directed through a 
router.  If they are directed at a router, then they will be filtered / 
rate-limited on the data plane before they ever hit the management plane 
because no-one with half a brain cell is going to let their dfz core 
router open to snmp abuse.  If they're pure data plane packets, then the 
management plane will never hear about them in the first place.

Routing protocol packets are considered to be a potential attack vector, 
but again are subject to the limitation that if they are generated by 
third parties (i.e. unrelated parties, as compared to directly connected 
second parties who might have a legitimate reason for sending specific 
types of routing protocol packets - and not others), then they are 
routinely filtered out and/or rate limited before being forwarded to any 
router management plane.  In any event, they are also subject to 
policers / shapers before hitting the management planes, regardless of 
source.

Packets with HBH EHs are fundamentally different in this regard because 
they are data plane packets which are mandated by protocol to be 
processed on the management plane on every forwarding plane that they 
hit, even if this isn't their destination point.  This is what's 
different and what is so dangerous about HBH packets, and why they need 
the sort of specific consideration that doesn't apply to most other 
types of packets.

Thankfully rfc8200 recategorised them so that intermediate nodes are no 
longer required to process them.

> A security issue is created when a packet can cause*disproportionate*
> load. Otherwise it’s just called load.

This is exactly what we are talking about: terabits of data-plane 
traffic hitting a management plane because the protocol says that that's 
what needs to happen.

Terabits of data-plane traffic hitting a management plane which can only 
handle kilobits or megabits of data is  disproportionate.  You can 
trivially assess the level of disproportionality by noting the orders of 
magnitude in the numbers.  Is 6 orders of magnitude disproportionate 
enough? One order of magnitude is enough for me.  Trashed control planes 
are trashed, regardless of the scale of the trashing.

> The security issue is the implementation not throttling such packets
> to avoid having 10G of them shutting down the control plane. Yes,
> that’s a security issue, but it’s not the fault of the HBH packets.

It's a direct consequence of what the defining protocol used to say, 
except that vendors had more sense than to take protocols literally, and 
operations people have more sense than to leave their networks open to 
catastrophic abuse vectors just because it was written in a formal 
specification.

Common sense is, thankfully, one of the optimisation considerations 
applied when dealing with the conflicting standpoints presented by 
protocols and reality.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Dec 2018 15:28:00 +0000

> is not to loose its reason to exist.

yes, completely.  There has always been a tension in this area.

The tension isn't necessarily a bad thing, btw. It reminds us that this 
is important.

Nick

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 17:44:27 +0100

Hi,

On Wed, Dec 05, 2018 at 06:32:33AM -0800, Joe Touch wrote:
> No, but you haven???t either.

How would you know?  I turn on IPv6 on things all day.

I'm an operator, after all :-)

(That my routers - thankfully - do not agree to certain parts of the
IPv6 specification doesn't mean my endpoints are not proper IPv6 endpoints)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 17:45:59 +0100

HI,

> > and money came from governments to research networks in huge amounts.
[..]
> That network devices find it hard to parse deep into user???s traffic is a feature.

Ole, you've worked for a vendor long enough, and understand terms like
"rate limiting" and "hardware".

Please.

Gert Doering
        -- NetMaster

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Dec 2018 09:10:22 -0800

> takes down your network core because your management planes can't
> handle 1Tbit, or more realistically 10gbit, of HBH packets, then that
> is categorically a network security issue, even if it is a secondary
> effect.

security failure is almost always a secondary effect.  we usually do not
intentionally design in specific security vulnerabilities.  well, RH0 i
guess; every rule has exceptions.  but we don't have to knowingly add an
other.

perhaps there is a signal here where folk who operate the network worry
about the operational consequences of ipv6 protocol purism.  perhaps we
have seen this before.  i suspect we will see it again.

> What do we do?
> 
> 1. declare that these routers should be able to process terabits of
>    HBH packets (or experimental EHs because we don't know whether
>    experimental EHs are required to be processed HBH or by end points
>    only).

and i presume i can print this rfc on paper and put it in the floppy
drive slot of my routers and they will suddenly be able to process
terabits of hbh on the slow path.  cool!

> 2. formally drop the requirement for intermediate routers to process

we do not really have an actually deployable choice other than this.

>    and drop the rest (+ update rfcs to make this formally compliant).

and put this into my routers' floopy slot too?  we're talking EXISTING
ROUTERS that are just not going to be able to make this happen.

if this was an ideal world, i would focus on war, hunger, the resurgence
of fascism, etc.  an undeployable protocol requirement is pretty far
down my priority list.

randy

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Dec 2018 18:57:28 +0100

> "rate limiting" and "hardware”.

You are creating the “perceived” security problem yourself, by requiring processing deeper into the packet than is required.
Just comply with RFC8200. As long as a router is not configured to process any HBH options, it can ignore the header.
You seem to think HBH still means “punt to software”. If it ever meant that.

There’s no need for rate-limiting for not processing HBH obviously.

Cheers,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 5 Dec 2018 18:08:07 +0000

> There’s no need for rate-limiting for not processing HBH obviously.
Of course it still needs to step through them all to do ECMP even if 
they are all disabled. Of course here it is only looking for two values 
(TCP or UDP).

If it has to look at any it has a much more complex set of tests, or a 
large vector table  given the way the EH space is fragmented.

Stewart

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 19:08:55 +0100

Hi,

On Wed, Dec 05, 2018 at 06:57:28PM +0100, Ole Troan wrote:
> You are creating the ???perceived??? security problem yourself, by requiring processing deeper into the packet than is required.
> You seem to think HBH still means ???punt to software???. If it ever meant that.
> 
> There???s no need for rate-limiting for not processing HBH obviously.

I *must* be able to look at the protocol field of packets coming in on
our borders (see detailed description on our rate-limiting rules in 
another mail of today).  If there are EHs in the way so our routers' 
hardware cannot decide if this is a TCP or UDP packet, these packets 
go down the drain.

And I'm fairly sure you understand that operational reality, so I'm not
sure what point you are making.

(It's not just HBH.  EHs are fundamentally incompatible with today's
reality)

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Dec 2018 19:58:09 +0100

> On 5 Dec 2018, at 19:08, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

My point is that if you are worried about the processing cost for routers of EHs and HBH specifically, then this “security” draft makes that much worse than what’s specified in rfc8200. 

Cheers 
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Dec 2018 20:12:06 +0100

Hi,

On Wed, Dec 05, 2018 at 07:58:09PM +0100, Ole Troan wrote:
> My point is that if you are worried about the processing cost for routers of EHs and HBH specifically, then this ???security??? draft makes that much worse than what???s specified in rfc8200. 

I see.

I do not particularily care about this draft, tbh, I just tried to bring
insight into operational realities into the discussion.

Other people are much better versed at writing nice documents that vendors
can then ignore.

Gert Doering
        -- NetMaster

---

From: Christian Huitema <[email-masked]>
Date: Wed, 5 Dec 2018 11:26:38 -0800

> hardware cannot decide if this is a TCP or UDP packet, these packets 

Gert, I think that you are actually pointing at a significant issue with
the draft.

The draft goes into an evaluation of "security issues", without actually
explaining some basic assumptions. For example, it is hard to believe
that a router forwarding too many packets of any kind will cause an
issue for the security *of that router*. But on the other hand there is
a widely distributed practice of network equipment attempting to provide
differential treatment of packets based on protocol types and port
numbers. That practice is not acknowledged in the RFC that specify IPv6.
In fact, the IPv6 design assumes that routers only look at the address
and flow-id fields. This design is actually a departure from IPv4, whose
header format makes it easy to skip over the option field and assess the
"five tuple".

The draft *implicitly* assumes that routers will try to find the
protocol and port numbers "because of security reasons", but never
actually delineates these reasons. I think the discussion would be much
more productive if the draft started by explaining why network managers
believe that access to the "five tuple" is essential for a variety of
reasons, many of which are only tangentially related to "security". At
that point we can have a discussion between protocol designers assuming
that the network routers shall only look at IPv6 addresses and that
everything else is end-to-end on one side, and on the other side network
managers explaining why they need access to the payload type and port
numbers.

My personal preferences on the subject are not very relevant, and I
could actually line up arguments for both sides of that debate. But I
believe that getting to a resolution there would be much better than
arguing piecemeal over this or that end-to-end option.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 09:04:48 +1300

> What exactly does ‘transparent to HbH options mean’ if not ‘not supported’?

It means a forwarding node that uses the exception added by RFC7045 and simply
doesn't even look for an HbH header. The flag bits are invisible and irrelevant
to such a node. The flag bits apply as defined for a forwarding node that *does*
process HbH options, so they certainly should not be deprecated.

   Brian

> .

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 14:50:58 -0800

> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> process HbH options, so they certainly should not be deprecated

Do why bother with “drop if not supported” if not supported can mean silently skipped over?

Or the other variants?

They’re now meaningless but required to support. You don’t see the contradiction?

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 14:53:52 -0800

+1

> On Dec 5, 2018, at 11:26 AM, Christian Huitema <[email-masked]> wrote:
> 
> 
> Gert, I think that you are actually pointing at a significant issue with the draft. 
> 
> The draft goes into an evaluation of "security issues", without actually explaining some basic assumptions. For example, it is hard to believe that a router forwarding too many packets of any kind will cause an issue for the security *of that router*. But on the other hand there is a widely distributed practice of network equipment attempting to provide differential treatment of packets based on protocol types and port numbers. That practice is not acknowledged in the RFC that specify IPv6. In fact, the IPv6 design assumes that routers only look at the address and flow-id fields. This design is actually a departure from IPv4, whose       header format makes it easy to skip over the option field and assess the "five tuple".
> 
> The draft *implicitly* assumes that routers will try to find the protocol and port numbers "because of security reasons", but never actually delineates these reasons. I think the discussion would be much more productive if the draft started by explaining why network managers believe that access to the "five tuple" is essential for a variety of reasons, many of which are only tangentially related to "security". At that point we can have a discussion between protocol designers assuming that the network routers shall only look at IPv6 addresses and that everything else is end-to-end on one side, and on the other side network managers explaining why they need access to the payload type and port numbers.
> 
> My personal preferences on the subject are not very relevant, and I could actually line up arguments for both sides of that debate. But I believe that getting to a resolution there would be much better than arguing piecemeal over this or that end-to-end option.
> 
> -- Christian Huitema
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 13:05:19 +1300

> Do why bother with “drop if not supported” if not supported can mean silently skipped over?

Ah. I assume that you are not referring to RFC7045 + RFC8200 (the standards)
but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5 , which is quite nuanced. All I can say is that *if* we are going to issue guidance for security-based filtering of HbH headers, that advice seems realistic. It does include this:
   ...  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.
Frankly I don't think you'd find any operational security practitioner who disagrees with this.

Whether we *should* issue guidance for security-based filtering of HbH headers is a broader question. All I would say is that if we don't, then either somebody else will, or default-deny will remain as the most common practice.

  Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 16:17:32 -0800

I am referring to the standards. They’re in direct conflict. 

> On Dec 5, 2018, at 4:05 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 13:34:34 +1300

On 2018-12-06 07:08, Stewart Bryant wrote:
> they are all disabled. 

No it doesn't. That's what the flow label, in a fixed position early in the IPv6 header, is for. A line speed IPv6 router has no need to look at the layer 4 header, even if it's doing both diffserv and ECMP. Looking at transport headers is an IPv4 concept.

The topic here is not really IPv6 routers. It's devices whose job in life includes filtering. They might also be routers.

> Of course here it is only looking for two values 
> (TCP or UDP).

You too just killed SCTP ;-)

> large vector table  given the way the EH space is fragmented.

Frankly doing it without a network processor seems wrong. You can't expect
an ASIC or FPGA based device to handle the EH structures.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 13:38:24 +1300

> I am referring to the standards. They’re in direct conflict. 

I see no conflict between RFC8200 and RFC7045. RFC2460 is obsolete, so it doesn't matter.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Dec 2018 13:48:29 +1300

> header format makes it easy to skip over the option field and assess the

And I don't think that is an oversight. The *definition* of "router"
for IPv6 is "a node that forwards IPv6 packets not explicitly addressed
to itself." No mention of filtering, classification, admission control,...

> managers explaining why they need access to the payload type and port

That seems to define a class of "routers" that have supplementary
functions that are not part of routing. And, surprise, these functions
cannot be satisfied by only inspecting the first 40 bytes of the packet.

I agree that this could usefully be made very clear in the draft.

> arguing piecemeal over this or that end-to-end option.

I doubt that we can ever resolve this, but we can document it.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 5 Dec 2018 23:06:29 -0300

> If there is a SQL injection problem we fix that problem rather than dropping HTTP

Bad analogy there. If you are vulnerable to SQL injection problems, you
just stop trasting whatever crap is being sent to your app, and enforce
checks on the input, usually based on what you'd expect or what one
might consider "sane". -- some extremists might call some of that a
deviation from "be liberal in what you accept".

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Dec 2018 00:33:13 -0300

> managers explaining why they need access to the payload type and port

We did that in gont-v6ops-ipv6-ehs-packet-drops, but I agree that that
is not explicitly mentioned in the document. I wouldn't rehash the I-D
here, but simply note something along the lines of:

---- cut here ----
While not strictly part of the functionality in of a router, it is a
common practice for network equipment attempting to provide differential
treatment of packets based on protocol types and port, for reasons such as:

 o ECMP and Hash-based Load-Sharing

 o Enforcing infrastructure ACLs

 o DDoS Management and Customer Requests for Filtering

While the IPv6 standard assumes that routers only look at the address
flow-id fields, the aforementioned operational requirements results in
the aforementioned devices having to parse the IPv6 extension header
chain. In such scenarios, extension headers poses a challenge to these
devices, which have implementation limits in the lengths of the
extension chains they are able to process, or the performance with which
they can process the EH chains. In that sense, the IPv6 design is
actually a departure from IPv4, whose header format makes it easy to
skip over the option field and assess the "five tuple".
[gont-v6ops-ipv6-ehs-packet-drops] contains further discussion of these
issues.
---- cut here ----

Thoughts?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 20:57:22 -0800

Then explain what it means to mark an EH as ‘drop if not supported’ if it isn’t dropped where - well - NOT SUPPORTED.

Or ICMP where not supported. 

Or any of those values. 

I’m talking about a conflict in the text of 8200 - which has those fields as required to support - and 7045, which says they can be silently ignored. 

> On Dec 5, 2018, at 4:38 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Dec 2018 00:01:55 -0500

On Wed, Dec 5, 2018 at 11:57 PM Joe Touch <[email-masked]> wrote:

> Then explain what it means to mark an EH as ‘drop if not supported’ if it
> isn’t dropped where - well - NOT SUPPORTED.
>
> I’m talking about a conflict in the text of 8200 - which has those fields
> as required to support - and 7045, which says they can be silently ignored.
>
>
How is it, for example, different to put ipv6 packets into an MPLS path
doing nothing along 'many' hops (except forwarding the packets along), and
then once you pop out of the tunnel start processing the packet as you
(joe) would want.

Versus just ignoring the offensive EHs along the same path outside of MPLS
and then dealing with them after you pop out the last router in the chain?

In my mind this is what Brian (and me and apparently 8200) are proposing:
"edge site sends packet with offensive header(s) to ISP, ISP ignores EHs
and forwards across (potentially many) routers/as-hops and far end edge
site gets the packet and parses EHs to it's hearts content."

> >>> but to
> https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5
> , which is quite nuanced. All I can say is that *if* we are going to issue
> guidance for security-based filtering of HbH headers, that advice seems
> realistic. It does include this:
> >>>  ...  Finally, when
> >>> Whether we *should* issue guidance for security-based filtering of HbH
> headers is a broader question. All I would say is that if we don't, then
> either somebody else will, or default-deny will remain as the most common
> practice.
> >>>
> >>> Brian
> >>>
> >>>> Or the other variants?
> >>>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 21:22:15 -0800

> On Dec 5, 2018, at 9:01 PM, Christopher Morrow <[email-masked]> wrote:
> 
> How is it, for example, different to put ipv6 packets into an MPLS path doing nothing along 'many' hops (except forwarding the packets along), and then once you pop out of the tunnel start processing the packet as you (joe) would want.

The hopcount doesn’t get decremented by L2. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Dec 2018 21:31:32 -0800

Additionally, packets don’t emerge from different mole endpoints or are IP  processed in any way. The mold acts like a wire, which is fine. That can be done by IP tunnels too. But not routers that converge and diverge packets. 

Again, if HBH headers are meaningless and not needed, then go through the proper process and remove them from IPv6. If not, stop trying to hobble this protocol to the point where we all realize why nobody wants to use it. 

> On Dec 5, 2018, at 9:22 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Dec 2018 01:24:17 -0500

> The hopcount doesn’t get decremented by L2.
you are assuming that the mpls path has 'no_decrement_ttl' set though?

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 6 Dec 2018 01:28:02 -0500

On Thu, Dec 6, 2018 at 12:31 AM Joe Touch <[email-masked]> wrote:

> Additionally, packets don’t emerge from different mole endpoints or are
> IP  processed in any way. The mold acts like a wire, which is fine. That
> can be done by IP tunnels too. But not routers that converge and diverge
> packets.
>
>
this is patently incorrect. but also not particularly important I suppose.

> Again, if HBH headers are meaningless and not needed, then go through the
> proper process and remove them from IPv6. If not, stop trying to hobble
> this protocol to the point where we all realize why nobody wants to use it.
>
>
I think everyone here is actually happy to see v6 progress.
I think the option to ignore if you are an adult is a fine option, and
actually helps deploy v6 further/faster/more.

I do agree that IF the end systems expect their core networking (across the
wider internet, not in their campus deployment) to 'do something' to the
packets aside from 'forward' ... they are going to be sad. I don't know how
much processing (aside from 'forward') matters though on the wider
internet. What L3 does with my packet EXCEPT deliver it .. is unimportant
to me, please just deliver my packet(s).

note I'm not trying to be intentionally combative, just attempting to say:
"the best answer for the user here is PROBABLY to just have the core ignore
all the EH business entirely"

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 10:00:45 +0100

Hi,

[..]
> reasons, many of which are only tangentially related to "security".
[..]

Thanks for spotting this and spelling it out.

gert

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 10:13:14 +0100

Hi,

> to itself." No mention of filtering, classification, admission control,...

This definition of a router is nice, but such a device will not be 
useful in today's Internet.

What do you want this draft to be?  Theoretically beautiful, or useful
for people operating outside a closed and well-controlled network?

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 10:22:21 +0100

Hi,

> Again, if HBH headers are meaningless and not needed, then go through the proper process and remove them from IPv6. If not, stop trying to hobble this protocol to the point where we all realize why…

I don't think "lack of extensibility" is the major showstopper in 
IPv6 deployment.

"Endless quarrelling and unimplementable complexity, while lacking
sorely needed aspects that are considered too-hard or out-of-scope" 
might come closer.

Gert Doering
        -- NetMaster

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 10:32:59 +0000

> No it doesn't. That's what the flow label, in a fixed position early in the IPv6 header, is for. A line speed IPv6 router has no need to look at the layer 4 header, even if it's doing both diffserv…

A question for the operators, how widely supported in the flow label?

(a) in native IP
(b) IP over MPLS

Certainly in MPLS and Detnet land I hear about the five or six tuple all 
the time, including the inspection of them during forwarding, but I 
don't hear much spoken about the flow label.

- Stewart

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Dec 2018 11:59:50 +0100

Joe,

I think you misunderstand.

> I’m talking about a conflict in the text of 8200 - which has those fields as required to support - and 7045, which says they can be silently ignored.

8200 says:
If the router is explicitly configured to process the HBH header it MUST adhere to the option flag 2 high order bits.
Otherwise it MUST forward the packet.

There is no conflict.

If you think a different behaviour is required, then propose that. But preferably in 6man and on a different thread.

This was discussed at length. The consequence of relaxing the processing rules, is that an end-host can no longer use those bits to guarantee that every router on the path implements the option. That was the compromise we accepted. There is clearly a need for something like HBH, where it’s a cheap to process for the router signal that this packet requires further attention. The alternative is much worse, that the router must parse deep into the packet and where the trigger to process is a magic cookie in transport somewhere (and yes this has been proposed). 

Ole

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 11:25:15 +0000

> You too just killed SCTP ;-)

Well the last time I heard about SCTP was when we were forced to include 
it as an option for IPFIX.

How much SCTP exists in the real world?

> an ASIC or FPGA based device to handle the EH structures.
Something that has served the IETF well over the years is not to 
constrain the forwarding
implementation, and I think we would be wise to continue in that mould. 
Also we need
to remember that an NP is an application specific processor, and thus 
has various
hardware assists.

No one talks about the internals of an NP, and I am not current on any 
vendor's design,
but it is reasonable to suggest that in addition to the s/w parser there 
might
be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of 
expected type, dec
TTL and do what the TCAM say picking this ECMP option else parse it the 
hard way.

Then there is something that we do not talk at all about in such 
designs: electrical power.
There is no question that it takes more power to s/w parse a packet, and 
sooner of later
the power burn of the Internet is going to come under scrutiny, and we 
will be asked
to reduce its carbon footprint.

- Stewart

- Stewart

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Dec 2018 12:42:23 +0100

Stewart,

> Something that has served the IETF well over the years is not to constrain the forwarding
> implementation, and I think we would be wise to continue in that mould. Also we need
> to remember that an NP is an application specific processor, and thus has various
> hardware assists.
> 
> No one talks about the internals of an NP, and I am not current on any vendor's design,
> but it is reasonable to suggest that in addition to the s/w parser there might
> be a h/w parser that does the heavy lifting, i.e. if IPv6 packet of expected type, dec
> TTL and do what the TCAM say picking this ECMP option else parse it the hard way.
> 
> Then there is something that we do not talk at all about in such designs: electrical power.
> There is no question that it takes more power to s/w parse a packet, and sooner of later
> the power burn of the Internet is going to come under scrutiny, and we will be asked

So you are arguing that we need to define ULPs that are easy for routers to parse?
At arbitrary depth? Because why would the buck stop at the UDP header when transport has moved one layer up?

As opposed to the 6man argument which is that IPv6 is explicitly designed to only require routers to need to process the first 40 bytes (with the one exception hook).
And the design of EHs is specifically done to make it hard to parse for intermediate devices…

Is that really the Internet we want? Of course it will be countered with encryption, but I foresee a raft of problems if the IETF as a whole would redefine the “formal Internet architecture”.

Cheers,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 13:16:28 +0000

> The hopcount doesn’t get decremented by L2.

MPLS is not L2.

MPLS has two modes, one in which the TTL of the IP payload is 
decremented on ingress and the TTL across the MPLS path is ignored. In 
the other mode, the TTL of the IP packet minus one is copied into the 
MPLS label which is then decremented as the packet travels across the 
network at egress from the MPLS layer the TTL is copied back into the 
the IP packet.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 13:36:03 +0000

> So you are arguing that we need to define ULPs that are easy for routers to parse?
I don't see how you would conclude that from the above. What is needed 
is that whatever the parser needs to parse needs to be easy and cheap to 
parse.

> At arbitrary depth? Because why would the buck stop at the UDP header when transport has moved one layer up?
What is the status of the flow label in practice? As I said earlier in 
the thread, I know the five tuple is trusted for ECMP, but I hear very 
little discussion of the flow label being a trusted source of entropy to 
feed the ECMP selector.

> And the design of EHs is specifically done to make it hard to parse for intermediate devices…
That seems a fundamentally bad idea. Why would you go out of your way to 
make something difficult when you never know what path future protocol 
development will take you?

> Is that really the Internet we want? Of course it will be countered with encryption, but I foresee a raft of problems if the IETF as a whole would redefine the “formal Internet architecture”.
I think I have been describing the Internet architecture as it exists 
today regardless of the what the RFCs say.

- Stewart

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Dec 2018 14:40:26 +0100

Hi,

On Thu, Dec 06, 2018 at 12:42:23PM +0100, Ole Troan wrote:
> Is that really the Internet we want? 

Is this question relevant?

(And no, the Internet we have today is very much different from the 
Internet I *want*, in a large number of aspects.  I'd *love* to be back
in the friendly and cooperative Internet of the 90ies, but I lack the
necessary superpowers)

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Dec 2018 15:00:28 +0100

Stewart,

> I don't see how you would conclude that from the above. What is needed is that whatever the parser needs to parse needs to be easy and cheap to parse.

“what’s needed” is clearly something which is very contentious. There is a reason why encryption by default is a necessity.

> What is the status of the flow label in practice? As I said earlier in the thread, I know the five tuple is trusted for ECMP, but I hear very little discussion of the flow label being a trusted source of entropy to feed the ECMP selector.

I don’t know. I hear the situation is improving. Would be great if someone with access to a large packet trace could tell us.
That said, you will not always find the ports. fragmented packets, Non TCP/UDP protocols (GRE, IPinIP etc). You need to tackle that case too.
At least with the flow label you would be able to ECMP correctly for a session containing both fragmented and not fragmented packets.

> That seems a fundamentally bad idea. Why would you go out of your way to make something difficult when you never know what path future protocol development will take you?

It was a value desicion. Any time the network starts to dwelve deeply into packets that prohibits innovation and end to end transparency.
Of course it wasn’t a perfect solution. Encryption is the only thing that can “solve” it properly.

> I think I have been describing the Internet architecture as it exists today regardless of the what the RFCs say.

Sure. But I think the IETF’s signal effect is quite important.

And we are doing quite a bit to rectify the current state. If everything is encrypted. Sure, you might have a UDP header to do ECMP on, but you would need other indicators to detect attack traffic.

Cheers,
Ole

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Dec 2018 06:04:30 -0800

Your right - it’s a broken L2.

Only routers are supposed to decrement TTLs. Links and tunnels themselves aren’t.

Joe

> On Dec 6, 2018, at 5:16 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> MPLS has two modes, one in which the TTL of the IP payload is decremented on ingress and the TTL across the MPLS path is ignored. In the other mode, the TTL of the IP packet minus one is copied into the MPLS label which is then decremented as the packet travels across the network at egress from the MPLS layer the TTL is copied back into the the IP packet.
> 
> - Stewart

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Dec 2018 06:11:43 -0800

> On Dec 5, 2018, at 10:28 PM, Christopher Morrow <[email-masked]> wrote:
> 
> 
> 

That got mangled by autocorrect.  Packets aren’t supposed to be IP processed by links. To the extent that MPLS does this, it is broken vs the Internet arch.  Remember that MPLS tries to emulate a router path that can’t keep up.  It can - and does - fail to do so correctly in some cases.

> I think everyone here is actually happy to see v6 progress.

As am I - in Standards.  It shouldn’t ‘progress’ on ops.

> note I'm not trying to be intentionally combative, just attempting to say: "the best answer for the user here is PROBABLY to just have the core ignore all the EH business entirely" 

Again, if they’re not needed, fine. Remove them in Standards.

However, if the role of ops is to decide what standards to ignore, then perhaps the IESG should reconsider the area’s charter.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Dec 2018 06:13:16 -0800

> On Dec 6, 2018, at 1:22 AM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Then remove EHs. IN STANDARDS.

> have you enabled IPv6 on something today...?

No, but I haven’d DISabled it either.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Dec 2018 06:20:39 -0800

> On Dec 6, 2018, at 2:59 AM, Ole Troan <[email-masked]> wrote:
> 
> Joe,
> 

Read this text. Tell me what part of it you do not understand regarding nodes THAT DO NOT SUPPORT an option (if “skipping over” isn’t not supported, then what is it?):

The Option Type identifiers are internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type: 
 00 - skip over this option and continue processing the header. 
** 01 - discard the packet. 
** 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 
** 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type.

> Otherwise it MUST forward the packet.

The conflict is in the issue of “not supported”. Skipping over headers means they’re not supported, but it’s not possible to “NOT SUPPORT” them two different ways - one silent, one that *requires* action.

Joe

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Dec 2018 15:34:31 +0100

Joe,

> The conflict is in the issue of “not supported”. Skipping over headers means they’re not supported, but it’s not possible to “NOT SUPPORT” them two different ways - one silent, one that *requires*…

I don’t know where you found the use of “support”.

The text from RFC8200 is:

   The Option Type identifiers are internally encoded such that their
   highest-order 2 bits specify the action that must be taken if the
   processing IPv6 node does not recognize the Option Type:

This only apply if you are actually processing the option in the first place.
Which is a change from RFC2460.

Cheers,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 6 Dec 2018 14:35:50 +0000

I disagree, although I image we will never agree on this.

The devices in an MPLS router are called label switching routers for a 
reason, and in the most common form of operation the LFIB is populated 
with data derived from the IGP and EGP.

There are many ways of thinking of MPLS labels, but one model is to 
consider them IP address equivalents, hence the use of the term 
Forwarding Equivalence Classes.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Dec 2018 07:35:07 -0800

OK, all,

So let's try it this way:

- standards people on this list claim that 8200 already allows silently
ignoring HBH options

- ops people on this list claim that most routers already do this

So if you accept the items above, then why exactly is this document
needed at all? The standards already support it and operators already do it.

It clearly isn't needed, just as clearly as it isn't driven by security
issues.

So I would conclude that whether we agree on the logical path, we have
come to the same conclusion - drop this doc and move on.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Dec 2018 14:24:18 -0300

> is that whatever the parser needs to parse needs to be easy and cheap to

At the end of the day, it ends up being the call of the folks running
the net. -- see RFC7872.

"I'm gonna make it hard for your to parse the packets"
"OK, good. I'll just drop them. Good luck. Bye".

Thanks,

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 6 Dec 2018 17:59:58 +0000

Perhaps we should push for some research to evaluate the actual impact?

This is the only study I know that did something like that. It was limited to a single router and is 2 years or so old.

http://www.macrothink.org/journal/index.php/npa/article/viewFile/10190/8493

"The maximum traffic rate was reached
with packets of 1518 Bytes and IPv4 protocol, and it decreases with the use of IPv6 protocol.
The router reaches higher performance when work with IPv4 traffic. The CPU usage
increases with the increase of IPv6 traffic. The use of ACL in IPv4 traffic the CPU usage rises
from 6.5% without ACL to 15% with ACL (8.5%) while for IPv6 goes from 67.5% to 82.5%,
15%, the double. The maximum traffic rate falls 1.54 Mbps by the use of ACL in IPv4 and
27.14 Mbps in IPv6. With IPv4 the router is able to support bidirectional traffic without
decrease the maximum traffic rate, compared with unidirectional traffic. But for IPv6 in
bidirectional traffic the maximum traffic rate is lower than for unidirectional traffic in the
same conditions. The use of REH in the traffic supposes an increment of the CPU usage; this
increment depends on the packets per second of the data flow. "

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]

________________________________________
From: OPSEC [[email-masked]] on behalf of Gert Doering [[email-masked]]
Sent: Monday, November 26, 2018 12:57 AM
To: Joe Touch
Cc: ietf; [email-masked]; Nick Hilliard; OPSEC; Christian Huitema; tsv-art; Brian E Carpenter
Subject: Re: [OPSEC] [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

Hi,

On Sun, Nov 25, 2018 at 09:16:23PM -0800, Joe Touch wrote:
> I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intended.

And then IETF wonders why operators do not feel like time spent on
providing their input to IETF WGs is well-spent.

What else can it be, on a real-world device, in today's Internet?

Gert Doering
        -- Operator

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 6 Dec 2018 18:13:13 +0000

Smith, Donald wrote on 06/12/2018 17:59:
> This is the only study I know that did something like that. It was
> limited to a single router and is 2 years or so old.
this isn't a relevant study because the device in question was a 
software-forwarded device (i.e. no separation between control plane and 
forwarding plane).  The devices we're talking about in this discussion 
are systems which have separate management planes which can be 
overloaded by excess traffic from the forwarding planes, unless specific 
mitigating configuration is used.

Not sure why the authors of that report used a C1841 - that device dates 
from 2004.

Nick

---

From: Ole Troan <[email-masked]>
Date: Thu, 6 Dec 2018 19:27:52 +0100

> this isn't a relevant study because the device in question was a software-forwarded device (i.e. no separation between control plane and forwarding plane).  The devices we're talking about in this discussion are systems which have separate management planes which can be overloaded by excess traffic from the forwarding planes, unless specific mitigating configuration is used.
> 
> Not sure why the authors of that report used a C1841 - that device dates from 2004.

The VPP project maintains lots of performance measurements for modern Intel CPUs.
https://docs.fd.io/csit/rls1810/report/vpp_performance_tests/packet_throughput_graphs/index.html

We haven’t measured extension header cost as far as I know.

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Dec 2018 09:35:07 +1300

> A question for the operators, how widely supported in the flow label?

But there's a preliminary question: how widely is the flow label set
by sending hosts? The answer is: widely, by modern o/s releases. But not
much, by legacy o/s releases.
 
> don't hear much spoken about the flow label.

Why would forwarding devices bother, until a majority of traffic has
the flow label set by the source? This is a long term play. As it
becomes harder and harder to parse packet contents, the flow label
will become more and more useful for ECMP.

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 6 Dec 2018 22:02:43 +0000

> much, by legacy o/s releases.

more to the point, if you were going to implement a forwarding device, 
do you depend solely on the flow label?

This gives end-user device control over the hashing path on a purely 
discretionary basis.  I.e. and end user can change the flow label and 
consequently make their own decisions about which network path to use, 
without affecting any other transmission characteristic of the network 
flow, e.g. port numbers, IP addresses, etc.

Operationally, flow labels can cause grief.  APNIC had a blog posting on 
this a while back

https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/

Most devices allow the operator to selectively use flow labels as an 
entropy source for hashing.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Dec 2018 11:05:35 +1300

Gert,

> useful in today's Internet.

Are you saying that *every* router in a carrier network needs to
perform filtering? I would have thought that this would be done
where necessary, but intentionally avoided elsewhere, to reduce
energy consumption and improve throughput. Anyway...

> for people operating outside a closed and well-controlled network?

I wasn't actually thinking about this draft; I was just trying to make
the (obvious) point that IPv6 was designed a certain way and that is
what the IPv6 standards track documents deal with. This draft is directed
at the operational community and I fully agree with you that it needs
to match operational reality as much as possible. (My issues with the
draft were fixed before it moved to IETF Last Call.)

   Brian

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 6 Dec 2018 22:10:19 +0000

Brian E Carpenter wrote on 06/12/2018 22:05:
> Are you saying that*every*  router in a carrier network needs to
> perform filtering?

every interface to a second- or a third-party needs filter rules 
applied, yes.  In practice, this means deploying ACLs on everything 
except for devices acting in a pure core role.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Dec 2018 11:16:25 +1300

> flow, e.g. port numbers, IP addresses, etc.

Well, ECMP would be based on the {dest, srce, flow_label} 3-tuple so
it's only the layer 4+ info that's missing. That will be missing anyway
when encryption takes over. And any source that plays silly games
with the flow label will damage its own users more than it damages
the network.

> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/

By Joel J, who generally knows what he's talking about.

"By in large, this flow label changing behaviour has been traced to IPv6 supporting CPE/firewalls, which change the flow label between the initial syn and the ack."

Broken middleboxes can prevent anything from working properly.
 
> entropy source for hashing.

And that's progress. Again, the flow label is a long-term play that
will become more important as encryption becomes more of a factor.

   Brian

---

From: Jared Mauch <[email-masked]>
Date: Thu, 6 Dec 2018 19:43:51 -0500

> On Dec 6, 2018, at 5:05 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Gert,
> 
> energy consumption and improve throughput. Anyway…

Depends on how you build your network, but yes, every router needs to
perform filtering and you want it done in hardware as well.

> draft were fixed before it moved to IETF Last Call.)

We learned in the late 90s and early 2000’s about the problems of
processing things like IP options and their complexity.  Most providers
turn off or filter these as they are a risk to the control plane of the
device and there could be loss of control of the device due to the CPU
being consumed with these packets.  You can’t have a few hundred gigs
Of traffic going to the CPU, no matter what scale you think the router
is.

	- Jared

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Dec 2018 20:04:18 -0300

On 6/12/18 19:16, Brian E Carpenter wrote:
> when encryption takes over. 

If crypto == TLS, that need not.

> And any source that plays silly games

FWIW, FreeBSD had this behaviour -- without middleboxes involved ...
haven't checked recently to see if that's still the case

Thanks,

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 7 Dec 2018 00:27:32 -0500

On Thu, Dec 6, 2018 at 9:11 AM Joe Touch <[email-masked]> wrote:

> That got mangled by autocorrect.  Packets aren’t supposed to be IP
> processed by links. To the extent that MPLS does this, it is broken vs the
> Internet arch.  Remember that MPLS tries to emulate a router path that
> can’t keep up.  It can - and does - fail to do so correctly in some cases.
>
>
Joe, frankly I'm pretty sad that your behavior here is such as this.
I would like the IETF Ombudsteam to have a  chat with you are your behavior
and your lack of listening to reasoned input from folk who both implement
and operate networks, equipment and the protocols which make up the
Internet at large. You are not helping your case nor the case of the
protocols in question.

If the ombudsteam are unable/unwilling to interact here I'd like the
responsible ADs for ops/tsv to have a chat with you about this.

> However, if the role of ops is to decide what standards to ignore, then
> perhaps the IESG should reconsider the area’s charter.
>
> Joe
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Dec 2018 10:24:20 +0100

Hi,

> energy consumption and improve throughput. Anyway...

As of today, every border router connecting to other networks needs to
be able to do inbound rate-limiting by traffic class.

Networks interconnect with 10G to multiple 100G, and inbound DDoS 
nicely utilizes these pipes.  Customer connections and internal network
connections get filled, so you rate-limit the obvious crap ("inbound
large NTP packets with many Gbit/s") at your borders to protect the 
customer links and the internal network infrastructure.

Inside the network, you could have "pure" forwarding devices that
do not need to inspect L4/EH for transit traffic - correct.

(We do observe hardware being developed around merchant silicon that
actually specializes more and more for the "P" role - fast, cheap,
and little support for anything but "forwarding")

Gert Doering
        -- NetMaster

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 07 Dec 2018 15:16:29 -0600

With my Ombudsperson-hat firmly on my head:

If you do wish to make a report to the Ombudsteam, please do that in 
private email; Cc'ing a bunch of mailing lists is an inappropriate venue 
for such a report.

That said, it's not clear that this falls under our purview. From the 
Introduction to RFC 7776:

     The IETF has general policies for managing disruptive behavior in 
the
     context of IETF activities.  In particular, [RFC7154] provides a 
set
     of guidelines for personal interaction in the IETF, and [RFC2418] 
and
     [RFC3934] give guidelines for how to deal with disruptive behavior
     that occurs in the context of IETF working group face-to-face
     meetings and on mailing lists.

     However, there is other problematic behavior that may be more
     personal and that can occur in the context of IETF activities
     (meetings, mailing list discussions, or social events) that does 
not
     directly disrupt working group progress but nonetheless is
     unacceptable behavior between IETF Participants.  This sort of
     behavior, described in the IESG Statement "IETF Anti-Harassment
     Policy" [Policy], is not easily dealt with by our previously 
existing
     working group guidelines and procedures.  Therefore, this document
     sets forth procedures to deal with such harassing behavior.

     These procedures are intended to be used when other IETF policies 
and
     procedures do not apply or have been ineffective.

Since this is all taking place on public lists, and at least at first 
glance does not appear to be the kind of "more personal" behavior that 
RFC 7776 is talking about, it seems like going to the appropriate AD, or 
WG chair, or IETF list sergeant-at-arms, would be the more obvious first 
step. But again, first glances are not always accurate, so if you (or 
anyone) feels that particular behavior has crossed the line into the 
inter-personal sort (as against simply disruptive), please do not 
hesitate to drop an email to the Ombudsteam; we're more than happy to 
discuss it and help resolve it, privately.

pr

On 6 Dec 2018, at 23:27, Christopher Morrow wrote:

>> On Dec 5, 2018, at 10:28 PM, Christopher Morrow 
>> <[email-masked]>
>> wrote:
>>
>>
>>

---

From: Jared Mauch <[email-masked]>
Date: Fri, 7 Dec 2018 16:29:22 -0500

> On Dec 6, 2018, at 10:35 AM, Joe Touch <[email-masked]> wrote:
> 
> OK, all,
> 

I think many of us have PTSD from trying to talk about reasonable defaults and the failure to explicitly state why some of these things are bad and deprecating them continues to burn us to this day.  (Unrelated but perhaps relevant is some of us can’t get our vendors to clean up the garbage they sold us or our customers/peers/partners so we are bearing these costs on a daily basis).

> come to the same conclusion - drop this doc and move on.

I’ll let someone else decide that, chairs/ADs etc.  I think the question of additional work of eliminating these things so vendors don’t feel the need to implement them is fair work.

- jared

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 8 Dec 2018 05:51:41 -0500

Thanks Pete.

A few days ago I was about to hit send on a mail reminding people to keep the discussion in the last call threads about this document constructive, but then it in fact did seem to be getting more constructive and some new voices started chiming in. Nevertheless, perhaps it’s useful for everyone to remember to ask themselves a few questions before posting further in these threads (or other IETF threads):

- Am I offering an argument that is designed to persuade someone who I know has a well-established view that is different from mine, or simply to promote my own view?
- Has the point I'd like to make been overtaken by events?
- If I’ve already made my point multiple ways, might it be time to sit back and hear from others?
- Can I make my point without being condescending or demeaning?

I think at this point in the discussion of this document we might also be nearing a place where having the responsible AD summarize the commentary thus far would be useful — I’ll ping Warren on that although I know he was traveling earlier in the week.

Alissa

> On Dec 7, 2018, at 4:16 PM, Pete Resnick <[email-masked]> wrote:
> 
> If you do wish to make a report to the Ombudsteam, please do that in private email; Cc'ing a bunch of mailing lists is an inappropriate venue for such a report.
> 
> That said, it's not clear that this falls under our purview. From the Introduction to RFC 7776:
> 
> The IETF has general policies for managing disruptive behavior in the
> context of IETF activities.  In particular, [RFC7154] provides a set
> of guidelines for personal interaction in the IETF, and [RFC2418] and
> (meetings, mailing list discussions, or social events) that does not
> Policy" [Policy], is not easily dealt with by our previously existing
> These procedures are intended to be used when other IETF policies and
> Since this is all taking place on public lists, and at least at first glance does not appear to be the kind of "more personal" behavior that RFC 7776 is talking about, it seems like going to the appropriate AD, or WG chair, or IETF list sergeant-at-arms, would be the more obvious first step. But again, first glances are not always accurate, so if you (or anyone) feels that particular behavior has crossed the line into the inter-personal sort (as against simply disruptive), please do not hesitate to drop an email to the Ombudsteam; we're more than happy to discuss it and help resolve it, privately.
> 
> pr
> 
> On Thu, Dec 6, 2018 at 9:11 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Dec 5, 2018, at 10:28 PM, Christopher Morrow <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>> 
>> On Thu, Dec 6, 2018 at 12:31 AM Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
> I would like the IETF Ombudsteam to have a  chat with you are your behavior and your lack of listening to reasoned input from folk who both implement and operate networks, equipment and the protocols which make up the Internet at large. You are not helping your case nor the case of the protocols in question.
>  
> If the ombudsteam are unable/unwilling to interact here I'd like the responsible ADs for ops/tsv to have a chat with you about this.
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Dec 2018 12:06:41 -0800

Brian E Carpenter <[email-masked]> writes:

> "By in large, this flow label changing behaviour has been traced to
> IPv6 supporting CPE/firewalls, which change the flow label between the
> initial syn and the ack."
> 

With my <operator> hat on, we have indeed run into a problem where a
small (~ 2%) of IPv6 TCP sessions to us were failing due to FlowLabels
being used in ECMP hashing.  We had to turn off the usage of FlowLabel
in the hashing because of even a small real world impact to end-users.
-- 
Wes Hardaker
USC/ISI

---

From: Fernando Gont <[email-masked]>
Date: Thu, 6 Dec 2018 15:10:03 -0300

Hello, Donald,

We had this preso in the IPv6 Hackers (http://www.ipv6hackers.org/)
meeting in Berlin, 6 years ago:

* slides:
http://www.ipv6hackers.org/meetings/ipv6-hackers-1/zack-ipv6hackers1-firewall-security-assessment-and-benchmarking.pdf
* video: http://www.youtube.com/watch?v=umva0BxaXfM

Thanks,
Fernando