Subject: [v6ops] Default IPv6 Local Only Addressing for Non-Internet Devices (Fwd: New Version Notification for draft-smith-v6ops-local-only-addressing-00.txt)

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 14:29:17 +1100

Hi All,

Recently bought an IPv6 capable Wifi printer. As it is attached to my
single Wifi SSID, it is also configuring IPv6 GUA addresses, even
though it doesn't need or need to be reachable from the Internet in my
use (i.e. I'm not using "cloud printing" or similar).

I thought it would be better for these types of devices to only
configure routeable addresses from the ULA address space by default,
unless that is overridden.

Comments most welcome.

WG Chairs, I'm attending IETF-106, so I'd like a presentation slot for this.

Thanks very much,
Mark.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, 15 Oct 2019 at 14:24
Subject: New Version Notification for
draft-smith-v6ops-local-only-addressing-00.txt
To: Mark Smith <[email-masked]>

A new version of I-D, draft-smith-v6ops-local-only-addressing-00.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-v6ops-local-only-addressing
Revision:       00
Title:          Default IPv6 Local Only Addressing for Non-Internet Devices
Document date:  2019-10-14
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-smith-v6ops-local-only-addressing-00.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-v6ops-local-only-addressing/
Htmlized:
https://tools.ietf.org/html/draft-smith-v6ops-local-only-addressing-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-smith-v6ops-local-only-addressing

Abstract:
   For certain types or models of devices it should be clear and obvious
   that, by default, they should not be reachable from the global IPv6
   Internet, or able to reach the global IPv6 Internet, even though the
   network they are attached to provides global IPv6 Internet
   connectivity.  This memo proposes that these types of devices refuse
   to configure and use global IPv6 Internet addresses by default.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Oct 2019 23:33:19 -0400

> unless that is overridden.

How does the device know that it is “that type of device?”   Also, don’t you want it to fetch firmware updates?

You should probably look at MUD—that’s a better approach to this sort of problem, and doesn’t rely on address routability as a proxy for access control.

---

From: Jen Linkova <[email-masked]>
Date: Tue, 15 Oct 2019 19:11:00 +1100

> unless that is overridden.

The draft says '...when it is clear to a device manufacturer that a
device should be isolated from the Internet by default..'
I'm not sure it's possible to know that. Isolation from the Internet
is the policy decision, not smth which is a function of the device
type.
I'm not sure that devices listed in the section 6 should by default be
'isolated from the Internet' - actually I believe otherwise.

All those devices can be installed not just in a single-subnet home
network but in SMB or enterprise-like networks. In that case
reachability to/from global addresses would be required.

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

-- 
SY, Jen Linkova aka Furry

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Oct 2019 10:15:53 +0200

Hi,

> device should be isolated from the Internet by default..'

I'd say that most devices built by manufacturers today SHOULD be
isolated from the Internet...  but I'm afraid that *manufacturers*
are never going to agree that their shiny new toys are not mature
enough...

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: Dmytro Shytyi <[email-masked]>
Date: Tue, 15 Oct 2019 17:02:10 +0200

Hello,

>From the point when device is connected to the internet it becomes a Node that could be reached outside by external users.

The firmware of such devices is updated not that frequenly. It could be dangerous.
>From the point I put my device in DMZ in few moments i see in the log the "Access denied via ssh for user root".

Thus, I think, it is an important thing the authors of the draft highlight.
______________
Dmytro SHYTYI

---- On Tue, 15 Oct 2019 10:15:53 +0200 Gert Doering <[email-masked]> wrote ----

Hi, 

 
Gert Doering 
 -- NetMaster 

mailto:[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Oct 2019 11:13:53 -0400

> The firmware of such devices is updated not that frequenly. It could be dangerous.

True.

> From the point I put my device in DMZ in few moments i see in the log the "Access denied via ssh for user root".

Yes, we all see these sorts of things.

> Thus, I think, it is an important thing the authors of the draft highlight.

The problem is that this is not really a good way to solve the problem, and I’d be surprised if anyone implemented it.  If you and/or the authors want to work on this problem, I think that would be worthwhile, but I think you need to think about a different solution.   That’s why I suggested that you look at the work that is being done with MUD (e.g., RFC 8520).

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Oct 2019 22:51:19 -0700

> On Oct 14, 2019, at 8:29 PM, Mark Smith <[email-masked]> wrote:
> 
> Hi All,
> 

As always, I'm looking for a posted draft, and I'm looking for supportive working group commentary when it is posted. When you post it, you will get an email from the secretariat. I'd suggest you "reply" to it, but retrain it to v6ops@, describe your intentions, and request comments.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Oct 2019 22:54:36 -0700

> On Oct 15, 2019, at 1:11 AM, Jen Linkova <[email-masked]> wrote:
> 
> I'm not sure it's possible to know that. 

It *is* possible for the device to prevent its packets from going elsewhere, assuming routers and proxies behave according to the rules and people aren't translating. That is a defined function of ULAs and Link-Local addresses.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 16 Oct 2019 20:19:12 +1100

On Wed, Oct 16, 2019 at 4:54 PM Fred Baker <[email-masked]> wrote:
> It *is* possible for the device to prevent its packets from going elsewhere,

Sorry I should have clarified: I'm questioning the statement that it's
possible (or should be done) to know at the time of manufacturing that
this particular
device should be isolated from the Internet.
Let's say I'm buying a printer. Or an IoT device (a sensor). How can
the manufacturer know if I'm going to install it at my mom's home
network with just one subnet (the link-local address would be
sufficient), at my place (with subnets, so GUAs are needed or at least
ULAs - but I would mean I have to configure my routers) or at my
office (so GUA are required for the device to work)?

Will I need to look for 'work with multiple network segments' sticker
on a box before I buy a device (and shall I test it in the lab because
vendors tend to be overly optimistic about their products feature
set)?

> assuming routers and proxies behave according to the rules and people aren't translating. That is a defined function of ULAs and Link-Local addresses.

Not sure about ULAs. The ULA has global scope. If a device has a
default gateway and ULAs only nothing would prevent it from sending
packets with ULA source to any destinations. The network is expected
to have a *policy* configured at its edge to block ULAs - so we are
back to 'it's a policy decision if this device should or should not
have  global connectivity'. Let the administrator decide.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2019 02:12:01 +1100

Jena , how does the attacker route the traffic to the ULA address of the device?  GUA to ULA works within the site.  Getting it to work from outside the site is another matter.  

First you have to find a border router with ULA filtering disabled.  Home border routers have ULA filtering on by default if they want to be certified by cablelabs etc.  Then you have to also have a border router that processes source routed packets as ULA routes aren’t carried be default.  Again something that is supposed to be blocked on border routers by default. 

Printers could also default to only accepting connections from the containing /48 of advertised RA prefixes. This works fine for ULA and reasonably well for GUA in restricting traffic to “intra site”

It would work better if ISPs would hand our /48s. 

-- 
Mark Andrews

> On 16 Oct 2019, at 20:19, Jen Linkova <[email-masked]> wrote:
>

---

From: Simon Hobson <[email-masked]>
Date: Wed, 16 Oct 2019 21:36:33 +0100

Gert Doering <[email-masked]> wrote:

> are never going to agree that their shiny new toys are not mature

Not only that, but these days everything is "internet connected" regardless of whether that actually adds anything useful*. I can't see many (if any) manufacturers defaulting to *not* internet connected.

* Eg, a made up example of a light "switch" and associated "smart" lights that don't work without taking to a controller "somewhere out in the internet" just so the user can control their lights from anywhere.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 17 Oct 2019 10:14:10 +1100

On Thu, Oct 17, 2019 at 2:12 AM Mark Andrews <[email-masked]> wrote:
>
> Jena , how does the attacker route the traffic to the ULA address of the device?  GUA to ULA works within the site.

What is the 'site'?

>Getting it to work from outside the site is another matter.

Scenario 1: we have devices which are technically able to talk to each
other. You can either use this functionality or if you don't -
implement security policies to block such traffic.
Scenario 2: we start creating devices which looks like a normal
Ipv6-enabled ones but they can only work in a very limited set of
scenarios and if I want them to work in an arbitrary network, it would
be, as you've correctly noticed, 'another matter'. I see this as an
attempt of solving one particular and very specific use case on the
expense of everyone else.

If someone needs to prevent accidental access to subset of their
devices from the Internet w/o putting any effort into implementing
security policies why would not they just install devices w/o IPv6
support whatsoever? Use Ipv4 link-local addresses (or any other IPv4
addresses) and disable IPv4 NAT...
Could be a great selling point 'built-in protection from unauthorised
access: no IPv6 support'.

> First you have to find a border router with ULA filtering disabled.
>Home border routers have ULA filtering on by default if they want to be certified by cablelabs etc.

Let's keep in mind that there are other scenarios besides 'a home
router connected to an ISP network'.
Last time I had a Cisco router as my home DSL device it was definitely
able to route packets to/from ULAs.

> Printers could also default to only accepting connections from the containing /48 of advertised RA prefixes. This works fine for ULA and reasonably well for GUA in restricting traffic to “intra sit…

This creates a serious artificial limitation by introducing an entity
called 'a site' on the host network stack level and enforcing very
specific IPv6 address plan.

> It would work better if ISPs would hand our /48s.
...and now it affects ISPs...

What I'm trying to say is that the use case for the proposed approach
is way to narrow to justify all consequences (and inconvenience
caused).

Like we haven't had enough issues with IPv6 support on
non-phones/laptops - let's make our life even more entertaining ;)
On the other hand indeed it could be a selling point for device
vendors: 'you can print on that printer from another office building'
and 'you can actually connect to our IoT sensors from your DC/Cloud,
not just from a workstation sitting next to it'.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Oct 2019 12:25:21 +0200

Hi,

> On 16 Oct 2019, at 11:19, Jen Linkova <[email-masked]> wrote:
> 

Ted mentioned RFC 8520 and Manufacturer Usage Descriptions.  Here the manufacturer can tell you what it was designed to access.  That’s not to say that you have to grant that access, but that some functions may be lost if you don’t grant that access.

For a consumer device, this can mean different things:

Device won’t work at all (Echos, Hey Google)
Device will work perfectly without Internet access or any local access (most kitchen and home appliances)
The device will lose some functionality but otherwise operate (no firmware updates, maybe no notifications about malfunctions, status, etc).

Whether you want to grant access probably should not be made based on the IP address, but on the network access control function.

Eliot

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Oct 2019 14:51:47 +0200

Le 15/10/2019 à 17:02, Dmytro Shytyi a écrit :
> Hello,
> 
> From the point when device is connected to the internet it becomes a
>  Node that could be reached outside by external users. The firmware
> of such devices is updated not that frequenly. It could be 
> dangerous. From the point I put my device in DMZ in few moments i see
> in the log the "Access denied via ssh for user root". Thus, I think,
> it is an important thing the authors of the draft highlight.

True, the network topology that involves a DMZ is another way of solving
the problem.

Yet one may wonder how the address scoping solution would work together
with a network topology solution involving a DMZ.  Is ULA space to be
used within the DMZ and GUAs on both sides of it, such that to better
protect legitimate end users from attackers?

Formulating a problem statement would help.

Alex

> ______________ *Dmytro SHYTYI*
> 
> 
> ---- On Tue, 15 Oct 2019 10:15:53 +0200 *Gert Doering
> <[email-masked]>* wrote ----
> 
> Hi,
> 
>> The draft says '...when it is clear to a device manufacturer that
>> a device should be isolated from the Internet by default..'
> 
> isolated from the Internet... but I'm afraid that *manufacturers* are
> never going to agree that their shiny new toys are not mature 
> enough...
> 
> Gert Doering -- NetMaster -- have you enabled IPv6 on something
> today...?
> 
> D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444
> USt-IdNr.: DE813185279
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] <mailto:[email-masked]> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>