Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Feb 2021 12:36:37 +0000

Gyan,

About your comment of DUID not having a MAC address in the 48 LSB bits, section 2.6.1.5 has now more text around this issue.

Hope this clarifies and thank you for being the document shepherd

-éric

-----Original Message-----
From: Gyan Mishra <[email-masked]>
Date: Monday, 18 November 2019 at 07:50
To: Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Iotdir early review of draft-ietf-opsec-v6-21
Resent-From: <[email-masked]>
Resent-To: Eric Vyncke <[email-masked]>, Kiran Kumar Chittimaneni <[email-masked]>, Merike Kaeo <[email-masked]>, <[email-masked]>, Ron Bonica <[email-masked]>, <[email-masked]>, Ignas Badonas <[email-masked]>, <[email-masked]>, Gyan Mishra <[email-masked]>, <[email-masked]>
Resent-Date: Monday, 18 November 2019 at 07:50

    Ted

    Thank you for the comments.

    In the abstract it does mention the audience but needs to be clearer as I agree to your point that this document is geared for a managed network and not for unmanaged or home network.

    ULA mentioned in section 2.1 mentions use case described in RFC 4864 but should mention section 3.2 of that document.  I think we could add some verbiage that ULA is used for local scope communications only. Also maybe a case of SHIM6 multi homing or where 6to6  nat - nat64 is used where ULA is inside local Nat to outside global address use case. Maybe also mention default address selection RFC 6724 where a host is configured with both ULA and Global and how ULA is used for internal local communications and how the global address is used for external internet communications.

    2.1.4 static does mention obfuscation of static address but 2.1.6 does not since DHCPv6 ISC or other DHCPV6 server implementations the pool address picked let’s say within the scope is randomly picked each time the server doles ourt an IPv6 lease by default and not picked sequentially by the server which is why obfuscation is not mentioned.   We could mention that is how the DHCPv6 sever picks the address so that is not confused.  We don’t mention split scope is required for redundancy which should be mentioned and how that works in comparison to IPv4 where state sharing is done between active and backup server where with DHCPV6 no active leases state sharing.  We will get that added as well.  Also a caveat with DHCPv6 that when the primary server goes down and the lease has to be renewed rebind time that the IPv6 address has to change at which time any active session will have to reset.  I have actually deployed this with BT Diamond which used ISC and to get around this issue we ended up setting a long 7 day lease time with larger block size for the scope being a /112 versus our initial /116 scope.  Also good to mention that since the 128 bits is managed to use smaller scope size for split scope then 2 /65 since their is not any privacy extension which stateful that for security it’s better to have a smaller DHCPv6 scope for managed address.  In section 2.1.6 the DUID has the mac embedded in the address embedded in the DUID as the 48 LSB bits.  Can you provide the use case where the DUID does not have embedded mac.  I agree  that 2.1.7 needs to some extra verbiage as to the use case of when and why addressing would be done as /64 per host and refer back to 2.1.4 static addressing use case.

    Thank you 

    Gyan

    Sent from my iPhone

    > On Nov 16, 2019, at 6:36 PM, Ted Lemon via Datatracker <[email-masked]> wrote:
    > 
    > Reviewer: Ted Lemon
    > Review result: On the Right Track
    > 
    > This is a review of draft-ietf-opsec-v6 from the IoT Directorate perspective.  
    > I am a volunteer on the IoT, and do not speak authoritatively for the IoT
    > Directorate as a whole.  My impression of this document is that it's useful,
    > but could use some work.   Some of my comments below are coming strictly from
    > an IoT perspective; others are more general.
    > 
    > ---
    > 
    > The document doesn't talk about its intended audience.  It appears to be the
    > case based on my reading of it that the intended audience is enterprise
    > operators and similar.  This should be stated clearly and explicitly.  Some of
    > the advice in this document would be actively harmful if deployed on an
    > unmanaged network (e.g. in a home).  That doesn't mean that the document is
    > bad—just that it needs to be scoped appropriately.   I would suggest adding a
    > brief statement of applicability in the abstract and a more detailed
    > explanation in the introduction.  It is important that this statement make
    > clear that the advice in this document must not be followed by implementers of
    > home routers and similar devices.   E.g., this advice would utterly break a
    > Thread (IPv6 over 802.15.4 mesh) Border Router.
    > 
    > It's also not clear that this document lives up to its abstract.   The abstract
    > says:
    > 
    >   This document analyzes the operational security issues in several
    >   places of a network (enterprises, service providers and residential
    >   users) and proposes technical and procedural mitigations techniques.
    > 
    > And yet if you look for example at section 2.1.1, there is no actual analysis
    > of the use of ULAs, nor is any advice on their use provided.
    > 
    > Section 2.1.4 doesn't mention using DHCP to provide hosts with obfuscated
    > address that, since known to the operator, can be added to filter lists as
    > appropriate, while still making probing mathematically challenging to an
    > outside attacker.
    > 
    > Section 2.1.6 incorrectly implies that DHCPv4 binds IP addresses to link-layer
    > addresses.  This is not true.  I don't know that it really matters, but since
    > it's not true, you should fix it.  DHCPv4 uses a "client identifier," which is
    > quite similar to a DUID.  If no client identifier is offered, then the
    > link-layer address is used, but this is not required, and the behavior
    > described for DUIDs in this document is also applicable to client identifiers.
    > 
    > 2.1.7 seems to be continuing a thought that was started in 2.1.4.  It would be
    > worth stating that explicitly, and comparing and contrasting these approaches.
    > 
    > Although the abstract explicitly excludes applicability to IoT networks, the
    > advice in this document will necessarily be taken as applicable in situations
    > where IoT networks are leaf networks or even infrastructure that is present
    > alongside the networks that _are_ covered by this document.  This has some
    > specific impacts that aren't talked about here and should be.   For instance,
    > Manufacturer Usage Descriptions (MUD) are not mentioned, and should be.   MUD
    > is applicable to infrastructure devices and really any special-purpose device;
    > e.g., MUD would be highly appropriate for use in hospital environments where
    > many devices are connected to the network that absolutely must have their
    > accessibility controlled; MUD is a good candidate for doing this.   The
    > omission of this approach from section 2,1 is a major gap, since the issues
    > discussed in section 2.1 directly impact the feasibility of using MUD (since
    > MUD specifies firewall behavior for devices, and devices are necessarily
    > identified by source address).
    > 
    > The conclusion I'm drawing having gotten to the end of section 2.1, in addition
    > to what I've said above, is that some of the issues introduced in subsections
    > of section 2.1, like filterability of host addresses, really belong in the
    > initial section 2.1 introduction, so that the subsections of 2.1 can refer back
    > and give the reader a coherent picture, rather than requiring the reader to
    > synthesize this as they read through the subsections.
    > 
    > Section 2.3.2 talks about the threat of a MITM attack through the use of forged
    > RAs, but doesn't actually describe how prevalent such on-link attacks are (this
    > would be an on-link attack) nor does it talk about how such an on-link attack
    > would be more effective than an attack the attacker could do without this
    > capability.  Without a threat model, this is somewhat hypothetical.
    > 
    > Section 2.3.2 goes on to talk at length about how to make RA Guard work,
    > without talking about when it is useful, what attacks it prevents, and what
    > problems it causes when deployed incorrectly.  We have actually run into
    > serious problems working on the Thread Border Router specification because of
    > uncertainty about whether RA Guard may be present on a network to which the TBR
    > is attached.  If it is, then the easiest way for the TBR to advertise
    > reachability is gone, and we have to resort to bypasses such as ND Proxy,
    > reverse NAT64, NAT66, or tunnels, just in order to ensure reachability of the
    > leaf network.
    > 
    > I think it's actively harmful to recommend the use of RA guard without talking
    > about the problems it causes and how to mitigate them.  This section should
    > explicitly say that RA guard should never be enabled by default: it should be
    > the case that the operator enables it explicitly, and that in cases where there
    > is no operator with the authority to set routing policy for a link, RA guard
    > should not be used on that link.
    > 
    > SAVI is another extremely useful technology that can't really be deployed
    > automatically without creating similar problems.  To be clear, my goal here is
    > not to say that the document shouldn't recommend RA guard or SAVI, but rather
    > that it should be very clear about when to deploy it and when not to.
    > 
    > In section 2.3.5, what is a "generic operating system?"   I don't know what
    > this term means.   Can you use a term with a clearer meaning?
    > 
    > One thing I didn't see discussed in section 2 that I think belongs there is the
    > concept of isolation of networks.  Networks that provide connectivity to
    > general-purpose devices like phones and comouters may need to provide
    > flexibility of addressing for privacy reasons.  Infrastructure devices,
    > particularly those for which MUD is applicable, may need to be on networks
    > where filtering is present and addressing is tightly controlled.  There's no
    > discussion fo this kind of separation in the document, and I think it's a
    > serious gap.
    > 
    >

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 9 Feb 2021 13:04:23 +0000

Ted,

Just to confirm that the revision -23 should have all your review items addressed except the 3 cited by Merike.

The section 2.3.2 has been revised extensively.

Thank you again for this review

-éric

-----Original Message-----
From: Merike Kaeo <[email-masked]>
Date: Thursday, 5 December 2019 at 20:13
To: Ted Lemon <[email-masked]>, Eric Vyncke <[email-masked]>, Kiran Kumar Chittimaneni <[email-masked]>, Enno Rey <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

    Hello Ted.

    Very much appreciate the thorough review of the document.  All 4 authors agree with most of your comments which will be incorporated
    in the next revision (also includes the discussion between yourself, Gyan and Suresh re DHCPv6).  For the comment re  section 2.3.2 and
    RAs,  can you point us to the relevant specifications for the TBR (Threat Boarder Route) so that we can come up with a potential addition that discusses the (non-) applicability of RA for certain scenarios?

    For 3 comments the authors want to preserve the existing language for reasons stated below.

    2.1.1 on ULA: The very first draft had some specific language on ULA use and the topic of ULAs has been a major contention area to get to working group last call.  Some individuals felt for years that the discussion on ULA should be to state that they are not required and not recommended while others wanted to be more explicit on recommended language *if* ULAs are used.  The current language on ULAs reflects working group rough consensus after many iterations of language.  Te authors would recommend that the language not be changed at this point.

    2.1.7 re /64s.  The section references rfc8273 and the working group felt that re-iterating even in more detail that work, which provides the added context, was not necessary in the document itself

    Last comment on Isolation of Networks -  While we did not discuss varying network configurations, usually more explicit details are provided in the rfcs we reference.  rfc8273 referenced in Section 2.1.7 and rfc7721 referenced in section 2.1.8 are some examples.

    - merike

    > _______________________________________________
    > OPSEC mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/opsec
    >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Feb 2021 09:23:41 -0500

> Just to confirm that the revision -23 should have all your review items addressed except the 3 cited by Merike.

Thanks, I look forward to seeing it on the datatracker! :)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Feb 2021 10:59:40 -0500

Éric, to be clear, your latest changes do not successfully address my comments. For example, you talk about a managed ISP router, and say that it’s okay for such a router to do all kinds of blocking on the home network. It’s not—what does the ISP know of the home network? How is the ISP qualified to set security and reachability policy on the home network?

This will cause major operational problems. Any network on which this is deployed will break stub networks, such as are used by the HomePod Mini and Google’s Nest gateway to provide reachability to Thread networks.

The text that I think you added to address my concerns is this:

   The residential users case assumes a managed ISP CPE
   device.  Some very specific types of networks such as the Internet of
   Things (IoT) and unmanaged home networks are not discussed in this
   document.

This is not helping. The text should read this way:

   This document is only applicable to managed networks, such as enterprise
   building networks. The recommendations in this document are not applicable
   to residential user cases, even in cases where an ISP may be managing the
   home gateway.

If you really want this to apply to the ISP-managed home network router, it should only be in the case where the ISP is providing a value-added service—where the home user is actually paying for a person to manage their network, not just to have an ISP-owned router that maybe gets regular firmware updates and some centrally-managed malware site blocking. If you were to address this use case (which I think is really unnecessary), this document needs to talk about what an ISP would have to do to avoid creating interop problems for IoT networks in the home. This needs to be very explicit and needs to be mentioned in the sections where you talk about RA filtering and ND filtering.

Sorry to be a sticky wicket, but I am afraid I failed to fully communicate the seriousness of this problem back in 2019.

Also, I don’t mean to minimize the problem you are trying to address. I’m just saying that we don’t have the technology to address it right now, and trying to address it on an effectively unmanaged network with existing technology will create serious interoperability problems.

In addition to the IoT stub networks issue, following this document on a home network would also eliminate multi-homing, which I hope is not something that we are proposing to do.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 12 Feb 2021 15:31:05 +0000

Ted,

As you guessed in your email : we, the authors, do not want to prevent multi-homing ;-)  E.g., we already have several ‘do not apply in all cases’ for several mitigation techniques include the RA-guard one for obvious reason.

Just to be clear, we have used your suggestion to modify the abstract and add an applicability statement in a -24 version (yet to be published). We would appreciate it if you reviewed the proposed change below.

--- start of abstract ---
   Knowledge and experience on how to operate IPv4 securely is
   available: whether it is the Internet or an enterprise internal
   network.  However, IPv6 presents some new security challenges.  RFC
   4942 describes the security issues in the protocol, but network
   managers also need a more practical, operations-minded document to
   enumerate advantages and/or disadvantages of certain choices.

   This document analyzes the operational security issues associated
   with several types of network and proposes technical and procedural
   mitigation techniques.  This document is only applicable to managed
   networks, such as enterprise building networks.  The recommendations
   in this document are not applicable to residential user cases, even
   in cases where a Service Provider may be managing the home gateway.

--- end of abstract ---

--- start of applicability statement (sub-section of introduction) ---
1.1.  Applicability Statement

   This document is applicable to managed networks, i.e., when the
   network is operated by the user organization itself.  Indeed, many of
   the recommended mitigation techniques must be configured with the
   detailed knowledge of the network (which are the default router,
   which are the switch trunk ports, etc.).  This covers Service
   Provider (SP), enterprise networks and some knowledgeable-home-user-
   managed residential network.  This applicability statement especially
   applies to Section 2.3 and Section 2.5.4.

   For example, an exception to the generic recommendations of this
   document is when a residential or enterprise network is multi-homed.

--- end of applicability statement (sub-section of introduction) ---

Regards

-éric

From: Ted Lemon <[email-masked]>
Date: Tuesday, 9 February 2021 at 16:59
To: Eric Vyncke <[email-masked]>
Cc: Merike Kaeo <[email-masked]>, Kiran Kumar Chittimaneni <[email-masked]>, Enno Rey <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

   document.

   home gateway.

On Feb 9, 2021, at 8:04 AM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:

Ted,

-éric

-----Original Message-----
From: Merike Kaeo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 5 December 2019 at 20:13
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Kiran Kumar Chittimaneni <[email-masked]<mailto:[email-masked]>>, Enno Rey <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

   Hello Ted.

   - merike

---

_______________________________________________
OPSEC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsec

---

From: Ted Lemon <[email-masked]>
Date: Fri, 12 Feb 2021 10:34:44 -0500

That’s a big improvement, Éric. Thanks!

> On Feb 12, 2021, at 10:31 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Ted,
>  
>> On Feb 9, 2021, at 8:04 AM, Eric Vyncke (evyncke) <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Ted,
>> 
>> From: Merike Kaeo <[email-masked] <mailto:[email-masked]>>
>> To: Ted Lemon <[email-masked] <mailto:[email-masked]>>, Eric Vyncke <[email-masked] <mailto:[email-masked]>>, Kiran Kumar Chittimaneni <[email-masked] <mailto:[email-masked]>>, Enno Rey <[email-masked] <mailto:[email-masked]>>
>> Cc: <[email-masked] <mailto:[email-masked]>>
>>> [email-masked] <mailto:[email-masked]>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 12 Feb 2021 15:43:17 +0000

Thank you Ted for the quick check.

I will immediately upload the revised I-D -24 to the datatracker

Regards

-éric

Date: Friday, 12 February 2021 at 16:35

On Feb 12, 2021, at 10:31 AM, Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:

Ted,

--- end of applicability statement (sub-section of introduction) ---

Regards

-éric

From: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 9 February 2021 at 16:59
To: Eric Vyncke <[email-masked]<mailto:[email-masked]>>
Cc: Merike Kaeo <[email-masked]<mailto:[email-masked]>>, Kiran Kumar Chittimaneni <[email-masked]<mailto:[email-masked]>>, Enno Rey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

   document.

   home gateway.

Ted,

-éric

-----Original Message-----
From: Merike Kaeo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 5 December 2019 at 20:13
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, Kiran Kumar Chittimaneni <[email-masked]<mailto:[email-masked]>>, Enno Rey <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

   Hello Ted.

   - merike

---

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 15 Feb 2021 19:33:47 -0800

Thank you Éric for making this change.

If ISPs were to to implement and enable RA-Guard in ISP-supplied home gateways, that would break both Apple HomeKit and the upcoming Project Connected Home over IP <https://www.connectedhomeip.com/>. It would be a pity to break residential IoT in the infancy of the IoT industry, and it would create a lot of support telephone calls for Apple, other residential IoT vendors, and ISPs.

Stuart Cheshire

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 11:34:56 +0100

Hi,

On Mon, Feb 15, 2021 at 07:33:47PM -0800, Stuart Cheshire wrote:
> If ISPs were to to implement and enable RA-Guard in ISP-supplied home gateways, that would break both Apple HomeKit and the upcoming Project Connected Home over IP <https://www.connectedhomeip.com/>. 

Why so?    What sort of RAs are these devices sending to the network
shared with the "home gateway"?

> It would be a pity to break residential IoT in the infancy of the IoT industry, and it would create a lot of support telephone calls for Apple, other residential IoT vendors, and ISPs.

If "basic network hygiene" creates support calls, something is not right.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 07:38:41 -0500

They provide non-default routes to the IoT network, of course. 

> On Feb 16, 2021, at 05:35, Gert Doering <[email-masked]> wrote:
> 
> What sort of RAs are these devices sending to the network

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 14:37:38 +0100

Hi,

> > shared with the "home gateway"?

Not sure what of that is "of course" and what "routes to the IoT network"
might be...

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 08:49:58 -0500

On Feb 16, 2021, at 8:37 AM, Gert Doering <[email-masked]> wrote:
> might be…

Router Advertisements advertise routers, prefixes, and routes, among other things. They can advertise a default router (and hence a default route), or they can advertise a non-default router that provides more specific routes, for example to an IoT stub network. Unless you prefer that we just bridge constrained networks to Wifi or Ethernet infrastructure networks at layer 2?

See https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00 (update coming soon)

FWIW, the situation for IoT (stub) networks is no different than the situation for multi-homing: you have two routers connected to the same link, both multicasting RAs to the link. Which one do you want your network infrastructure to automatically filter?

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2021 15:03:04 +0100

Hi,

On Tue, Feb 16, 2021 at 08:49:58AM -0500, Ted Lemon wrote:
> > might be???
> Router Advertisements advertise routers, prefixes, and routes, among 
> other things. They can advertise a default router (and hence a default 
> route), or they can advertise a non-default router that provides more 
> specific routes, for example to an IoT stub network. 

You say!  I wouldn't have guessed that.

So, where would that IoT network get their addresses from?

How would the router in my house know that it should listen to this
RA, so other routed segments will be able to reach the IOT segment?
(Routers do usually do not listen to RAs)

How would my machines be able to differenciate between "this is a good
RA" and "everything else that is sending a RA around is not"?

> FWIW, the situation for IoT (stub) networks is no different than
> the situation for multi-homing: you have two routers connected to
> the same link, both multicasting RAs to the link. Which one do you
> want your network infrastructure to automatically filter?

Arguably dual-RA multihoming is not working very well today.  

Like, "not at all".

Because hosts do not send their outgoing packets to the "right" router,
depending on source address, even if they should - and because routers do
not honour RAs, so if the hosts sends a packet to the "wrong" router, 
it will not be forwarded by "router A" to "router B", so it can be sent
to the correct ISP.  Assuming BCP38 filtering on the ISP side, of course.

HNCP had/has the potential to make that work in a very nice way.

Coming back to the original question: I think permitting some random
device to inject RAs into arbitrary networks to connect IoT stub networks
fully conforms to the mantra "the 'S' in IoT stands for 'Security'"...

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2021 09:19:23 -0500

> So, where would that IoT network get their addresses from?

To reach out to the cloud, it can use NAT64. To reach in, it needs IPv6, because there is no practical way to do NAT64 in the other direction. So the IoT router advertises an on-link autoconf prefix on the infrastructure link if there is no prefix on the link, and it advertises a non-default route to the prefix it’s advertising on the IoT network. Both prefixes are ULA prefixes, so it gets them by making them up with a random number generator. :)

> (Routers do usually do not listen to RAs)

If you have a multi-subnet home network, you will get the same behavior you get now for IoT devices connected to different links: they won’t be useable other than on the link to which they are attached. In the case of an IoT stub network, you will be able to use devices on the stub network on the link to which it is attached. If you want more than that, you can set up prefix delegation. In principle the stub router could do HNCP where it’s available, but since that’s nowhere, and since HNCP doesn’t solve the naming problem, there’s not much point.

> HNCP had/has the potential to make that work in a very nice way.

Actually that would be Babel. HNCP doesn’t solve this problem.

> fully conforms to the mantra "the 'S' in IoT stands for 'Security’"

What distinguishes a “random device” from a “not random device”? That’s the problem. If you are really concerned, you could have your “not a random device" filter out default RAs, but that would still cause operational problems—just fewer of them.

And BTW HNCP is no more secure than RA. And on an HNCP network RAs are vital for informing hosts of which router to communicate with, because default routes won’t work in a self-configuring mesh topology.

You might want to read the document I pointed you to.