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 07:37:31
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.

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