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

On Thu, Oct 17, 2019 at 2:12 AM Mark Andrews <marka@isc.org> 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 site”

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'.

> > On 16 Oct 2019, at 20:19, Jen Linkova <furry13@gmail.com> wrote:
> >
> > On Wed, Oct 16, 2019 at 4:54 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
> >>>> On Oct 15, 2019, at 1:11 AM, Jen Linkova <furry13@gmail.com> wrote:
> >>>
> >>> 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.
> >>
> >> 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.
> >
> > --
> > SY, Jen Linkova aka Furry
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
SY, Jen Linkova aka Furry