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

[Tom Herbert <[e-mail]>]

On Sun, Aug 19, 2018 at 8:10 PM, C. M. Heard <[e-mail]> wrote:
> On Sun, Aug 19, 2018 at 1:30 PM, Tom Herbert <[e-mail]> wrote:
>> On Sat, Aug 18, 2018 at 1:22 PM, C. M. Heard <[e-mail]> wrote:
>>> On Sat, Aug 18, 2018 at 11:06 AM, Tom Herbert <[e-mail]> wrote:
>>>> On Sat, Aug 18, 2018 at 10:16 AM, C. M. Heard <[e-mail]> wrote:
>>>>> First, the proposal makes processing of a Destination Options header that
>>>>> precedes a routing header optional for the final destination node, to
>>>>> which the stated rationale clearly does not apply.
>>>
>>> Would you care to address this objection?
>>
>> The allowance would have to cover all destination nodes including the
>> last one because there is no way to to know a node is last in the
>> routing list without processing the routing header which would violate
>> RFC8200. I would note that this wouldn't impact DestOpts after a
>> Routing header which must be processed only by the final destination.
>
> True, but surely a node that can process a Destination Options header that
> follows a Routing Header -- which an end node must be able to do -- also has
> the capability to process a Destination Options header that precedes a
> Routing Header. It should not matter whether or not it is the final
> destination of the packet.
>
Mike,

Yes, that would be true if the final destination is a compliant host
stack (e.g. Linux). In that case Hop-by-Hop options as well as
Destination options before or after a Routing header are properly
parsed. As I mentioned, we can now limit the number of TLVs that are
parsed to reasonably limit processing and prevent some denial of
service attack, but there's no motivation for these stacks to start
completely ignoring options all together-- it's only a MAY in RFC8200
that a stack can ignore HBH and a MAY in this draft to ignore DestOpts
.

The negative converse also seems to be true. If an implementation does
not support parsing of Destantion Options before the Routing header,
then the node probably doesn't support parsing of any Destination
Options. This becomes an issue in router implementations that
terminate tunnels int the network with intent to and forward the
tunneled packets. For instance FD.io VPP supports VXLAN, LISP, SR-IPIP
among other encapsulations, AFAICT if the implementation receives an
encapsulated packet addressed to the node that has a Destination
Option (second type that follows any Routing header), either the
packet is either dropped or the Destination options are ignored.

Tom

> [ ... ]
>
>>> Do you know how that
>>> all works for the implementations(other than Linux) that are listed in
>>> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-14#section-8?
>>
>> Linux properly implements Destination Options (both before and after
>> Routing header), including handling of unknown TLV types. It also now
>> limits the number of TLVs per the recommendations of RFC6434bis (eight
>> is default limit).
>>
>> I looked at FD.io VPP code. AFAICT they do NOT implement compliant
>> support for Destination Options. It appears that the Routing header is
>> being fished for using the function ip6_ext_header_find_t. That
>> function will skip over Destination Options before the Routing header.
>> There are only two inconsequential references to
>> IP_PROTOCOL_IP6_DESTINATION_OPTIONS (nexthdr constant) in all the VPP
>> code, and I can't find any evidence that Destination Options TLVs are
>> ever parsed.
>>
>> I looked for information on P4 how implements this an couldn't find
>> much of relevance. As I understand it, P4 does not natively support
>> loops so parsing an unlimited list of TLVs might not be feasible,
>> although maybe it's possible to parse a small number of them.
>>
>> For commercial implementations, like Cisco and Juniper, I'll let it up
>> to the vendors to report whether or not they have proper support for
>> Destination Options and how much they have tested that.
>
> Thanks for providing that information.
>
> Mike Heard