Subject: Re: [v6ops] draft-smith-v6ops-local-only-addressing

From: Ole Troan <[email-masked]>
Date: Mon, 2 Dec 2019 09:14:23 +0100

> On 30 Nov 2019, at 21:14, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> draft-smith-v6ops-local-only-addressing

I believe Townsley or was it Vyncke described a security model, where a device by default would only accept incoming connections on link-local or ULA addresses.
The device would have a global address that could be used for outbound connections, e.g. software updated.
Can't find or recall exactly where they described this model.

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Dec 2019 08:30:21 -0300

Mark,

Here are my comments:

* Meta:
I find it valuable to explore different ways of leveraging IPv6
addressing capabilities. In a way, it's a shame that given the lack of
advice we have in this area, hosts/application are doing, at best,
sub-optimal use of it.

* Things that I think that are missing:

  + It would seem to me that your document should somehow that CPEs and
DHCPv6 servers advirtise/lease ULAs, in addition of global
addresses/prefixes? -- otherwise, it will be more unlikely that these
devices get to configure ULAs

  + You might clarify that ULAs *might* be reachable from other networks
if not properly filtered at the border.

  + IIRC this one was discussed at the last IETF meeting: how would e.g.
automatic updates work?

  + The document should analyze why "only local" vs. "configure all, but
do not allow incomming comunications"

* Specific comments:

>    By default, a Local Only Address device MUST only configure Link-
>    Local and non-global IPv6 addresses, currently Unique Local Addresses
>    [RFC4193], on its network interfaces.

You might want to clarify the terminology esp in the context of RFC8190.

>    By default, if there are no ULA prefix PIOs in the received RAs, or
>    no ULA prefix PIOs with the A flag set, the Local Only Addresses
>    device MUST only configure IPv6 Link-Local addresses on its network
>    interface.

The text might be misleading/mis-interpreted: normally, at point you
process RAs with PIOs, you have already configured link-locals.  (the
text might be interpreted like you configure them when there are no ULA
prefixes with the A bit set).

>    By default, if there are ULA prefix PIOs that do not have the A flag
>    set, they MUST be processed per standard RA PIO processing for other
>    flags.  For example, a PIO for a ULA prefix, with the A flag unset,
>    and the L or on-link flag set, is still processed, and is asserting
>    that the specified ULA prefix is on-link.

I'd omit this para -- you are not changing the current state of affairs.

>    If the Configure All IPv6 Addresses configuration switch is enabled,
>    then the Local Only Addresses device MUST process all IPv6 RA PIOs
>    received for SLAAC address configuration, per [RFC4862], from that
>    point in time onwards.

Same here. So I'd rephrase as ""If... normal processing of RAs takes
place, honoring all prefixes" or the like.

> 
>    By default, a Local Address Only device MUST NOT accept any upper
>    layer connections from any global IPv6 addresses.

s/upper layer/transport layer/?

>    An application may attempt to overcome this global IPv6 address
>    constraint by constructing packets itself that contain a global IPv6
>    address source address.  T

Not sure what this means.... the app crafting IPv6 pckets?

Thanks!

Cheers,
Fernando

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Dec 2019 11:55:30 -0800

I think you're thinking of an opec draft by Michael Behringer, https://tools.ietf.org/html/rfc7404. In essence, it suggests that routers only talk with each other and their local hosts using link-layer addressing in the "destination" address. 

To my way of thinking, forcing that for all sessions means that one cannot access a device from a system that it is not directly connected to. Michael's proposal was in essence to prevent attacks on routers, permitting them to white-list network management devices and exclude pretty much everything else. Doing that for hosts would make the network pretty useless, I suspect. 

> On Dec 2, 2019, at 12:14 AM, Ole Troan <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Mon, 2 Dec 2019 22:33:06 +0100

Hi Fred,

> To my way of thinking, forcing that for all sessions means that one cannot access a device from a system that it is not directly connected to. Michael's proposal was in essence to prevent attacks o…

No it wasn't that one.
It was very much along Mark's lines of increasing security by controlling reachability and scope of addressing to end hosts.
Perhaps it was just something he talked about when Eric and he did advanced-security.

Regardless, seems like a fine idea. Devices that have no business being on the Internet, should as Mark proposes by default not have a global address.
Now you might argue, are there really any such device.

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Dec 2019 13:13:35 +1300

>> To my way of thinking, forcing that for all sessions means that one cannot access a device from a system that it is not directly connected to. Michael's proposal was in essence to prevent attacks…

Well, there's always https://tools.ietf.org/html/rfc4864#section-3.2

And of course we punted on https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Dec 2019 13:42:42 +1300

A few somewhat random comments:

1. A nit, but a major nit: the use of the word "global".

Repeat after me: ULAs are global scope addresses. They are explicitly defined as having global scope in RFC4193.

Also repeat after me: ULAs are not globally reachable addresses. They are explicitly forbidden to be routed globally by RFC4193.

Yes, this could be confusing; that's why we have RFC8190. But each occurrence of "global" in the draft needs to be reviewed, and if appropriate, replaced by either "with global scope" or "globally reachable". For example, the last sentence of the Abstract should be: "This memo proposes that these types of devices refuse to configure and use globally reachable IPv6 Internet addresses by default."

2.

> 2.  Default Local Only Addresses
> 

That will fail if the router doesn't announce a ULA prefix. What do you want the default behaviour to be in that case?

OK, I see that you cover this point later under SLAAC but it seems to me that it is a general that point should be covered here. And I think your recommendation is broken from a practical point of view: if a device is installed on a routed network that does not announce a ULA prefix, limiting it to link-local is simply broken as it prevents the devices from being accessed by devices on other subnets.

So I think the only practical proposal is that if and only if both ULA and globally reachable prefixes are announced, the device should configure only a ULA.

> 5.  Permitted Incoming and Outgoing Connections
> 

This is a case where s/global/globally reachable/ is essential. I agree with it, although default settings in many CE routers will already do this.

You probably need to discuss "call home" scenarios, which many vendors want to include in their products and which clearly need globally reachable addresses.

Finally, I think there are points mentioned in https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-4.2 and even in RFC4864 that should be considered.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 2 Dec 2019 22:32:03 -0300

> And of course we punted on https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02

It's a shame that work in this area hasn't been pursue whether in this
document, or elsewhere.

Similarly, we did: draft-gont-6man-address-usage-recommendations-, which
has broader scope.

At the end of the day, we have all these different IPv6 address sorts
but nodes/apps don't leverage them due to lack of appropriate advice.

Thanks,

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 3 Dec 2019 19:52:30 +0100

Le 30/11/2019 à 21:14, Ron Bonica a écrit :
> Folks,
> 
> Each week between now and IETF 107, we will review and discuss one draft 
> with an eye towards progressing it.
> 
> This week, please review and comment on 
> draft-smith-v6ops-local-only-addressing.

I have read it, thanks for the pointer.

We have such a setting with a convoy of three IP/V2V autonomous cars; we 
only have ULAs and LLs in there, even though I hope one day GUAs will 
reach them.

Where draft says fc::/7 for ULA it is wrong, or am I again fooled by 
bits; shouldnt that rather be fc00::/7?

The configuration option Configure All IPv6 Addresses SHOULD be on by 
default.

>    device MUST only configure IPv6 Link-Local addresses on its network

... and me  who wanted to put fe80::/10 in PIOs :-(

> changed
>    from enabled to disabled,

earlier it says 'ommited' too, so there might be a problem for 
programmer to distinguish between the latter two.

Alex

>                                                               Fred and Ron
> Juniper Public

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Dec 2019 16:47:05 -0800

> On Dec 3, 2019, at 10:52 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Where draft says fc::/7 for ULA it is wrong, or am I again fooled by bits; shouldnt that rather be fc00::/7?

Yes