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

[Tom Herbert <[e-mail]>]

On Mon, Aug 20, 2018 at 2:47 PM, 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 the
>>>> aforementioned 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.

Tom

> So you’d end up with a configuration option I’d imagine…
>
>>
>>> If I get time, I’ll try to do some performance measurements on what the actual cost is for a software based system.
>>>
>> Our testing in Linux showed that the performance hit is heavily
>> dependent on the number of TLVs to be processed. Processing a small
>> number of TLVs was fairly inconsequential relative the rest of the
>> header processing. A a packet filled with tiny TLVs so that a single
>> MTU sized packet has hundreds of them will kill performance on any
>> software or hardware system and really has no other practical purpose
>> other than to be a DOS attack. This why we needed to add limits in
>> RFC6434bis. In Linux, the default  limit of number of options a stack
>> will process is eight.
>
> Right.
>
> Cheers,
> Ole