Re: [Roll] Benjamin Kaduk's No Objection on draft-ietf-roll-unaware-leaves-26: (with COMMENT)

[Michael Richardson <[e-mail]>]

About how to mark MOP=7

Pascal Thubert \(pthubert\) <pthubert=[e-mail]> wrote:
    > I have (plenty of) coffee, it's early afternoon, I had (almost) no red
    > wine at lunch... I'm ready for your review comments : ) : )

I'm thinking that there is a market for caffeinated red wine.
Maybe that's already covered by Redbull+Vodka for some.

    bk> I still feel that if we're going to incrementally add new properties to MOP 7, we
    bk> should list the relevant documents as references in the registry until MOP 7 is
    bk> fully specified.  In this case we can arguably get away with not doing so since this
    bk> document Updates: RFC 6550 already and thus could be said to be doing the
    bk> reservation by modification of the core protocol, but we are not using that
    bk> procedure universally (e.g., for turnon-rfc8138) and it seems prudent to use a
    bk> consistent mechanism.

    > Yes, we have a github page for that, see
    > https://github.com/roll-wg/RPLv2; I added your concern above in there.

But, Ben is suggested that turnon-rfc8138, unaware-leaves and useofrpinfo
should all be listed under IANA MOP=7 until we actually publish RFC6550
and/or mopex/capex.

Ben, I hadn't thought of that, and I like it.
How do we do this?

    >> A RUL is not expected to support the compression method defined in
    >> [RFC8138].  For that reason, the border router uncompresses the
    >> packet before forwarding it over an external route to a RUL
    >> [USEofRPLinfo].
    >>
    >> Just to confirm: the "border router" here is not the 6LBR but rather a "normal"
    >> 6LR (i.e., an "RPL border router")?

    > Yes; I changed to " the border router (the 6LR here)". Since we now
    > have external routes, we now have a southern border as well.

Yeah, so we have international (EGP) borders, and we have municipal (IGP/ND) borders.
But, even EGP/IGP are really inaccurate terms, since the 6LBR could well speak OSPFv3,
to the rest of the Enterprise.   I wonder if the RTG-area group might want to
suggest some new terms here for us.

    >> message are taken from the Transaction ID and the Address
    >> Registration lifetime in the NS(EARO) message from the 6LN.
    >>
    >> Reusing an identifier taken from one context in one protocol to play a role in a
    >> different context in a different protocol has historically led to security-relevant
    >> flaws/attacks.  What kind of analysis has been done to consider the risk of such
    >> issues here?

    > None. I have no idea what opening this creates.
    > All I can say is that as opposed maybe to your examples, the TID was
    > designed to be mapped onto RPL from the beginning and to mean the same
    > thing.

    > If you look at the text in RFC 8505 for the TID: It is the verbatim
    > copy of the text for the Path Sequence in RPL. It's easier to drive
    > when you know where's you're going 😊. For the lifetime, we had to go
    > through a translation.

These are identifiers at the ICMPv6/"ND" level.
It might be important to recognize that RPL control messages live inside IPv6
ICMPv6.  So they are alongside ND messages as well.
The typical case where the identifier problem occurs has been for things that
received different kinds of protection.
I feel confident that it's okay.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide