ietf
[Top] [All Lists]

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

2017-02-14 17:35:46
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

On 15/02/2017 03:27, David Mozes wrote:
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:ipv6-bounces(_at_)ietf(_dot_)org] On Behalf Of Tal Mizrahi
Sent: Tuesday, February 14, 2017 3:37 PM
To: Mark Smith <markzzzsmith(_at_)gmail(_dot_)com>
Cc: draft-ietf-6man-rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org; 
6man(_at_)ietf(_dot_)org; IETF Discussion list <ietf(_at_)ietf(_dot_)org>; 
6man-chairs(_at_)ietf(_dot_)org
Subject: RE: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> 
(Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

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:markzzzsmith(_at_)gmail(_dot_)com]
Sent: Monday, February 13, 2017 6:07 PM
To: Tal Mizrahi
Cc: 6man(_at_)ietf(_dot_)org; IETF Discussion list; draft-ietf-6man- 
rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org; 6man-chairs(_at_)ietf(_dot_)org
Subject: [EXT] Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> 
(Internet Protocol, Version 6 (IPv6) Specification) to Internet 
Standard

External Email

----------------------------------------------------------------------
Hi,



On 14 February 2017 at 00:43, Tal Mizrahi <talmi(_at_)marvell(_dot_)com> 
wrote:
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.



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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



<Prev in Thread] Current Thread [Next in Thread>