Subject: [v6ops] Extension Headers / Impact on Security Devices

From: Enno Rey <[email-masked]>
Date: Fri, 15 May 2015 13:37:28 +0200

All,

yesterday's IPv6 WG session at the RIPE meeting saw another debate on extension headers.
Pls allow to submit our contribution to v6ops as well. Let me know if you think that the 6man mailing list would be the more appropriate place.

Here's some material/sources we'd like to bring up:

- this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation:
https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf.

- here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs:
http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/.
http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/.

We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months.

As for the topic itself I'd like to summarize our position as follows:
- it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.
- we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.
- from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case.
- looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either).
Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.
- the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown).
- now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.

===

Everybody have a great weekend

Best

Enno

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

----- End forwarded message -----

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2015 08:36:46 +1200

Enno,
On 15/05/2015 23:37, Enno Rey wrote:

...
> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.

I object to that logic. Firstly, the timescale is misleading: IPv6 deployment has
been so painfully slow that you really can't look at the 17 year span for
this argument; it's only within the last 5 years or so that the words "compelling"
and "Internet-scale" could be relevant. That's why the obvious issues in RFC 2460
were only fixed in 2013, by the way (RFC 7045). We haven't even had time for those
fixes to reach deployment.

Secondly, "compelling" is entirely a matter of judgement. There's no possibility
of a compelling case for something that is undeployable, and it's well known
that because of faulty handling of new extension headers by middleboxes, no
new extension headers are deployable today.

> - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.

Of course you won't, until middleboxes stop breaking them. Extensibility is for the
future and unpredictable, by definition.

> - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they a…

That is automatically a self-fulfilling prophecy. The new rules in RFC 7045 were
carefully constructed to offer a way out of this. I hope your advice is to follow
those rules and to insist on products that allow this (correct defaults, for example).

> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappe…

I assume you are following documents like draft-ietf-6man-deprecate-atomfrag-generation,
RFC 7112, RFC 6946, etc. It isn't as if the IETF is unaware of the issues.

> Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.

Well, Moore's law is stll with us, so I think that is plain wrong as products evolve,
which is exactly why we should update the standards accordingly. Of course that applies
to vendors, not operators.

> - now that "this vicious circle" has gained sufficient ground it will be evfixesen less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.

It's possible, but that doesn't mean that the IETF should give up on extensibility.
We should continue to mitigate the problems, which is what we've been doing for
several years, since they became apparent.

Nobody, I think, is arguing that the extensibility design in IPv6 is middlebox-friendly.
But that's history and we have to deal with it.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 16 May 2015 01:22:26 +0000 (UTC)

So quickly, how have IPv4 options been handled? They too can vary the location of the TCP/UDP etc. headers in an IPv4 packet. How have the variety and variable number of TCP options been handled? They too can vary the location of the TCP segment payload.
IOW, I don't think is a new problem exclusive to IPv6, so I think the IPv4 methods used to overcome packet header location variations should be reviewed/considered for applicability to IPv6.
How are you going to handle encryption of payloads and techniques such as multipath TCP when trying to do host and application security in the network rather than on the hosts?
      From: Enno Rey <[email-masked]>
 To: [email-masked] 
 Sent: Friday, 15 May 2015, 21:37
 Subject: [v6ops] Extension Headers / Impact on Security Devices
   
All,

===

Best

Enno

-- 
Enno Rey

----- End forwarded message -----

-- 
Enno Rey

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gert Doering <[email-masked]>
Date: Sat, 16 May 2015 23:18:40 +0200

Hi,

On Sat, May 16, 2015 at 01:22:26AM +0000, Mark ZZZ Smith wrote:
> So quickly, how have IPv4 options been handled? 
> They too can vary the location of the TCP/UDP etc. headers in an IPv4 packet. 

"Drop packets with IP options".

> How have the variety and variable number of TCP options been handled? They 
> too can vary the location of the TCP segment payload.

But they do not move the location of the TCP port info.

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

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
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: Brian E Carpenter <[email-masked]>
Date: Sun, 17 May 2015 11:16:02 +1200

> "Drop packets with IP options".

And, to be clear, that has been a fact of life since before IPv6 was
designed. (If it hadn't, back in early 1994 I would have pushed very
very hard on my own proposal to add address extension options to IPv4.)

  Brian

---

From: Silvia Hagen <[email-masked]>
Date: Sun, 17 May 2015 17:28:52 +0000

Yes Brian, I fully support your viewpoint.

Learning to deal with IPv6 takes time, and we have to give it that time.  And give the vendors the time to learn where the pain points are and give them time but also expect them to find solutions.
And they will find solutions.

Silvia

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Brian E Carpenter
Gesendet: Freitag, 15. Mai 2015 22:37
An: Enno Rey; [email-masked]
Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices

Enno,

...
> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.

I object to that logic. Firstly, the timescale is misleading: IPv6 deployment has been so painfully slow that you really can't look at the 17 year span for this argument; it's only within the last 5 years or so that the words "compelling"
and "Internet-scale" could be relevant. That's why the obvious issues in RFC 2460 were only fixed in 2013, by the way (RFC 7045). We haven't even had time for those fixes to reach deployment.

Secondly, "compelling" is entirely a matter of judgement. There's no possibility of a compelling case for something that is undeployable, and it's well known that because of faulty handling of new extension headers by middleboxes, no new extension headers are deployable today.

> - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.

Of course you won't, until middleboxes stop breaking them. Extensibility is for the future and unpredictable, by definition.

> - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they a…

That is automatically a self-fulfilling prophecy. The new rules in RFC 7045 were carefully constructed to offer a way out of this. I hope your advice is to follow those rules and to insist on products that allow this (correct defaults, for example).

> Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.

Well, Moore's law is stll with us, so I think that is plain wrong as products evolve, which is exactly why we should update the standards accordingly. Of course that applies to vendors, not operators.

It's possible, but that doesn't mean that the IETF should give up on extensibility.
We should continue to mitigate the problems, which is what we've been doing for several years, since they became apparent.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 May 2015 12:23:33 +0200

Enno,

[…]

> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.

this is clearly wrong. FH, AH, ESP are all widely deployed.
any form of tunnelling is essentially either using the IP header as an extension header. including GRE.

> - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they a…

open communication is a security nightmare.

cheers,
Ole

---

From: [email-masked]
Date: Mon, 18 May 2015 13:43:12 +0200 (CEST)

> any form of tunnelling is essentially either using the IP header as an extension header. including GRE.

AH is in RFC 2402 (1998).
ESP is in RFC 2406 (1998).
FH is in RFC 2460 (1998).

Do we have any examples of Internet-scale use cases where the extension
header has been defined *after* RFC 2460?

Steinar Haug, AS 2116

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 18 May 2015 13:41:20 +0100

> AH is in RFC 2402 (1998).

AH is nearly a zombie these days.  It's a pity the ipsec people won't
deprecate it, as it has so few useful applications.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 May 2015 01:15:54 -0300

On 05/15/2015 10:22 PM, Mark ZZZ Smith wrote:
> So quickly, how have IPv4 options been handled? They too can vary the
> location of the TCP/UDP etc. headers in an IPv4 packet. How have the
> variety and variable number of TCP options been handled? They too can
> vary the location of the TCP segment payload.

There are substantial differences here:

* The size of IPv4 options is very limited (well under 128 bytes)

* IYou only need to look at the IHL of the IPv4 packet to be able to
jump to the layer-4 protocol header. -- there's no such a thing in IPv6.

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 May 2015 14:14:04 -0400

> jump to the layer-4 protocol header. -- there's no such a thing in IPv6.

I think it's generally agreed that we can expect devices to be somewhat limited as to how far into the packet they can peek on the fast path, and that we may need to tolerate a certain degree of non-compliance in such devices until Moore's law fixes the problem, or people become willing to pay more for it (which they probably won't absent some significant application).

Maybe we should have an extension header that says where the transport header is... ;)

---

From: Gert Doering <[email-masked]>
Date: Tue, 19 May 2015 20:22:41 +0200

Hi,

> Maybe we should have an extension header that says where the transport header is... ;)

And document that this SHOULD NOT be incorrect, otherwise an evil bit MUST
be set.

Gert Doering
        -- NetMaster

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2015 11:51:14 -0700

> Maybe we should have an extension header that says where the transport header is... ;)

I briefly considered this at various times when this thread keeps
reappearing, but it would need to be another "HBH" header because it
needs to be examined and/or modified at any hop that modifies any other
extension header.

IPv4 knows where the transport header is but has limited option space
and can't natively support "shim" protocol layers inbetween IP and TCP
BUT it can find the transport header with localized info.

IPv6 makes the opposite trade-off.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2015 11:55:14 -0700

> header has been defined *after* RFC 2460?

The following are defined after 2460:

135 	Mobility Header 			[RFC6275]
139 	Host Identity Protocol 			[RFC7401]
140 	Shim6 Protocol 				[RFC5533]
253 	Use for experimentation and testing 	[RFC3692][RFC4727]
254 	Use for experimentation and testing 	[RFC3692][RFC4727]

FWIW.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 May 2015 16:09:38 -0400

> And document that this SHOULD NOT be incorrect, otherwise an evil bit MUST

Exactly!   :)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 08:35:31 +1200

> The following are defined after 2460:

To be clear, there is now an IANA registry for this, defined by RFC 7045:

http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#extension-header

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 08:48:04 +1200

> needs to be examined and/or modified at any hop that modifies any other

No. RFC 2460 makes it clear that hops don't modify extension headers
(except for shuffling within a routing header).

Also, there is a draft for this:
https://tools.ietf.org/html/draft-zhang-6man-offset-option-01

(which does discuss the security issue; as with the evil bit, a firewall
would be foolish to trust this option).

   Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 May 2015 13:59:43 -0700

> (except for shuffling within a routing header).

HBH headers are the exception and can be modified in-transit, which
would affect a transport-offset header.

FWIW, though, RFC2460 also clearly states:

   With one exception, extension headers are not examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field of the IPv6 header.

If that were actually enforced, we would not need a transport-offset
header because routers would never be looking there.

> would be foolish to trust this option).

But fails to address the fact that this option might need to be updated
whenever any other extension header is modified.

Joe

---

From: Sander Steffann <[email-masked]>
Date: Tue, 19 May 2015 23:37:19 +0200

Hi,

> Op 19 mei 2015, om 22:48 heeft Brian E Carpenter <[email-masked]> het volgende geschreven:
> 

What this says is basically that any device that might benefit from this option would be foolish to trust it :)

Cheers,
Sander

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 19 May 2015 23:09:12 +0000 (UTC)

From: Gert Doering <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: Enno Rey <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Sunday, 17 May 2015, 7:18
 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
   
Hi,

"Drop packets with IP options".
/ So you're actively doing that? I've configured routers to drop IPv4 packets with source route options, but not IPv4 packets with any options.

But they do not move the location of the TCP port info.
/ So what do you do with non-TCP or UDP traffic, that doesn't have port numbers? Drop that too?
/ What particular problem are you trying to solve with forwarding plane ACLs? Dropping DDoS traffic? How would you handle a DDoS that doesn't use TCP or UDP, or for which the TCP/UDP ports aren't accessible?

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 11:52:19 +1200

> What this says is basically that any device that might benefit from this option would be foolish to trust it :)

No, things like load balancers and diffserv classifiers could use it
(inside a suitably paranoid firewall, indeed).

   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 20 May 2015 09:14:25 +0100

> On 19 May 2015, at 19:55, Joe Touch <[email-masked]> wrote:
> 

Which, as I think you imply, haven’t exactly been widely implemented or successfully used.

The other question is what existing work is being done that relies on the correct (desired) operation of EHs? The two that would spring out would be segment routing and sfc, at least one of which is using the existing Routing Header. If such protocols are constrained to specific administrative domains then their successful operation I would assume is down to specific EH handling in the equipment in that domain, and its capabilities, rather than (undesired) operator filtering somewhere between sender and receiver.

Tim

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 20 May 2015 12:28:31 +0000

On 20/05/15 10:14, "Tim Chown" <[email-masked]> wrote:
>
>The other question is what existing work is being done that relies on the
>correct (desired) operation of EHs? The two that would spring out would
>be segment routing and sfc, at least one of which is using the existing
>Routing Header. If such protocols are constrained to specific
>administrative domains then their successful operation I would assume is
>down to specific EH handling in the equipment in that domain, and its
>capabilities, rather than (undesired) operator filtering somewhere
>between sender and receiver.

The primary use case of segment routing is indeed within a single
administrative domain, so, EH does not cause a problem.

OTOH, this whole discussion is pretty close to having a discussion on
whether an ISP should block everything which is neither UDP nor TCP? Or
block currently-unallocated TCP/UDP ports? (and I appreciate that there
are differences of course).

To Enno's original point: it is fair for a destination domain to handle
(permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
layer-4 ports, layer-4 protocols or extension headers. This is their own
responsibility

-éric

---

From: Silvia Hagen <[email-masked]>
Date: Thu, 21 May 2015 14:38:07 +0000

So to summarize:

EH such as destination option and fragment is no issue in the Internet and must not be filtered, nor analyzed, simply forwarded in hardware based on the information in the IPv6 header.
And what the administrator does within his administrative domain is up to his choice and the Internet needs not care about it

Is that correct?
If yes, what is the problem?

If that is how it is supposed to work we need to educate people that feel that EHs must be filtered in the Internet.
Now hop-by-hop is obviously diffferent. But is it needed in the Internet? Again, what I do internally, nobody out there cares.

Silvia

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von Eric Vyncke (evyncke)
Gesendet: Mittwoch, 20. Mai 2015 14:29
An: Tim Chown; Joe Touch
Cc: [email-masked]
Betreff: Re: [v6ops] Extension Headers / Impact on Security Devices

On 20/05/15 10:14, "Tim Chown" <[email-masked]> wrote:
>
>The other question is what existing work is being done that relies on 
>the correct (desired) operation of EHs? The two that would spring out 
>would be segment routing and sfc, at least one of which is using the 
>existing Routing Header. If such protocols are constrained to specific 
>administrative domains then their successful operation I would assume 
>is down to specific EH handling in the equipment in that domain, and 
>its capabilities, rather than (undesired) operator filtering somewhere 

The primary use case of segment routing is indeed within a single administrative domain, so, EH does not cause a problem.

OTOH, this whole discussion is pretty close to having a discussion on whether an ISP should block everything which is neither UDP nor TCP? Or block currently-unallocated TCP/UDP ports? (and I appreciate that there are differences of course).

To Enno's original point: it is fair for a destination domain to handle (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
layer-4 ports, layer-4 protocols or extension headers. This is their own responsibility

-éric

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 May 2015 16:00:23 +0100

Your summary is not correct.  The problems with EHs have been discussed
extensively on this mailing list.  Please see the archives for what the
problems are.

Nick

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 26 May 2015 05:27:00 +0000 (UTC)

________________________________
From: Eric Vyncke (evyncke) <[email-masked]>
To: Tim Chown <[email-masked]>; Joe Touch <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Wednesday, 20 May 2015, 22:28
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices

/ +1

/ In my opinion a huge amount of security context is missing from this discussion, to the point where the question has been simplified to a too simplistic and binary EHs or not question, and there is never going to be consensus on that question.

/ There seems to be an underlying and unstated set of assumptions behind the sorts of "block EHs","must be able to look at TCP/UDP headers in the network" questions/statements : 

/ (a) the network is the only place that network, host and application security can and must be done, implying that hosts and applications do nothing to protect themselves
/ (b) that the contents of packets will always remain transparent to the network, allowing them to be inspected in the network
/ and (c) that all traffic to and from a host/application will always traverse a single inspection/choke point in the network and will always use the same Internet protocol.

/ I think all of the above assumptions were true up until about the mid 1990s (if I remember well enough). Since then, they've all become false to varying degrees. Consequently, a choke point in the network may not be the best place to perform all network, host and application security measures, and in some cases persisting with that model will cause security failures. (For example, it seems that hosts aren't the lowest hanging fruit for network delivered malware any more, it is residential CPE itself - the device that is supposed to be so effective at providing "security" (including implicitly via NAT) that theoretically downstream hosts don't need firewalls at all.)

-éric

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 11:02:12 +1200

> would affect a transport-offset header.

I don't get where RFC 2460 allows that.

> whenever any other extension header is modified.

s/updated/hacked/
s/modified/hacked/

Yes, anyone who munges headers en route has to deal with the consequences.
That isn't news.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 11:06:20 +1200

I've lost track of who wrote that (Tim?), but it's only true if
all middleboxes respect RFC 7045, especially the bits about what
needs to be configurable and what the factory defaults should be.

> are differences of course).

Again: all these choices need to be configurable, so that providers
can make their own choices and decide what to break. I assume that
discussion belongs in opsec.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 May 2015 16:14:07 -0700

...
> I don't get where RFC 2460 allows that.

Section 4 states:

   The exception referred to in the preceding paragraph is the Hop-by-
   Hop Options header, which carries information that must be examined
   and processed by every node along a packet's delivery path, including
   the source and destination nodes.

In addition, RFC2460 defines a bit to handle when changes to such
options occurs en-route:

      1 - Option Data may change en-route

What is the purpose of that bit if the data can never change en-route?

Such changes can affect the content and *length* of these options.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 11:37:51 +1200

> Such changes can affect the content and *length* of these options.

Oh yuck. I suspect that allowing a length change is an unintended side
effect, but you're correct that it isn't forbidden. I've certainly
always read that text as allowing an update of the current value
of the content, not an increase in the length.

     Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 May 2015 16:56:17 -0700

> of the content, not an increase in the length.

FWIW, I don't see anything that prohibits adding headers either.

Not that I think that's a great thing to play with, but seems in-scope too.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 12:23:30 +1200

> FWIW, I don't see anything that prohibits adding headers either.

"With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header."

To me that clearly implies not adding (which is a form of processing).

   Brian

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 May 2015 17:32:28 -0700

...
> To me that clearly implies not adding (which is a form of processing).

The "one exception" are HBH headers - as a class.

I.e., this is just restating that non-HBH header classes don't change
en-route. It doesn't prohibit adding/removing HBH headers, but gives no
examples because the only HBH header types defined by 2460 are NOP fillers.

Joe

---

From: Gert Doering <[email-masked]>
Date: Wed, 27 May 2015 09:39:43 +0200

Hi,

> To me that clearly implies not adding (which is a form of processing).

So how do the SR folks handle that?  From what I heard, the intended
deployment really is "inside your administrative domain, SR headers get
added, processed, and when the packet leaves your domain, they can be
(optionally) removed again to not upset your neighbours"...

Gert Doering
        -- NetMaster

---

From: Ray Hunter <[email-masked]>
Date: Wed, 27 May 2015 13:07:52 +0200

> To me that clearly implies not adding (which is a form of processing).
I don't see how that text prohibits adding additional hop by hop headers 
though.

e.g. If none are present, then one could theoretcially be added en route.

That could form the basis of a nice resource depletion attack for all 
downstream devices.

[not that I expect anyone to actually process hop by hop headers in the 
real world]

---

From: Tim Chown <[email-masked]>
Date: Wed, 27 May 2015 12:34:50 +0100

Hi,

> On 27 May 2015, at 00:06, Brian E Carpenter <[email-masked]> wrote:
> 
>> ______________________________

I think the point is that drops caused by administrative configuration should not be an issue within a domain under your full control. Which is presumably why sfc/spring are limiting their primary use cases in this way. The exposure is presumably then only equipment within their domain that has some limitation in EH handling.

> discussion belongs in opsec.

With the caveat that you can’t control what you can’t control.

Tim

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2015 10:24:01 -0700

> (optionally) removed again to not upset your neighbours"...

AFAICT, SR headers are destination options, and aren't supposed to be
modified by anything but the endpoints (where each addressed hop in such
a route is such an endpoint).

So I would think that they MUST NOT be added to IPv6 datagrams except by
the source.

In many of the cases we're discussing, the nodes inside an AD act "on
behalf" of a source or sink, and that's the logic by which they are
allowed such modification. HOWEVER, whenever you act on behalf of a
source or sink, you ARE effectively a source or sink and thus beholden
to the source/sink requirements, not merely router requirements.

I.e., if you want the performance of a router, act like a router and
nothing more. If you want to act like a host, you need will have the
performance of a host.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 May 2015 08:29:37 +1200

> So I would think that they MUST NOT be added to IPv6 datagrams except by

I agree, but I think the SR people prefer to think otherwise, which just
stacks up MTU problems for the future. We know that features designed
for "local" use have a tendency to be deployed much more widely than
their designers intended.

   Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2015 13:31:58 -0700

> their designers intended.

See the rest of my response below, then.

Joe

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 28 May 2015 15:26:06 +0000

Segment Routing Header is currently drafted as another type of routing
header and are drafted to be inserted either by the source or by the
ingress router of a SR-configured domain (then being removed at the exit
of the SR-domain). Destination Option is not useful here as it is
inspected/processed only by the destination while the intent of SR is to
have this information processed by a couple of intermediate routers (which
have a specific configuration as SRH is not enabled by default).

Of course, this causes MTU issues (pretty much like MPLS but at a
different layer) within one domain which is solvable. The performance
issues need to be handled (as Joe wrote). But, as long as the pros/cons
balance is on the pro side, then it is valuable.

-éric

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2015 11:14:04 -0700

> have a specific configuration as SRH is not enabled by default).

Agreed, but note that some Dest Options can occur before the Routing
Header options (RFC 2460 Sec 4.1), e.g., where those DOs are relevant to
the next router as a "destination" - i.e., those DOs are processed
before the RH.

> different layer) within one domain which is solvable

Which is slightly more problematic because the Frag Header comes *after*
the Routing Headers, but - as you note - solvable using context.

Joe

> The performance

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 May 2015 16:43:51 +0000

On May 28, 2015, at 5:26 PM, "Eric Vyncke (evyncke)" <[email-masked]>
 wrote:

> of the SR-domain).

correct.

packet classification at ingress may result into a new SRH (segment routing header).
Very similar (well, mostly the same) to what ipv4/6 packet get with a label stack.

s.

> Destination Option is not useful here as it is

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 28 May 2015 19:01:05 +0000

> the Routing Headers, but - as you note - solvable using context.

the networking industry already faced the mtu "issue" more than 15 years ago with the introduction of the label stack. The reality of network operators infrastructure is such that the mtu is not really an issue.

s.

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 29 May 2015 14:54:53 -0400

On 5/28/15, 3:01 PM, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:

>the networking industry already faced the mtu "issue" more than 15 years
>ago with the introduction of the label stack. The reality of network
>operators infrastructure is such that the mtu is not really an issue.

This statement surprised me so much I thought I should ask:
³MTU is not really an issue² in general?

Lee

>s.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 29 May 2015 19:39:05 +0000

> On May 27, 2015, at 10:24 AM, Joe Touch <[email-masked]> wrote:
> 

You might consider commenting in Spring, then. They are designed as something that would be added in, and potentially removed again in, the network. They are something the ultimate source and destination need never see.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 29 May 2015 19:45:21 +0000

> On May 29, 2015, at 11:54 AM, Howard, Lee <[email-masked]> wrote:
> 
> "MTU is not really an issue" in general?

It's largely a question of equipment choice and configuration. Equipment made with merchant chips, and older equipment, may or may not support MTUs larger than 1500 bytes for an Ethernet frame, but the chips we use in our current products (I can't really speak for J or H, but AFAIK this is true of them as well) are quite content with a 9K MTU. If your source is sending 1500 byte frames, how large do you need the MTU to be?

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 13:23:25 -0700

On 5/29/2015 12:39 PM, Fred Baker (fred) wrote:
> You might consider commenting in Spring, then. They are designed as
> something that would be added in, and potentially removed again in, the
> network. They are something the ultimate source and destination need
> never see.

As I also noted, adding things "on behalf of" the source is equivalent.

If these are things the source never sees and used only on the path,
then they are *by definition* HBH options and should be indicated as such.

Joe