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

From: Ted Lemon via Datatracker <[email-masked]>
Date: Sat, 16 Nov 2019 15:36:19 -0800

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: Gyan Mishra <[email-masked]>
Date: Mon, 18 Nov 2019 01:50:15 -0500

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Nov 2019 02:30:54 -0500

> 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 communicat…

I don’t think you should mention anything that’s not ready to deploy.  SHIM6 is a neat idea that nobody has deployed, as far as I know, and it’s not clear that it can be deployed.  I may be wrong about that—that’s just my impression—but the point is that if you’re going to suggest something, it should be readily actionable.

> 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 pic…

Why do you need a split scope?  If the prefix is managed, just give out random addresses.   Use a good random number generator.  Use failover to keep the servers in sync.

DUID is opaque.  We recommended generating it using the MAC address because we hadn’t thought about privacy.   RFC7824 makes it clear that this is a problem.  Any DHCP implementation on a device where privacy is a likely issue should already be randomizing the DUID.  DUID-LLT with a random MAC address should be safe to use and unique.  It can be regenerated as frequently as the client decides.

But this isn’t really your problem.  You’re talking about network operational security, not about host operational security.   From the network perspective, you should just assume that this problem either is solved, or will be solved, because the network operator’s behavior is the same in either case.  In fact, given that we are talking about firewalls and filtering here, the fact that any client already can just fabricate a DUID means that you have to account for that when talking about the policy implications of this.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 19 Nov 2019 20:12:01 -0500

>> On Nov 19, 2019, at 2:30 AM, Ted Lemon <[email-masked]> wrote:
>> 

Agreed.
> Why do you need a split scope?  If the prefix is managed, just give out random addresses.   Use a good random number generator.  Use failover to keep the servers in sync.

See RFC 6853.

https://tools.ietf.org/html/rfc6853#section-6.1

With DHCPV6 all servers are active and that is why there is not any state sharing since the pool has to be different and there a a preference option as to which server is preferred.  This does go deeper into host configuration which is out of scope for this document so will leave out.
> DUID is opaque.  We recommended generating it using the MAC address because we hadn’t thought about privacy.   RFC7824 makes it clear that this is a problem.  Any DHCP implementation on a device wh…
DUID-LLT which is most commonly used still uses an embedded Mac but now along with time source to generate the DUID versus DUID-LL.

> But this isn’t really your problem.  You’re talking about network operational security, not about host operational security.   From the network perspective, you should just assume that this problem…
Agreed. I think staying on point with network operational security which is the goal of this draft and not drift into the weeds on host security.  That in itself could be a separate host operational security draft.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 20 Nov 2019 14:06:24 +0800

Hi Gyan/Ted,

> On Nov 20, 2019, at 9:12 AM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> On Nov 19, 2019, at 2:30 AM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Nov 18, 2019, at 1:50 AM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> https://tools.ietf.org/html/rfc6853#section-6.1 <https://tools.ietf.org/html/rfc6853#section-6.1>
> 

There are specific recommendations for this (generation of DUIDs) in Section 4.3 of RFC7844, essentially describing randomizing contents (and usage of “old” random timestamps for DUID-LLT). 

Regards
Suresh

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Nov 2019 04:53:20 -0500

> With DHCPV6 all servers are active and that is why there is not any state sharing since the pool has to be different and there a a preference option as to which server is preferred.  This does go d…

Right.  What I’m suggesting is that you explicitly recommend using DHCPv6 servers that support RFC 8156 rather than the less effective solution proposed in RFC 6853.  This recommendation will not be actionable for all network operators, but it should work well in enterprise settings.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 24 Nov 2019 02:11:56 -0500

Agreed. We will update the draft to reflect.

This is exactly what I have been looking for in an enterprise setting and I
see it’s authored by ISC.

Thank you for enlightening me.

Gyan

On Wed, Nov 20, 2019 at 4:53 AM Ted Lemon <[email-masked]> wrote:

> With DHCPV6 all servers are active and that is why there is not any state
> sharing since the pool has to be different and there a a preference option
> as to which server is preferred.  This does go deeper into host
> configuration which is out of scope for this document so will leave out.
>
>
> Right.  What I’m suggesting is that you explicitly recommend using DHCPv6
> servers that support RFC 8156 rather than the less effective solution
> proposed in RFC 6853.  This recommendation will not be actionable for all
> network operators, but it should work well in enterprise settings.
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Nov 2019 06:40:29 -0500

On Nov 24, 2019, at 02:12, Gyan Mishra <[email-masked]> wrote:
> This is exactly what I have been looking for in an enterprise setting and I see it’s authored by ISC.

The bulk of the work was done by Kim Kinnear when he was working at American Internet, and finished after Cisco acquired them. It’s an excellent piece of work. I’ve implemented an earlier version of the spec (I no longer so DHCP work).