Re: Comments on draft-herbert-ipv6-update-dest-ops

Hi Tom,
On 2018-09-12 07:23, Tom Herbert wrote:

<snip>

>>>> You have at least 4 arguments going at once here.
>>>>
>>>> 1) How to deal with destination options on intermediate devices terminating and forwarding traffic (tunnels, source routing)
>>
>> The words "destination option" and "marked to be changeable" in the same
>> sentence make my head hurt.
> 
> Hi Brian,
> 
> Yeah, I liken trying to resolve this to interpreting the meaning
> single obscure phrase in a consititution a hundred years after the
> fact!

A well regulated header format, being necessary to the security of a free Internet, the right of the people to keep and transmit destination options, shall not be infringed. 

>> So I think that indeed 8200 needs clarifying
>> on this, much as the draft says: if the option *precedes* the routing header
>> it's intended to be processed by the intermediate forwarder.
> 
> Is section 3 of the draft not clear on this?

Yes, I intended to indicate agreement.

>> (As a side
>> question, should that forwarder be entitled to remove the option completely,
>> as well as to modify it?)
> 
> My interpretation of RFC8200 is that if an option (HBH or Dest Opt) is
> marked changeable, then only the option data may change. Length and
> type cannot change, Options cannot be added nor deleted, and neither
> can extension headers be added nor removed, nor their lengths change.
> I think these requirements must be strict to achieve proper
> accountability in IP. For instance, if an intermeidate node makes some
> change to a packet field outside of what the sender has declared
> changeable, and if the change causes an error in a dowstream node, an
> ICMP error might be sent with a pointer to change data. The problem is
> that the ICMP error is sent to the source address not the party that
> made the change. The source might be able to deduce that the packet
> was changed and that caused the error, but would have no idea who
> actually made the change or how to prevent them from continuing to do
> that in subsequent packets. Does this need clarification in the draft?

I think it would do no harm to make it 100% clear. It's never been clear
to me whether a change in the option data is allowed to change the *length*
of the option data; changing the length breaks IPsec (see RFC 4302 section
3.3.3.1.2.2) and might confuse PMTUD.

>> But apart from that, "changeable" is a nonsense
>> for a *destination* option and should be forbidden.
>>
> 
> I'm not sure what forbidden would mean at least beyond what second
> paragraph describes. If someone marks a destination option a
> changeable in dest opts that is after a routing header or no routing
> header, then that is ignored (except for the auth header interaction).
> It's still legal to set the bit in that case. Does this paragraph need
> further clarification?

No, it seems clear enough to me.

   Brian

> 
> Tom
> 
>>>> 2) Dealing with destination options when terminating traffic as a host
>>
>> That seems clear cut.
>>
>>>> 3) Dealing with destination options when acting as a layer violating middlebox.
>>>
>>> Note that that RFC8200 doesn't distiguish any of the cases. Per the
>>> spec there is no difference between a tunnel endpoint and a end host
>>> in how they are supposed to process Destination Options. Neither is
>>> there is any difference between how a hardware and software
>>> implemenation of protocol is supposed to work. Middleboxes that aren't
>>> destinations of a packet aren't supposed to be looking at Destination
>>> Options header at all.
>>
>> +1
>>
>>>
>>>> 4) Why after 20 years aren’t there any “useful” destination options created?
>>>
>>> One could also argue that IPv6 itself has gotten enough traction until
>>> recently to warrant interest in the creating them.
>>
>> +1.
>>
>>>
>>> All these fall under the same root problem, namely how do we undo the
>>> effects of non-compliant implementations for core protocol features
>>> (i.e. Destination Options in this case). It seems like there's three
>>> alternatives: abandon trying to use the feature and try to do
>>> something else to get the functionality, fix implementations to be
>>> compliant, change protocols to adapt to reality of implementation that
>>> best preserves the feature.
>>
>> There's a 4th alternative hiding in draft-carpenter-limited-domains-03.
>> Namely, only use them where they actually work.
>>
>>    Brian
>>
>>> VPP is an example of an implementation that should simply be fixed to
>>> be compliant (I have taken that up with the VPP developers). This
>>> draft updates processing of Destination Options before the Routing
>>> header relax the requirements similar to how this was does for
>>> Hop-by-Hop options. It makes the assumption that some intermediate
>>> devices in a routing list won't processing the Destination Options per
>>> the current specification. That assumption seems to be true for VPP,
>>> and it seems like that some other implementations will also not be
>>> processing them ostensibly because of performance hit and processing
>>> cost.
>>>
>>> Tom
>>>
>>>> Best regards,
>>>> Ole
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
> 