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

[Tom Herbert <[e-mail]>]

On Mon, Sep 10, 2018 at 6:27 PM, Brian E Carpenter
<[e-mail]> wrote:
> A bit late to the party, but I have a few words to add:
> On 2018-08-22 03:09, Tom Herbert wrote:
>> On Tue, Aug 21, 2018 at 3:55 AM, Ole Troan <[e-mail]> wrote:
>>> Hi Tom,
>>>
>>>>>>>> Consider the folling scenario:
>>>>>>>>
>>>>>>>> Someone is developing a new Destination Option that might be of
>>>>>>>> interest for use with tunnels and might even become one of those
>>>>>>>> options "that makes sense to support" . Maybe it's an option for thenaforementioned insitu-OAM, or maybe a general packet CRC, etc. The
>>>>>>>> developer dutifully uses experimental option type 0x1e for the type
>>>>>>>> value of their option to test it. In particular, the action taken if
>>>>>>>> the option is unknown to a receiver is to skip over it. They made that
>>>>>>>> choice because that allows incremental deployment of the support for
>>>>>>>> the option in any combination supporting sending side or receivers. In
>>>>>>>> other words, they don't want a flag day for the option that requires
>>>>>>>> all nodes to support the new option.
>>>>>>>>
>>>>>>>> Now they go to test backwards comapatbility of the option by sending
>>>>>>>> it to a node that hasn't been updated to receive it. If the receiving
>>>>>>>> node is a Linux system, then the option is ignored and the tunneled
>>>>>>>> packet is processed as before-- expected behavior per the spec.
>>>>>>>> However, if it's sent to a VPP node then the packet is dropped-- not
>>>>>>>> expected. Even if this doesn't lead to incorrectness, it does breaks
>>>>>>>> interoperability and violates "be liberal in what you receive". This
>>>>>>>> net effect is that this makes development, test, and pilot deployment
>>>>>>>> of new options really hard. Just implementing the TLV loop, even if
>>>>>>>> the implementation doesn't process any of them, would resolve this.
>>>>>>>
>>>>>>> Absolutely. The set of _optional_ destination options would benefit from this approach.
>>>>>>> Of which we have none. I’d much rather just implement new options as they come available (if they ever will)
>>>>>>
>>>>>> Ole,
>>>>>>
>>>>>> I'm not sure what "comes available" mean here. Does that mean VPP
>>>>>> would only support TLVs parsing once one becomes standardized and the
>>>>>> VPP maintainers think is worth supporting? As shown in the scenario
>>>>>> above, with that approach its difficult to develop optional TLVs if
>>>>>> implementations don't properly skip over them.
>>>>>
>>>>> No, don’t get me wrong.
>>>>> As in any open source project you are welcome to provide a patch, and I’m pretty sure it would get in.
>>>>>
>>>> I would, but for me VPP code is very hard to decipher. For someone who
>>>> knows the code this should be relatively easy. The ip6_parse_tlv (in
>>>> net-next/net/ipv6/exthdrs.c) function does this in Linux in < 100 LOC.
>>>> It's straightforward, supporting padding, unknown options, and limits.
>>>>
>>>>> That said since we’re talking about tunnels, and in those cases you generally know whom you are talking to, I’m not sure I buy the argument that would make deploying new destination options harder. It’s not like a tunnel head end accepts traffic from random sources around the Internet (well, we’ve tried that with stuff like RFC1933, 6to4 and so on, but that didn’t quite pan out).
>>>>
>>>> I'm not sure this is just about tunnels. It looks like VPP can also
>>>> support TCP connections (there's a reference on web to HTTP server for
>>>> VPP) as well as UDP sockets, and VPP also can do classification, NAT,
>>>> and other firewall functions. Do you know if VPP properly handle
>>>> Destination Options in these cases?
>>>>
>>>> I'm afraid this might be an example of an implementation deployed on
>>>> middleboxes in the Internet (like firewalls) that arbitrarily drop
>>>> packets because they have a DestOpts extension header (RFC7872).
>>>> That's exactly a principle reason why Destination Options are unusable
>>>> on the Internet, and hence why there's been so much effort to avoid
>>>> using them and no one bother's trying to create "useful" options. This
>>>> is an example of death of a good protocol feature by undermining it
>>>> with a thousand arbitrary decisions on what parts of the spec to
>>>> implement or not.
>>>>
>>>> This goes goes back to a major rationale for this draft. If an
>>>> implementation really doesn't want to implement the TLV loop for
>>>> processing options then so be it, but then at least they should skip
>>>> over the options instead of just dropping the packet so as not to kill
>>>> the feature for everyone else.
>>>
>>> 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!

> 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?

> (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?

> 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?

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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>