Re: [RTG-DIR] Rtgdir last call review of draft-ietf-roll-turnon-rfc8138-10

[Alvaro Retana <[e-mail]>]

Pascal:


The link-layer security is a mechanism that applies to all the RPL
messages.  It doesn’t just apply to messages associated with this
document.  Making it required (or even just normatively recommending it) in
this document feels like overreaching because we’re just defining a flag,
not changing how the RPL adjacency works.

I rather go with something akin to the Security Considerations in, for
example, draft-ietf-roll-efficient-npdao (also approved by Ben)…which is
where I borrowed the "This document assumes that the security mechanisms as
defined in [RFC6550] are followed…” phrase from.


BTW, we should at least point the reader to the Security Considerations in
rfc6550 and rfc8138.


Thanks!

Alvaro.



On August 27, 2020 at 1:45:09 PM, Pascal Thubert (pthubert) (
[e-mail]) wrote:

Hello again Alvaro



We had a pass on similar text (with Benjamin K.) for the IESG review of
https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-21 (now in RFC
ED queue) and ended up with



   As indicated in [FRAG-FWD
<https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-21#ref-FRAG-FWD>],
Secure joining and the Link-Layer

   security are REQUIRED to protect against those attacks, as the

   fragmentation protocol does not include any native security

   mechanisms.



Indeed this requirement is common to anything 6LoWPAN or RPL. And MUSTing
it in the form above seemed to reach consensus.

In the case of RPL alone it’s either as above or one of RPL’s secured
modes, preinstalled of authenticated. RPL’s security section discusses the
last to but does not really say what to do with Unsecured. We could fill
that gap.



What about combining all this as:

“

It is worth noting that with [RFC6550], every node in the LLN that is
RPL-aware can inject any RPL-based attack in the network.

This document assumes that the RPL exchange are protected against on-link
attacks such as forged and replayed packets.

Section 10 of [RPL] proposes 3 security modes, Unsecured, Preinstalled and
Authenticated.

In the Unsecured Mode, secure joining and the Link-Layer security are
REQUIRED to protect against those attacks.

“



Keep safe,



Pascal

*From:* Alvaro Retana <[e-mail]>
*Sent:* jeudi 27 août 2020 19:18
*To:* Pascal Thubert (pthubert) <[e-mail]>; Stewart Bryant <
[e-mail]>
*Cc:* [e-mail]
*Subject:* RE: [RTG-DIR] Rtgdir last call review of
draft-ietf-roll-turnon-rfc8138-10



Sure…



I just to want to recommend anything that is not already specified
somewhere else for RPL.  :-)



On August 27, 2020 at 1:05:39 PM, Pascal Thubert (pthubert) (
[e-mail]) wrote:

Hello Alvaro 😊

I see your point.

> It is worth noting that with [RFC6550], every node in the LLN that is
> RPL-aware can inject any RPL-based attack in the network. This document
> assumes that the security mechanisms as defined in [RFC6550] are
followed.

This should be clarified a little bit. RPL has a security mechanism that to
my best knowledge no one uses (
https://tools.ietf.org/html/rfc6550#section-10).
What everyone uses is a Layer 2 access security. The text above seems to
recommend to use RPL's secured mode. Is there a way to reword that a bit?

Take care,

Pascal