Re: [6lo] Secdir last call review of draft-ietf-6lo-multicast-registration-16

["Eric Vyncke (evyncke)" <[e-mail]>]

[Trimming the recipient list]

Pascal,

The end of your reply to Scott’s review seems to indicate a new text, same applies to the secdir review.

Do you know when you will be able to provide such a revised I-D ?

Regards

-éric

From: Pascal Thubert <[e-mail]>
Date: Monday, 8 April 2024 at 11:35
To: Scott Kelly <[e-mail]>, [e-mail] <[e-mail]>, Eric Vyncke (evyncke) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Secdir last call review of draft-ietf-6lo-multicast-registration-16

Hello Scott

many thanks for the time and contributions to the progress of this document.
Le 30/03/2024 à 19:21, Scott Kelly via Datatracker a écrit :

Reviewer: Scott Kelly

Review result: Has Nits



I have reviewed this document as part of the security directorate's ongoing

effort to review all IETF documents being processed by the IESG. These comments

were written primarily for the benefit of the security area directors. Document

editors and WG chairs should treat these comments just like any other last call

comments.



>From the introduction, “This specification Extends [RFC8505] and [RFC9010] to

add the capability for the 6LN to subscribe anycast and multicast addresses and

for the 6LR to inject them in RPL when appropriate.”



I want to start by saying that I have little experience with the protocols

described in 8505 and 9010; I’d suggest that the AD have my security-related

comments double-checked with someone who has both security expertise and

expertise in these protocols.



Ack, Eric is now added to the "to" list to attract his attention.



As a general comment, it took me several passes to make sense of the

introduction. It seems to aim toward explaining the gaps motivating this RFC,

along with the building blocks this document uses to fill those gaps. It might

help readers to explain this from the outset, and to explicitly call out which

is which. There are still some paragraphs/sentences there whose purpose I don’t

understand.



For the security considerations, I have 2 suggestions: first, it currently

calls out the “security section” of RFC 8505. Shouldn’t it also call out the

security considerations of RFC 9010? Second (and I’m not sure about this), does

this extension potentially permit any new bad behavior (distinct from 8505 and

9010) that should be called out? I don’t understand the protocol nuances well

enough to say, but I’d have felt more certain if it said so explicitly.



Makes sense. The call out is easy to do. I'll ask the list for inputs on new security holes potentially being created by this.

On the RPL side, I do not see much since multicast was already there. We clarify the use of the sequence counter and add the concept of origin. I do not see an attack vector there but we can think twice about it.

As of using RFC 8505 on the first hop instead of RPL, we effectively add the capability to validate the origin of the registration, which was not present in RPL and could be the subject of a future ROV in RPL. So I'd say we are improving the security situation, denoting that the segregation allows less trusted devices to use the RPL network without allowing them to inject RPL messages directly, which could be a more ope attack vector for them.

I'll craft some text around the above if that's all right with you?

all the best;



Pascal