Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

From: Tal Mizrahi <[email-masked]>
Date: Mon, 13 Feb 2017 13:43:47 +0000

Hi,

Good discussion regarding the text about the hop-by-hop extension.

In my opinion there is a valid use case for intermediate nodes that insert/remove/modify/process hop-by-hop extensions. Examples: IOAM, INT.
Since there is a use case, I believe we need explicit text about intermediate handling of hop-by-hop extensions.

This [somewhat] reminds me of the discussion a few years ago about the IPv6/UDP zero checksum. The WG ended up defining that “Zero checksum is permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.

I would argue that regarding hop-by-hop extension handling we also need to define that “Hop-by-hop extensions can be inserted/removed/modified/processed by intermediate nodes *if* [……..] and the possible consequences are [……..]”.

Cheers,
Tal.

From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Monday, February 13, 2017 3:52 AM
To: Brian E Carpenter
Cc: [email-masked]; IETF Discussion list; Leddy, John; Pete Resnick; 神明達哉; Suresh Krishnan; [email-masked]; [email-masked]
Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

________________________________

On 13 Feb. 2017 11:40 am, "Brian E Carpenter" <[email-masked]<mailto:[email-masked]>> wrote:
John,

On 13/02/2017 12:05, Leddy, John wrote:
> I’m trying to understand how a ban of this functionality would work.  Is it targeted at vendor products, precluding them from implementing the functionality?
It's targetted at interoperability across the Internet. We can never stop
people doing whatever they please inside a private domain, obviously.
As always, there are no protocol police.

> If there is a technical problem that can be solved by using EH insertion within a domain where there are no harmful side effects, it should be able to be used.
> In a software networking world where functionality is being deployed that is not from traditional network vendors; solutions that solve problems efficiently will get deployed.
We had a lot of this conversation in a slightly different form prior to
RFC 6437. It proved impossible to specify "local domain" rules that could
reach consensus. I think we'd have the same problem trying to write rules
for header insertion/deletion within a domain. But in any case, that isn't
the target for RFC2460bis: the target is the Internet.

We also know that this statement from RFC1918 hasn't been 100% effective:

   Because private addresses have no global meaning, routing information

   about private networks shall not be propagated on inter-enterprise

   links, and packets with private source or destination addresses

   should not be forwarded across such links.

and we still don't have enough deployment of BCP38 which would also help enforce that.

If it is possible to plug a device into the Internet I think it is better to assume somebody probably will (and you won't be there to stop them) and design to that assumption.

(All the recent "IoT" botnets and corresponding attacks are a result of assuming those devices will only be connected to Private Internets, and therefore they don't have to be individually "Internet proof" (conceptually similar to a "water proof" watch).)

Regards,
Mark.

    Brian

>
> John Leddy
>
> From: ietf <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Vyncke (evyncke)" <[email-masked]<mailto:[email-masked]>>
> Date: Sunday, February 12, 2017 at 3:56 PM
> To: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>, 神明達哉 <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IETF Discussion list <[email-masked]<mailto:[email-masked]>>, Pete Resnick <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
>
> Suresh, Jinmei and Fernando,
>
> I fully agree with you Suresh, the goal of an IETF last call is to get NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.
>
> -éric
>
> From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
> Date: Saturday 11 February 2017 at 07:11
> To: 神明達哉 <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IETF Discussion list <[email-masked]<mailto:[email-masked]>>, Pete Resnick <[email-masked]<mailto:[email-masked]>>, Fernando Gont <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
>
> Hi Jinmei,
>
> On Feb 10, 2017 1:23 PM, "神明達哉" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> At Thu, 9 Feb 2017 18:30:11 -0300,
> Fernando Gont <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> While I largely agree with Fernando on everything he said, I have to
> admit most of the points are just repeated from the 6man discussion,
> and won't get us anywhere new by discussing these again at this point.
> I guess the only new input for the IETF last call is this:
>
>> 2) However, some folks came up with proposals to insert EH, on the basis
>> that "RFC2460 does not explicitly ban EH insertion". If there's people
>> arguing that, we clearly need to make this clear in the spec.
>>
>> 3) There was a consensus call, yes. When the call was made on the
>> mailing-list, the vast majority of supporters of "let's keep the
>> ambiguity" were folks from the same company as "2)". I have no idea if
>> this changes (or not) "consensus"... but this is clearly an important
>> datapoint.
> Although I don't want to point a finger at particular people or
> organizations without an evidence, I guess not a small number of 6man
> participants (not only those who explicitly spoke up here) suspected
> that the decision process was biased with the influence of a large and
> powerful organization and the process and resulting "consensus" was
> not really a fair one.  And I'm not an exception to it - in fact, it
> was so unbelievable to me that we can't clarify an ambiguity even when
> we were also open for future extensions, that I couldn't think of
> other reasons than a company agenda.
>
> Of course, it's quite possible that it was just a coincidence that
> many people with the same organization genuinely thought we should
> leave it ambiguous while many others strongly thought we should
> clarify it but few (if not no) people from that organization supported
> the clarification.  But I don't think we can prove it either way.
>
> But as Fernando said, I believe this point (and that several, and
> arguably more, participants suspected it) should be included in making
> the decision at the IESG and at the IETF last call.  And, whatever the
> decision, it would be more productive to move on after that and use
> our time for some other things.
>
> I am guessing that the people who spoke up during the WG process to not put in an outright prohibition would make their case along with their arguments here as well. We are only a week into a four week long last call.
>
> Thanks
> Suresh
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]<mailto:[email-masked]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 14 Feb 2017 03:06:55 +1100

Hi,

On 14 February 2017 at 00:43, Tal Mizrahi <[email-masked]> wrote:
> In my opinion there is a valid use case for intermediate nodes that
> insert/remove/modify/process hop-by-hop extensions. Examples: IOAM, INT.
>
> Since there is a use case, I believe we need explicit text about
> intermediate handling of hop-by-hop extensions.
>

Imagine you sent a letter through the postal system, and the postal
system wanted to add information to that letter, that is then to be
removed before the letter arrives at its final destination.

The postal system have at least two choices as to how to add that
information. They could:

(a) unstick your envelope's seal, insert the information, reseal the
envelope so well you can't tell and send it on its way, some how
flagging to a destination device within the postal system that this
specific envelop needs to be openned, a specific page removed, and
then resealed.

(b) take a new envelope with new internal postal system source and
destination address information, insert your letter without touching
it in addition to the new information, and then sending it on its way.

Imagine that the information to be added by the postal system is
printed on the same type of paper and is written in the same font as
you've chosen to use to write your letter.

Have a think about these two methods, what could fail with each of
them, and what the consequences may be if any of those failures occur.
Have a think of the benefits of each method, and whether they're worth
it compared to the failure mode costs and consequences for the method.

>
>
> This [somewhat] reminds me of the discussion a few years ago about the
> IPv6/UDP zero checksum. The WG ended up defining that “Zero checksum is
> permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.
>
>

That is a far more trivial change to the packet - it is allowing a
value in an existing field that was formerly prohibited, and nodes
that did not understand that value would drop the packet because that
is what they had been specified to do if they received this prohibited
value. In other words, existing implementations ' behaviour when this
formerly unexpected value was encountered had already been specified
and deployed.

>
> I would argue that regarding hop-by-hop extension handling we also need to
> define that “Hop-by-hop extensions can be
> inserted/removed/modified/processed by intermediate nodes *if* [……..] and
> the possible consequences are [……..]”.
>

Some things that are possible to do in theory shouldn't be done in
practice, because the consequences when their implementations fail can
be severe and outweigh the benefits.

In theory, inserted EHs will be removed 100% of the time. In practice
they won't be, because implementations can have bugs and they can also
fail in unexpected ways e.g., hardware faults.

Regards,
Mark.

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 14 Feb 2017 13:37:10 +0000

Hi Mark,

I certainly agree that hop-by-hop insertion/modification introduces potential security vulnerabilities.
Therefore, as I pointed out below, I would recommend to tackle this by defining something along the lines of “Hop-by-hop extensions can be inserted/removed/modified/processed by intermediate nodes *if* [……..] and the possible consequences are [……..]”

For example, hop-by-hop handling can be restricted only to a single administrative domain, or only to tunnels (as in the zero checksum case). 

Regards,
Tal.

>-----Original Message-----
>From: Mark Smith [mailto:[email-masked]]
>Sent: Monday, February 13, 2017 6:07 PM
>To: Tal Mizrahi
>Cc: [email-masked]; IETF Discussion list; draft-ietf-6man-
>[email-masked]; [email-masked]
>Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
>Protocol, Version 6 (IPv6) Specification) to Internet Standard
>
>External Email
>
>----------------------------------------------------------------------
>Hi,
>
>
>
>Imagine you sent a letter through the postal system, and the postal system
>wanted to add information to that letter, that is then to be removed before the
>letter arrives at its final destination.
>
>The postal system have at least two choices as to how to add that information.
>They could:
>
>(a) unstick your envelope's seal, insert the information, reseal the envelope so
>well you can't tell and send it on its way, some how flagging to a destination
>device within the postal system that this specific envelop needs to be openned, a
>specific page removed, and then resealed.
>
>(b) take a new envelope with new internal postal system source and destination
>address information, insert your letter without touching it in addition to the new
>information, and then sending it on its way.
>
>Imagine that the information to be added by the postal system is printed on the
>same type of paper and is written in the same font as you've chosen to use to
>write your letter.
>
>Have a think about these two methods, what could fail with each of them, and
>what the consequences may be if any of those failures occur.
>Have a think of the benefits of each method, and whether they're worth it
>compared to the failure mode costs and consequences for the method.
>
>>
>>
>> IPv6/UDP zero checksum. The WG ended up defining that “Zero checksum
>> is permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.
>>
>>
>
>That is a far more trivial change to the packet - it is allowing a value in an existing
>field that was formerly prohibited, and nodes that did not understand that value
>would drop the packet because that is what they had been specified to do if they
>received this prohibited value. In other words, existing implementations '
>behaviour when this formerly unexpected value was encountered had already
>been specified and deployed.
>
>
>>
>> I would argue that regarding hop-by-hop extension handling we also
>> need to define that “Hop-by-hop extensions can be
>> inserted/removed/modified/processed by intermediate nodes *if* [……..]
>> and the possible consequences are [……..]”.
>>
>
>Some things that are possible to do in theory shouldn't be done in practice,
>because the consequences when their implementations fail can be severe and
>outweigh the benefits.
>
>In theory, inserted EHs will be removed 100% of the time. In practice they won't
>be, because implementations can have bugs and they can also fail in unexpected
>ways e.g., hardware faults.
>
>Regards,
>Mark.

---

From: David Mozes <[email-masked]>
Date: Tue, 14 Feb 2017 14:27:16 +0000

Hi * ,
I am also supporting the insertion of in-band telemetry like INT along with the  actual data packet .
It is for sure a valid use case for the modern networking including data center. 
There are several proposals how to embedded telemetry information   some of them are with in nvo3 tannling protocols 
(Vxlan-GPE,Geneve) Spring and other  . 
I think that ipv6 hbh is the "cleanest"  way to add such info.
	1) I don't see any and advantages on the other  proposals (NVO3 ,SPRING) over IPV6 hbh.
	2))As far as security In the IPsec community, AH is pretty much considered deprecated, a failed experiment.They  are  prefer to use   ESP for authentication as well.
 
The postal system and the letter is very nice e example  . I will treat the adding ipv6-hbh info as stamps on the envelops ,since we are not touching  the data gram itself just the envelope

Thx
David
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Tuesday, February 14, 2017 3:37 PM
To: Mark Smith <[email-masked]>
Cc: [email-masked]; [email-masked]; IETF Discussion list <[email-masked]>; [email-masked]
Subject: RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Hi Mark,

Regards,
Tal.

>Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> 
>(Internet Protocol, Version 6 (IPv6) Specification) to Internet 
>Standard
>
>External Email
>
>specific envelop needs to be openned, a specific page removed, and then resealed.
>
>destination address information, insert your letter without touching it 
>in addition to the new information, and then sending it on its way.
>
>> This [somewhat] reminds me of the discussion a few years ago about 
>> the IPv6/UDP zero checksum. The WG ended up defining that “Zero 
>> checksum is permitted in IPv6/UDP *if* [……..] and the possible consequences are [……..]”.
>>
>>
>
>value in an existing field that was formerly prohibited, and nodes that 
>did not understand that value would drop the packet because that is 
>what they had been specified to do if they received this prohibited value. In other words, existing implementations '
>behaviour when this formerly unexpected value was encountered had 
>already been specified and deployed.
>
>
>>
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Feb 2017 12:34:52 +1300

David, Tal,

Note that if a HbH option is tagged "1 - Option Data may change en-route"
it is excluded from AH anyway. But if you insert an option, or extend
its length while modifying it, you will break all forms of PMTUD.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Feb 2017 07:41:19 +1100

> I am also supporting the insertion of in-band telemetry like INT along with the  actual data packet .

I think it will cause more trouble than any benefits it provides - of
which nobody has described when I've asked multiple times, and the
only one I can think of is to avoid the overhead of full
encapsulation.

> The postal system and the letter is very nice e example

It is not an example of insertion. The postal system uses
encapsulation to add information to letters, leaving the envelope and
its contents alone. Envelops might be a thin integrity barrier,
however the postal system usually has laws to make that integrity
barrier much stronger.

>. I will treat the adding ipv6-hbh info as stamps on the envelops ,since we are not touching  the data gram itself just the envelope

EH's are not equivalent to stamps on envelopes, they're equivalent to
pages inside the envelope. The pages inside the envelop are only
intended to be read by the recipient identified by the destination
address on the envelop.

Sorry for excessive bolding, but I'm getting tired of quoting this
text and having it ignored. RFC2460:

"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 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.  The Hop-by-Hop Options header,
   when present, must immediately follow the IPv6 header.  Its presence
   is indicated by the value zero in the Next Header field of the IPv6
   header."

In other words no mid-flght insertion allowed, even of the HBH option.