Subject: Re: Next steps on Extension Header Insertion

From: Fernando Gont <[email-masked]>
Date: Mon, 31 Oct 2016 21:54:47 -0300

Bob,

My main concern is:

* The text below notes that IPv6 (RFC2460, and prior RFCs) was not to
support EH insertion.

* The text below also notes that "The insertion of Extension Headers by
any node other than the source of the packet causes serious problems."

In the light of this, it would seem to me that the obvious outcome would
be "Therefore, don't do it!". That said, I'm keen to have RFC2460
updated to allow for EH insertion if deemed necessary and the above
problems can be made go away or mitigated.

However, the discussion so far seems to be about something that is not
part of IPv6, that is known for serious problems, but that somehow we
don't want to ban. Either ban it, or explicitly allow it and make it
work. I don't think that leaving something (deemed as causing serious
issues) unspecified can be a possible way to go for shipping a document,
even more to full std (clearly, the part of IPv6 that can be moved to
full std is IPv6 (without EH insertion)).

If we're moving IPv6 to full std, I would expect the specification to be
able to answer the question "Can middleboxes insert EHs?". -- Clearly,
it has always been implied that the answer was "No". But since the
question has been raised, and has been one of the most debated topics in
the last couple of years, I think the question deserves and explicit answer.

To make my point clear: I'm rather agnostic about SR, but I'm against
ambiguity in a std track documents, particularly when behind such
ambiguity there's the potential for a lot of problems.

Thanks,
Fernando

On 10/27/2016 04:02 PM, Bob Hinden wrote:
> Hello,
> 
> The chairs believe the bis drafts for moving the IPv6 to Internet Standard are close to being done with one exception, text in rfc2460bis on Extension Header Insertion.  This topic has been discussed extensively on the list and in working group sessions.  Prior to declaring a consensus and advancing the documents to the IESG we would like some feedback from the working group.
> 
> The current text regarding header insertion in draft-ietf-6man-rfc2460bis-07.txt (and has been there since the -05) is:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet breaks PMTU-discovery and can result in ICMP error
>   messages being sent to the source of the packet that did not insert
>   the header.
> 
>   The current approach to allowing a header to be inserted is to
>   encapsulate the packet using another IPv6 header and including the
>   additional extension header after the first IPv6 header, for example,
>   as defined in [RFC2473].
> 
> Based on recent face to face and mailing list discussions, we think the text could be improved as follows:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet causes serious problems.  Two examples include breaking
>   the integrity checks provided by the Authentication Header Integrity
>   [RFC4302], and breaking Path MTU Discovery and can
>   result in ICMP error messages being sent to the source of the packet
>   that did not insert the header.
> 
>   One approach to avoid these problems is to encapsulate the packet
>   using another IPv6 header and including the additional extension header
>   after the first IPv6 header, for example, as defined in [RFC2473]
> 
> The change in the first paragraph is more accurate as it notes there is more than one problem.  The change in the second paragraph makes it clear that encapsulation isn’t necessarily the only approach.
> 
> Our current take after reviewing the discussion in Berlin and on the mailing list we think there is consensus on the first paragraph as it accurately describes the issue with header insertion.  There is a much rougher consensus on the second paragraph, but don’t see it as the real issue which is the first paragraph.
> 
> While we both think that the intent of IPv6 was not to support header insertion we don’t see there being a consensus in the working group ban it outright as was proposed in the -01 draft:
> 
>   Extension headers must never be inserted by any node other than the
>   source of the packet.  IP Encapsulation must be used to meet any
>   requirement for inserting headers, for example, as defined in
>   [RFC2473].
> 
> We think the choice before the working group at this point is to either do something like the proposed text, or to not say anything at all about this topic.  This would be no change from RFC2460.   We would like your feedback on these choices between now and 13 October.  We have created a survey so we can better gauge where the working group is.  We are hoping that by using the survey, we will get more responses then by email alone.
> 
> To summarize, we think there are three choices.
> 
> (A) Banning header insertion outright:
> 
>   Extension headers must never be inserted by any node other than the
>   source of the packet.  IP Encapsulation must be used to meet any
>   requirement for inserting headers, for example, as defined in
>   [RFC2473].
> 
> (B) Describe the problems caused by header insertion:
> 
>   The insertion of Extension Headers by any node other than the source
>   of the packet causes serious problems.  Two examples include breaking
>   the integrity checks provided by the Authentication Header Integrity
>   [RFC4302], and breaking Path MTU Discovery and can
>   result in ICMP error messages being sent to the source of the packet
>   that did not insert the header.
> 
>   One approach to avoid these problems is to encapsulate the packet
>   using another IPv6 header and including the additional extension header
>   after the first IPv6 header, for example, as defined in [RFC2473]
> 
> (C) Not say anything at all about header insertion in rfc2460bis
> 
>   [No text in rfc2460bis about header insertion]
> 
> Note: If in case (B) or (C), it might be good to write a new draft that describes the issue in depth and makes recommendations.  We could then see if we can build a consensus around a draft like that, but it would be separate from the effort to move the IPv6 specifications to Internet Standard.
> 
> Please fill in the poll at
> 
>     https://www.surveymonkey.com/r/QG5QPVR
> 
> before November 4, 2016.  The poll allows you to express you preference for each choice, with 1 being the highest preference, and 3 being the lowest.  We will publish the results after the poll closes.
> 
> Thanks,
> Bob & Ole
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: 神明達哉 <[email-masked]>
Date: Tue, 1 Nov 2016 11:16:13 -0700

At Mon, 31 Oct 2016 21:54:47 -0300,

> ambiguity there's the potential for a lot of problems.

+1.  This is exactly why I had a big concern even with the choice
closest to my preference.  But I understood the chairs tried to
somehow move forward by this poll given the very diversified opinions
on this issue.  So I submitted my preferences with the reservation of
the concern.

--
JINMEI, Tatuya

---

From: Sander Steffann <[email-masked]>
Date: Wed, 2 Nov 2016 15:24:32 +0100

Hi Fernando,

> ambiguity there's the potential for a lot of problems.

Well said. Ambiguity is harmful here and will cause serious problems later.

Cheers,
Sander

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Wed, 2 Nov 2016 18:11:47 +0100

> Well said. Ambiguity is harmful here and will cause serious problems later.

+1

Ambiguity is our worst enemy.

Cheers, Jan

---

From: [email-masked]
Date: Wed, 2 Nov 2016 18:39:36 +0100

> Well said. Ambiguity is harmful here and will cause serious problems later.

There is absolutely no evidence that the lack of normative text here has led to any problems...

Regardless, it is also impossible to specify all the things creative people shouldn't be allowed to do. And that's probably not the purpose of standardisation either. It is to specify enough to make implementation interoperable.

I'm just trying to point out that we shouldn't blow this issue out of proportion. Whatever we end up doing here, it is hard to see it being particularly important, nor have any big consequences. It would have been nice if the IETF could have decreed that the Internet MUST be end to end transparent, and that middleboxes MUST not exist, but...

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 3 Nov 2016 06:40:33 +1100

> Regardless, it is also impossible to specify all the things creative people shouldn't be allowed to do. And that's probably not the purpose of standardisation either. It is to specify enough to mak…

I'd also say just as equally important is supportable / fixable. We
can't pretend implementations are perfect and that they'll never
suffer from partial failures that will cause them to misbehave, and
therefore interoperability is only a standardisation requirement.

> I'm just trying to point out that we shouldn't blow this issue out of proportion. Whatever we end up doing here, it is hard to see it being particularly important, nor have any big consequences.

I see it having big consequences and being hard to troubleshoot.

Currently, the source IP address in a packet identifies the host that
is entirely responsible for the construction of the packet. The set of
values in the IP packet that can be changed in the network is limited
and well known (HC, TC), and the consequences of those changes failing
is also limited (packet getting higher forwarding preference, being
dropped or being forwarded more or less hops than it should).

Allowing EH insertion means the source IP address value isn't true
anymore - its semantics have changed. It is now only the first
constructor of the packet, rather than the only one, and any other
constructors (the EH inserters) are not identified. It's now a
"multi-source" packet where only the first source is identified.

This change in source IP address semantics is what will cause new and
new types of failures and will make troubleshooting harder. I think it
would be a very fundamental and significant change, needs to be
thoroughly considered to identify all of its consequences and requires
more than just a couple of sentences specific to EH insertion.

> It would have been nice if the IETF could have decreed that the Internet MUST be end to end transparent, and that middleboxes MUST not exist, but...
>

You're right, these "standards" are fundamentally advisory.

I'm fine with consenting people doing their own thing inside their own
network, the trouble comes about when the price becomes an external
one

(And even then, if you adopt a technology that is hard to
troubleshoot, even if you're paying your staff to spend long periods
of time fixing it, it is still fundamentally wasting their life on
something that could have been avoided. They only have one life, and
they could be doing better things with it.)

Regards,
Mark.

---

From: [email-masked]
Date: Wed, 2 Nov 2016 21:33:30 +0100

Mark,

> "multi-source" packet where only the first source is identified.

Any text describing of EH insertion could possibly work or "allowing EH insertion" is far out of scope for 2460.

What I said was in regards to either of the 3 options in Bob's survey.

Best regards,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Wed, 2 Nov 2016 14:20:09 -0700

If you haven’t yet, please fill in the poll, it closes on November 4, 2016.

Thanks,
Bob

> On Oct 27, 2016, at 12:02 PM, Bob Hinden <[email-masked]> wrote:
> 
> Hello,
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Nov 2016 00:25:07 -0300

> There is absolutely no evidence that the lack of normative text here has
led to any problems...

Because nobody before proposed or pushed into code the idea of mangling
packets in the middle of the network with IPv6

> Regardless, it is also impossible to specify all the things creative
people shouldn't be allowed to do. And that's probably not the purpose of
standardisation either. It is to specify enough to make implementation
interoperable.

If IPsec, Path-MTU, and normal troubleshooting could all break as a
resultar of this, yes, we do have a say, and we should say so.

We should clearly state what the architecture is, including whether packets
are meant to be end2end, or  expect anyone to do their own thing.

If I read the v6 spec, at the very least, I want to be able to tell whether
I can expect that whatever I received in a packet was produced by the
source, or whether it could have been produced by the network itself. Since
a layer-3 protocol is supposed to be something quite simple, and such
question is core to the architecture, I'd expect the spec to answer the
question.

Clearly, it was obvious to everyone that intermediate systems don't mangle
v6 packets  But since all this discussion seems to indicate it wasn't so
obvious to everyone, the spec should make this important point very clear.

I'd say that some of the options given in the poll are rather misleading...
Because truth is that as of today, header insertion is not allowed. So any
discussion about "preferred way of doing eh insertion" seems like an
implicit update/"relax of the spec" to me.

> I'm just trying to point out that we shouldn't blow this issue out of
proportion. Whatever we end up doing here, it is hard to see it being
particularly important, nor have any big consequences.

Is that a politically-correct way of saying we're just irrelevant?

Cheers,
Fernando

---

From: <[email-masked]>
Date: Thu, 3 Nov 2016 07:45:37 +0000

Dear Bob,

I don't see evidence for (A). I'm tempted to live with (C). 

(B) may be good to have, but some of the issues apply also for encapsulation. Identifying issues that are unique to EH insertion would be valuable.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Bob Hinden
> Envoyé : jeudi 27 octobre 2016 21:03
> À : IPv6 List
> Cc : Bob Hinden
> Objet : Next steps on Extension Header Insertion
> 
> Hello,
> 
> The chairs believe the bis drafts for moving the IPv6 to Internet Standard
> are close to being done with one exception, text in rfc2460bis on
> Extension Header Insertion.  This topic has been discussed extensively on
> the list and in working group sessions.  Prior to declaring a consensus
> and advancing the documents to the IESG we would like some feedback from
> the working group.
> 
> The current text regarding header insertion in draft-ietf-6man-rfc2460bis-
> 07.txt (and has been there since the -05) is:
> 
> The change in the first paragraph is more accurate as it notes there is
> more than one problem.  The change in the second paragraph makes it clear
> that encapsulation isn’t necessarily the only approach.
> 
> Our current take after reviewing the discussion in Berlin and on the
> mailing list we think there is consensus on the first paragraph as it
> accurately describes the issue with header insertion.  There is a much
> rougher consensus on the second paragraph, but don’t see it as the real
> issue which is the first paragraph.
> 
> While we both think that the intent of IPv6 was not to support header
> insertion we don’t see there being a consensus in the working group ban it
> outright as was proposed in the -01 draft:
> 
> We think the choice before the working group at this point is to either do
> something like the proposed text, or to not say anything at all about this
> topic.  This would be no change from RFC2460.   We would like your
> feedback on these choices between now and 13 October.  We have created a
> survey so we can better gauge where the working group is.  We are hoping
> that by using the survey, we will get more responses then by email alone.
> 
> Note: If in case (B) or (C), it might be good to write a new draft that
> describes the issue in depth and makes recommendations.  We could then see
> if we can build a consensus around a draft like that, but it would be
> separate from the effort to move the IPv6 specifications to Internet
> Standard.
> 
> before November 4, 2016.  The poll allows you to express you preference
> for each choice, with 1 being the highest preference, and 3 being the
> lowest.  We will publish the results after the poll closes.
> 
> Thanks,
> Bob & Ole
> 
> 
>

---

From: [email-masked]
Date: Thu, 3 Nov 2016 11:09:46 +0100

Fernando,

> Because nobody before proposed or pushed into code the idea of mangling packets in the middle of the network with IPv6

That's only partly true from an IETF perspective (NPT66, TCP quick start... ), and certainly not the case if you look at the plethora of packet mangling middleboxes out there.

> If IPsec, Path-MTU, and normal troubleshooting could all break as a resultar of this, yes, we do have a say, and we should say so.
> 
> We should clearly state what the architecture is, including whether packets are meant to be end2end, or  expect anyone to do their own thing.
> 
> If I read the v6 spec, at the very least, I want to be able to tell whether I can expect that whatever I received in a packet was produced by the source, or whether it could have been produced by the network itself. Since a layer-3 protocol is supposed to be something quite simple, and such question is core to the architecture, I'd expect the spec to answer the question.
> 
> Clearly, it was obvious to everyone that intermediate systems don't mangle v6 packets  But since all this discussion seems to indicate it wasn't so obvious to everyone, the spec should make this important point very clear.
> 
> I'd say that some of the options given in the poll are rather misleading... Because truth is that as of today, header insertion is not allowed. So any discussion about "preferred way of doing eh insertion" seems like an implicit update/"relax of the spec" to me.

I fully agree with you on the architectural principles. I also think the Internet should be end to end transparent and that firewalls, NATs and other middleboxes have no place in the Internet architecture. _That_ political statement isn't for the core IPv6 _protocol specification_ though.

> Is that a politically-correct way of saying we're just irrelevant?

In the larger perspective we are all irrelevant. ;-)

I'm saying this is to a large degree politics. And as much as we want to put the middlebox cat back in the sack, the IETF doens't have the power to do that. Nor do I think it should.

End to end transparency has to be done by the end hosts with some sort of crypto.

Best regards,
Ole

---

From: Tim Chown <[email-masked]>
Date: Thu, 3 Nov 2016 10:20:33 +0000

Hi,

> On 3 Nov 2016, at 10:09, [email-masked] wrote:
> 
> Fernando,
> 

NPT66 is Experimental. Is TCP Quick Start mangling IP headers?

> I fully agree with you on the architectural principles. I also think the Internet should be end to end transparent and that firewalls, NATs and other middleboxes have no place in the Internet archi…

It’s not a political statement though, it’s about allowable behaviour, which is what a specification determines.  At the moment there’s a widely held assumption of behaviour X, but a number of people are wanting to introduce behaviour Y (though I’m not aware of a WG ID that actually documents that?)

> End to end transparency has to be done by the end hosts with some sort of crypto.

That is of course good too :)

Tim

---

From: [email-masked]
Date: Thu, 3 Nov 2016 11:30:38 +0100

> It’s not a political statement though, it’s about allowable behaviour, which is what a specification determines.  At the moment there’s a widely held assumption of behaviour X, but a number of peop…

Indeed, and since no-one has proposed to do this (in a draft) makes it very fuzzy what we're arguing against (or for).
We're arguing about an imagined treat. ;-)

Best regards,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Nov 2016 11:37:19 +0100

Hi,
> If IPsec, Path-MTU, and normal troubleshooting could all break as a resultar of this, yes, we do have a say, and we should say so
> 
As an operator these are the things I care about. I want predictable networking that I can debug. I understand the politics, but I think this issue is important enough to state in the core protocol RFCs.

Cheers,
Sander

---

From: [email-masked]
Date: Thu, 3 Nov 2016 12:24:57 +0100

> As an operator these are the things I care about. I want predictable networking that I can debug. I understand the politics, but I think this issue is important enough to state in the core protocol…

To paraphrase Michael Moore: "If you as a man is against gay marriage, then you do have the option of not marrying another man".
In this context; you have the choice of not deploying any packet mangling middleboxes.

Cheers,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Nov 2016 13:15:10 +0100

Hi Ole,

> To paraphrase Michael Moore: "If you as a man is against gay marriage, then you do have the option of not marrying another man".

Everybody is fully entitled to their own way of life and love :)  But the analogy doesn't fit...

> In this context; you have the choice of not deploying any packet mangling middleboxes.

If the mangled packets can be contained in one administrative domain then that's fine. I think that this is the point where the disagreement starts. Standards are about interoperability: everything that goes beyond your administrative domain. I don't care what people do to packets on their network, as long as interoperability doesn't suffer: as long as other operators don't even notice.

So I think the standard should say "this is what externally observable behaviour should/must be" with the understanding that "if you deviate from the standard internally, you must make sure the rest of the world doesn't notice".

I think that's what interoperability is about: your network, your rules, but between networks we use standards-based IPv6.

Cheers,
Sander

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 3 Nov 2016 13:20:23 +0100

On 03/11/2016 13:15, Sander Steffann wrote:
> Hi Ole,
>
>> To paraphrase Michael Moore: "If you as a man is against gay
>> marriage, then you do have the option of not marrying another
>> man".
>
> If the mangled packets can be contained in one administrative domain
> then that's fine. I think that this is the point where the
> disagreement starts. Standards are about interoperability: everything
> that goes beyond your administrative domain. I don't care what people
> do to packets on their network, as long as interoperability doesn't
> suffer: as long as other operators don't even notice.
>
> So I think the standard should say "this is what externally
> observable behaviour should/must be" with the understanding that "if
> you deviate from the standard internally, you must make sure the rest
> of the world doesn't notice".
>
> I think that's what interoperability is about: your network, your
> rules, but between networks we use standards-based IPv6.

...what roughly translates to: "send me non-standard packets and I'll drop
them on my network edge. They will never reach the destination. Don't cry
if I drop them, it's your fault."

Cheers, Jan

---

From: [email-masked]
Date: Thu, 3 Nov 2016 13:54:24 +0100

Sander,

> I think that's what interoperability is about: your network, your rules, but between networks we use standards-based IPv6.

What you are saying is something like:

"The IPv6 header fields described as immutable in RFC4302 MUST NOT be changed by the network. If within an administrative domain any of the immutable fields are changed, they MUST be restored on exit from the domain."

Correct?

Cheers,
Ole

PS: As an operator would you be happy if I sent packets with NH=59, SA=:: with an integrity check covering all fields apart from the HLIM field, and everything else beyond the IPv6 header (40 bytes) was encrypted?

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Nov 2016 14:11:08 +0100

Hi,

> "The IPv6 header fields described as immutable in RFC4302 MUST NOT be changed by the network. If within an administrative domain any of the immutable fields are changed, they MUST be restored on ex…

Yes, thank you for coming up with a good short bit of text. As RFC4302 defines the next-header field as immutable that would lock down the EH chain,

> PS: As an operator would you be happy if I sent packets with NH=59, SA=:: with an integrity check covering all fields apart from the HLIM field, and everything else beyond the IPv6 header (40 bytes…

Hmmmmm. Interesting question. As a network operator I'd probably drop that packet because of BCP38. As a security engineer I would be scratching my head and wondering what was going on. But effectively the payload wouldn't be that different from ESP...

Cheers,
Sander

---

From: [email-masked]
Date: Thu, 3 Nov 2016 14:39:04 +0100

> Hmmmmm. Interesting question. As a network operator I'd probably drop that packet because of BCP38. As a security engineer I would be scratching my head and wondering what was going on. But effecti…

If you dropped it because you looked beyond the 40 bytes IPv6 header that does violate the IPv6 specification.
You can argue even looking violates the specification.

Just making a point that while I'm all for doing good protocol politics in the specifications, what's written there and what happens in reality might not be the same thing. :-)

Best regards,
Ole

---

From: Sander Steffann <[email-masked]>
Date: Thu, 3 Nov 2016 16:18:49 +0100

Hi,

> You can argue even looking violates the specification.

Hey, if the length field says there is something there, i'd be curious to see what it is :)

> Just making a point that while I'm all for doing good protocol politics in the specifications, what's written there and what happens in reality might not be the same thing. :-)

I know :)  I'd like to see written down what is expected between admin domains though, to make it clear that if someone deviates then other parties shouldn't be affected.

Cheers!
Sander

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Nov 2016 06:19:12 +1100

> Fernando,
<snip>
> End to end transparency has to be done by the end hosts with some sort of crypto.

I think crypto is necessary for an assurance of end-to-end
transparency, however I don't think it is a requirement. If I send a
packet into an IP network that follows and is processed according
RFC2460, the only changes that will or may be made are to the HC and
TC values - there will be no structural changes to the packet.

As an analogy, while I might need to send a letter in an envelope to
attain some privacy and tamper evidence, I can send my holiday
postcards without an envelope, and still expect that the postal system
won't modify them, because that is the postal system specification
(and in most (all?) countries this processing is backed by law). (The
postal analogy seems to apply specifically as if I recall correctly,
early TCP specs, before the split off of IP, used it to describe
concepts.)

I think we're talking about a fundamental and default assumption about
how the network will treat and process packets according to the
specifications. Currently there is one field value that will be
modified and another that possibly may be. Other than that, you
receive what you send - the structure of the packet doesn't change.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Nov 2016 08:36:34 +1300

> Yes, thank you for coming up with a good short bit of text. As RFC4302 defines the next-header field as immutable that would lock down the EH chain,

Yes but... I understand that AH is more or less deprecated by the security community.
So while it has correctly identified what needs to be immutable, I'm not sure it's
a sound basis for a general requirement (much as I agree with that requirement).

Also, when we tried to write text for the flow label about restoring it on exit
from a domain, we were pretty much told to go away and stop being silly.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Nov 2016 08:36:53 +1300

On 03/11/2016 23:30, [email-masked] wrote:
...
> We're arguing about an imagined treat. ;-)

Huh? The segment routing header is far from imaginary.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 4 Nov 2016 08:19:31 +1100

On 4 Nov. 2016 6:36 am, "Brian E Carpenter" <[email-masked]>
wrote:
> >> "The IPv6 header fields described as immutable in RFC4302 MUST NOT be
changed by the network. If within an administrative domain any of the
immutable fields are changed, they MUST be restored on exit from the
domain."
> >>
> >> Correct?
> >
> > Yes, thank you for coming up with a good short bit of text. As RFC4302
defines the next-header field as immutable that would lock down the EH
chain,
> a sound basis for a general requirement (much as I agree with that
requirement).

I'm pretty sure that is because they use tunneling between hosts and IPsec
gateways and between gateways and gateways to add information to the
original packet and use a form of encryption that also provides
authentication.

IPsec is one of the reasons I think encapsulation is the better method. It
preserves the structure and content of the original packet, there is a
clear boundary between the original packet and what was added somewhere in
the network, and the outer IP header source address unambiguously
identifies the node acting as the tunnel end-point that added the IPsec
information to the original packet. ("tunnel" mode IPsec)

The only time IPsec "inserts" ESP and/AH headers is end to end or host to
host IPsec sessions between the host that is the original packet source and
the host that is final packet destination. ("transport" mode IPsec.)

Regards,
Mark.

> >> PS: As an operator would you be happy if I sent packets with NH=59,
SA=:: with an integrity check covering all fields apart from the HLIM
field, and everything else beyond the IPv6 header (40 bytes) was encrypted?
> >
> > Hmmmmm. Interesting question. As a network operator I'd probably drop
that packet because of BCP38. As a security engineer I would be scratching
my head and wondering what was going on. But effectively the payload
wouldn't be that different from ESP...

---

From: Tim Chown <[email-masked]>
Date: Fri, 4 Nov 2016 11:16:34 +0000

On 3 Nov 2016, at 19:36, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

On 03/11/2016 23:30, [email-masked]<mailto:[email-masked]> wrote:
...
Indeed, and since no-one has proposed to do this (in a draft) makes it very fuzzy what we're arguing against (or for).
We're arguing about an imagined treat. ;-)

But what do you deduce is really being specified in the SRH drafts?

In draft-ietf-6man-segment-routing-header-02 it says in section 2.2:

“While the source routing model defined in [RFC2460<https://tools.ietf.org/html/rfc2460>] doesn't mandate

   which node is allowed to insert (or modify) the SRH, it is assumed in
   this document that the SRH is inserted in the packet by its source.
   For example:

   o  At the node originating the packet (host, server).

   o  At the ingress node of an SR domain where the ingress node
      receives an IPv6 packet and encapsulates it into an outer IPv6
      header followed by a Segment Routing header.”

which implies the SRH uses encapsulation, and doesn’t insert an EH in the existing header chain.

In draft-ietf-spring-segment-routing-09 it says in section 8.2:

"From a network protection standpoint, there is an assumed trust model

   such that any node adding an SRH to the packet is assumed to be
   allowed to do so."

so “adding” is a little vague.

Perhaps both documents should be more explicit in terms of what “insert” really means?

Tim

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 4 Nov 2016 17:08:22 +0000

> On Nov 4, 2016, at 12:16 PM, Tim Chown <[email-masked]> wrote:
> 
>> On 3 Nov 2016, at 19:36, Brian E Carpenter <[email-masked]> wrote:
>> 
> “While the source routing model defined in [RFC2460] doesn't mandate
>       receives an IPv6 packet and 
> encapsulates
>  it into an outer IPv6

indeed, the current version of the draft only describes the encapsulation case.

> so “adding” is a little vague.

draft-ietf-spring-segment-routing is an architecture draft that is agnostic on the dataplane. The same architecture components apply to MPLS and v6. 

The document doesn’t aim to provide details on SR instantiation over a specific dataplane. For that we have draft-ietf-spring-segment-routing-mpls and draft-ietf-6man-segment-routing-header.

> Perhaps both documents should be more explicit in terms of what “insert” really means?

I think a good plan would be to not introduce any new text (i.e.: leave RFC2460 unchanged wrt header insertion) for now and work on a separate document explaining segment routing header insertion. 

s.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Nov 2016 22:22:35 -0300

> You can argue even looking violates the specification.

I think you're missing two different things. Dropping such packet is a
matter of policy. Where modifying packets on the fly can introduce
problems difficult (if at all possible) to troubleshot, for no evident
reason.

>From draft-gont-opsawg-firewalls-analysis-02:

---- cut here ----
3.3.  Firewalls and The End-to-End Principle

   One common complaint about firewalls in general is that they violate
   the End-to-End Principle [Saltzer].  The End-to-End Principle is
   often incorrectly stated as requiring that "application specific
   functions ought to reside in the end nodes of a network rather than
   in intermediary nodes, provided they can be implemented 'completely
   and correctly' in the end nodes" or that "there should be no state in
   the network."  What it actually says is heavily nuanced, and is a
   line of reasoning applicable when considering any two communication
   layers.

      [Saltzer] "presents a design principle that helps guide placement
      of functions among the modules of a distributed computer system.
      The principle, called the end-to-end argument, suggests that
      functions placed at low levels of a system may be redundant or of
      little value when compared with the cost of providing them at that
      low level."

   In other words, the End-to-End Argument is not a prohibition against
   lower layer retries of transmissions, which can be important in
   certain LAN technologies, nor of the maintenance of state, nor of
   consistent policies imposed for security reasons.  It is, however, a
   plea for simplicity.  Any behavior of a lower communication layer,
   whether found in the same system as the higher layer (and especially
   application) functionality or in a different one, that from the
   perspective of a higher layer introduces inconsistency, complexity,
   or coupling, extracts a cost.  That cost may be in user satisfaction,
   difficulty of management or fault diagnosis, difficulty of future
   innovation, reduced performance, or something else.  Such costs need
   to be clearly and honestly weighed against the benefits expected, and
   used only if the benefit outweighs the cost.

   From that perspective, introduction of a policy that prevents
   communication under an understood set of circumstances, whether it is
   to prevent access to pornographic sites or to prevent traffic that
   can be characterized as an attack, does not fail the End-to-End
   Argument; there are any number of possible sites on the network that
   are inaccessible at any given time, and the presence of such a policy
   is easily explained and understood.

   What does fail the End-to-End Argument is behavior that is
   intermittent, difficult to explain, or unpredictable.  If a site can
   be reached sometimes and not at other times, or can be reached using
   this host or application but not another, one will wonder why that is
   the case, and may not even know where to look for the issue.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 6 Nov 2016 22:04:17 -0300

> Any text describing of EH insertion could possibly work or "allowing EH insertion" is far out of scope for 2460.

Any text that talks about header insertion introduces a change in
RFC2460, because RFC2460 does not allow for header insertion.

Given the discussion, omission of the topic would be a failure on our side.

Thanks,

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 7 Nov 2016 08:37:35 +0000

> On Nov 7, 2016, at 2:04 AM, Fernando Gont <[email-masked]> wrote:
> 

can you point me to the section/paragraph making that statement ?

Also, if you think rfc2460 denies header insertion, why would you need new text ?

Seriously, nothing is prohibited as long as you understand the consequences. As discussed at length, the text should focus on that.

s.

---

From: Mark Smith <[email-masked]>
Date: Tue, 8 Nov 2016 06:52:26 +1100

On 7 Nov. 2016 19:37, "Stefano Previdi (sprevidi)" <[email-masked]>
wrote:
> >>>> I'm just trying to point out that we shouldn't blow this issue out
of proportion. Whatever we end up doing here, it is hard to see it being
particularly important, nor have any big consequences.
> >> Any text describing of EH insertion could possibly work or "allowing
EH insertion" is far out of scope for 2460.
> can you point me to the section/paragraph making that statement ?

First sentence, second paragraph of "4. IPv6 Extension Headers".

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

The one exception is the HBH EH, which appears directly after the IPv6
header if the packet origin host puts it there.

> Also, if you think rfc2460 denies header insertion, why would you need
new text ?

It shouldn't. It does because some people are saying the above is ambiguous.

> Seriously, nothing is prohibited as long as you understand the
consequences.

When it isn't allowed by the specification, claiming it is compliant with
the specification is prohibited.

Changing the specification to support a method doesn't make the problems
with the method go away. If the problems are severe enough, and there are
alterative methods that don't have those problems, the other methods should
be used and possibly specified.

As discussed at length, the text should focus on that.

I don't think it makes sense to have a part of a specification prohibit
something and then have other text later tacitly allow it.

Regards,
Mark.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 7 Nov 2016 20:05:53 +0000

> On Nov 7, 2016, at 8:52 PM, Mark Smith <[email-masked]> wrote:
> 
> On 7 Nov. 2016 19:37, "Stefano Previdi (sprevidi)" <[email-masked]> wrote:
> >
> >
> "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."
> 
> The one exception is the HBH EH, which appears directly after the IPv6 header if the packet origin host puts it there.
> 

Well, as far as I’m concerned, RFC2460 is good for me and I never asked to change anything regarding extension headers. 

This what has been proposed during an IETF meeting (I don’t remember if it was Buenos Airs or Prague) and it is also what I reflected in my vote.

RFC2460 needs not to be amended.

> > Seriously, nothing is prohibited as long as you understand the consequences.
> 
> When it isn't allowed by the specification, claiming it is compliant with the specification is prohibited.

the question is not being compiant or not.

Over time we always see implementations that diverge from the original intend of the specification. This is obvious and natural. 

> Changing the specification to support a method doesn't make the problems with the method go away.

I agree and that’s why I do not ask to change any specification. We need more experience and more feedback on network operations. In all ways.

> If the problems are severe enough, and there are alterative methods that don't have those problems, the other methods should be used and possibly specified.

and if there are methods who violates specifications but that have the necessary safeguards, this is fine too.

> I don't think it makes sense to have a part of a specification prohibit something and then have other text later tacitly allow it.

there are examples where a specification denies something and later, under precise circumstances, another specification allows it.

This is part of operational experience.

s.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 8 Nov 2016 15:35:20 +1300

Stefano,
> Well, as far as I’m concerned, RFC2460 is good for me and I never asked to change anything regarding extension headers. 

Yes, Stefano, because you interpreted "not examined or processed" to allow insertion.
Most people here, I think, interpreted it as forbdidding insertion (since that is
a form of processing) and of course as forbidding modification. And that was clearly
the intent when RFC1883 was written, according to the meeting minutes I dug out some
months ago.

So, the *fact* is that the current text is ambiguous, since it has been interpreted
both ways. As standards writers, we should hate ambiguity.

Rgds
    Brian

---

From: [email-masked]
Date: Tue, 8 Nov 2016 09:18:23 +0100

> both ways. As standards writers, we should hate ambiguity.

As standards writers, we should love interoperability.

Ole

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 8 Nov 2016 10:09:51 +0000

Brian, 

> On Nov 8, 2016, at 3:35 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Stefano,
> Most people here,

I’m not sure if it's a “most” or a “many”.

> I think, interpreted it as forbdidding insertion (since that is

rfc1883 was a little while ago and reality of operational networks may have slightly changed since.

As suggested, we should carefully understand and valuate the experience of EHs prior to make definitive statements.

> both ways. As standards writers, we should hate ambiguity.

if there aren’t issues with interoperability, ambiguity is just fine.

Thanks.
s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 8 Nov 2016 10:10:01 +0000

> On Nov 8, 2016, at 9:18 AM, [email-masked] wrote:
> 

agreed.

s.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 8 Nov 2016 09:23:00 -0800

> before November 4, 2016.  The poll allows you to express you preference for each choice, with 1 being the highest preference, and 3 being the lowest.  We will publish the results after the poll clo…

What's the result of the poll, btw?

I'm feeling we are now repeating all the previous discussions once
again.  I thought the chairs conducted the poll based on the
observation that keeping the discussion wouldn't get us anywhere.
(Whether or not having this poll can really make a difference) if so,
it would be better to show the result and see what we can do from that
point rather than repeating another round of the same discussion,
which will just waste our time even more.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Nov 2016 07:37:48 +1300

>> As standards writers, we should love interoperability.

Yes. Broken PMTUD is not very interoperable.

   Brian

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 8 Nov 2016 18:44:31 +0000

> On Nov 8, 2016, at 7:37 PM, Brian E Carpenter <[email-masked]> wrote:
> 

there are implementations currently deployed allowing you to cope with the effective mtu of the link so to take into account expected overhead (mpls reported the issue 20 years ago).

s.

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Nov 2016 20:06:25 +0000

On 8 Nov 2016, at 10:09, Stefano Previdi (sprevidi) <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 8, 2016, at 3:35 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

So much for "an implementation should be conservative in its sending behavior, and liberal in its receiving behaviour” :)

Stefano, you have said earlier in this thread that while draft-ietf-6man-segment-routing-header-02 only suggests the encapsulation method for “inserting” headers in transit, that you know some vendor implementations are really inserting EHs into existing packets instead, and thus causing the PMTU issues that Brian and others have raised. Can you say which implementations those are?

For me, draft-ietf-6man-segment-routing-header-02 is too vague. We should not let it be published with a waffly “for example, you might encapsulate”, while in practice this apparently isn’t what vendors are doing.  I’d like to hear some comment from the authors on this, because it is rather misleading as it stands.

Tim