[secdir] Re: [Roll] Secdir early review of draft-ietf-roll-enrollment-priority-10

[Michael Richardson <[e-mail]>]

{I'm sorry to take so long to reply}

Rifaat Shekh-Yusef via Datatracker <[e-mail]> wrote:
    > The following is a quote from the Security Consideration section of the
    > draft: "The use of layer-2 or layer-3 security for RPL control messages
    > prevents the two aforementioned attacks, by preventing malicious nodes
    > from becoming part of the control plane."

Yes.

    > The following quote is from RFC7416, section 7.1.2: "A number of
    > deployments, such as [ZigBeeIP] specify no Layer 3 (L3) / RPL
    > encryption or authentication and rely upon similar security at Layer 2
    > (L2).  These networks are immune to outside wiretapping attacks but are
    > vulnerable to passive (and active) routing attacks through compromises
    > of nodes (see Section 8.2)."

Yes, I wrote much of that document too.
(I was voluntold around 2010)

    > The draft seems to suggest layer-2 security might be sufficient
    > protection, while RFC7416 seems to suggest that solely relying on
    > layer-2 might not be enough.

So, the tension is that in RPL, layer-3 security involves the use of the
secured RPL messages, and in order to make it sensible, requires use of
assymetric algorithms (RSA, EcDSA, EdDSA, etc.)

Back a decade (+) when RFC7415 (and RFC6550) was being developed, most were
skeptical that we could do such signatures on constrained devices at a speed
(and power consumption basis) that would be practical.  Today, many M-class
CPUs have some accelerations that would help a lot, but that still requires
that the assymetric keys be provisioned.  BRSKI (RFC8995) was one protocol
that came out of this work to fill the gap.

However, to date I'm aware of no RPL implementations that actually implement
the secured L3 messages.  (I really wish that wasn't the case)

Secured L3 messages are better for control plane security because they
eliminate the possibility of one node impersonating another node.  This could
be accidental or malicious (malware).

This is also true of all the other routing protocols.  BGP continues to
struggle with this, for instance.  RPKI deals slightly with authorization,
but there is significant work still to do, and the core routers don't suffer
from being power constrained.
Secured L3 messages also allow for the possibility that not all nodes are
authorized to become routers (6LRs) and must remain as leaf nodes.

However, Secured L3 messages do nothing to enhance the privacy of the
network.  While IPsec (also L3) and application layer security (TLS, OSCORE) can help
here, absent a secured L2, a non-participating malicious node would be able
to view or forge traffic, even if it would be unable to disrupt existing
traffic.

    > RFC7416, section 8.2 states: "RPL provides for asymmetric
    > authentication at L3 of the RPL Control Message carrying the DIO, and
    > this may be warranted in some deployments."

    > I feel that this should be discussed here to make it clear that in some
    > deployments, layer-2 by itself might not be sufficient and the use of
    > asymmetric authentication at L3 might be required.

I think it's inappropriate in a short extension document to re-litigate the
work that RFC7416 already did.   I have however, rewritten the section
slightly to attempt to emphasize that L3 security does not provide privacy.

https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/commit/467947fd192a25fca0c1b3e07a20096c6b8d2126

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