Re: Lack of responses on WG Last Calls

[Brian E Carpenter <[e-mail]>]

For my sins, I was the Gen-ART reviewer for the main RPL spec,
so I was able to have a quick glance at these without being
completely mystified.

On 2010-12-17 02:53, Brian Haberman wrote:
> All,
>     Working group last calls ended 10 days ago for the two RPL-related
> drafts (draft-ietf-6man-rpl-option 

This looks basically OK to me. However:

> 9.  IANA Considerations
> 
>    The RPL option requires an IPv6 Option Number.

Shouldn't we have a "TBD" here, as used in the main text?
And an instruction to the RFC Editor to resolve the TBD
after IANA performs the assignment.

> 
>    HEX         act  chg  rest
>    ---         ---  ---  -----
>      1          01    1  01011
> 
> 
>    The first two bits indicate that the IPv6 node MUST discard the
>    packet if it doesn't recognize the option type, and the third bit
>    indicates that the Option Data may change en-route.
> 
>    This document also creates a new IANA registry for the sub-TLVs.  No
>    sub-TLVs are defined in this specification.  The policy for this
>    registry [RFC5226] is IETF Review.

I think the IANA will ask for a bit more guidance about the format
and name of this registry.

and
> draft-ietf-6man-rpl-routing-header). 

This defines a new routing header called RH4 (subject to
IANA confirming the "4"). One question that comes to mind
is whether this is going to cause more or fewer operational
difficulties than an instantiation of draft-ietf-6man-exthdr
would. Will legacy nodes treat RH4 as they should (discard the
packet), treat it like RH0 due to sloppy coding (which
amounts to the same thing under RFC5095) or what? Anyway,
it seems clear that RH4 will not successfully cross any
non-RPL-aware routers.

Now this may be deemed irrelevant because RH4 is "for use
strictly within a RPL domain." But it seems highly likely that
in practice, the odd non-RPL router will see one of these
headers. So at the least, I think the draft should discuss
what will happen in that case, even if only to point out that
the rules of RFC 2460 mean that the packet (not just the header)
will be dropped unless Segments Left is zero.

Then:

> 6.1.  Source Routing Attacks
> 
>    [RFC5095] deprecates the Type 0 Routing header due to a number of
>    significant attacks that are referenced in that document.  Such
>    attacks include network discovery, bypassing filtering devices,
>    denial-of-service, and defeating anycast.
> 
>    Because this document specifies that Type 4 Routing headers are only
>    for use within a RPL domain, such attacks cannot be mounted from
>    outside the RPL domain.  As described in Section 5, RPL Border
>    Routers MUST drop datagrams entering or exiting the RPL domain that
>    contain a Type 4 Routing header in the IPv6 Extension headers.

OK, but that implies that such attacks can still be mounted inside the
RPL domain. How is that OK, given that ROLL may be deployed in highly
dynamic scenarios where roaming nodes drop into a network at will?

   Brian