Re: SLAAC on non-/64 networks

[Mark Smith <[e-mail]>]

Hi Tom,

On 10 April 2018 at 16:07, Tom Herbert <[e-mail]> wrote:

> On Mon, Apr 9, 2018 at 1:59 PM, Mark Smith <[e-mail]> wrote:
> >
> >
> > On Sat., 24 Mar. 2018, 20:35 Lee Howard, <[e-mail]> wrote:
> >>
> >>
> >>
> >> On 03/24/2018 07:39 AM, DaeYoung KIM wrote:
> >>
> >> On 24 Mar 2018, at 16:03, Mikael Abrahamsson <[e-mail]> wrote:
> >>
> >> We're already telling them to hand out /56:es, but that seems to be
> >> working so-so. Right?
> >>
> >> Where’s the document to strongly recommend or mandate that they SHOULD
> or
> >> MUST hand out /56:es?
> >>
> >> With the one for /64, I mean a strong recommendation or mandating as
> >> SHOULD or MUST.
> >>
> >> If ISPs still don’t comply, it’d only mean that IETF has simply lost its
> >> authority as an SDO.
> >>
> >>
> >> The only authority the IETF has is in ensuring interoperability.
> >>
> >> The only appropriate use for MUST is "If you don't do this, your stuff
> >> won't work with others' stuff."
> >>
> >> RFC2119 "Key words for use in RFCs to Indicate Requirements Levels"
> >> Section 6 Guidance in the use of these Imperatives:
> >>
> >> Imperatives of the type defined in this memo must be used with care
> >>    and sparingly.  In particular, they MUST only be used where it is
> >>    actually required for interoperation or to limit behavior which has
> >>    potential for causing harm (e.g., limiting retransmisssions)  For
> >>    example, they must not be used to try to impose a particular method
> >>    on implementors where the method is not required for
> >>    interoperability.
> >>
> >>
> >> (emphasis mine)
> >>
> >> I don't think the case has been successfully made that IPv6 (or higher
> >> protocols) fails to interoperate with the 64 bit boundary.
> >
> >
> >
> > TL;DR. removing the /64 boundary, and making it arbitrary, contradicts
> > BCP188 - "Pervasive Monitoring Is an Attack".
> >
> > Where the difference is between IPv4 and IPv6 is in terms of addressing
> > security and privacy.
> >
> > In my experience, at a number of corporate and residential ISPs, privacy
> and
> > security properties of addresses have not been a consideration in IPv4
> > because they couldn't be - there just weren't enough address bits for it
> to
> > be possible. It has been all about providing customers with as many
> > addresses as they needed, while also considering the scarcity of IPv4
> > addresses.
> >
> > We might not know how many bits are the minimum are required for
> addressing
> > privacy and security. However, I think we do know that more bits is
> always
> > going to be better.
> >
> > Today, with the /64 boundary, ISPs still don't specifically need to
> think of
> > customer address privacy and security - it is inherent in the size of
> /64.
>
> Mark,
>
> I disagree that privacy customer privacy is inherent in /64
> assignment.



I don't think I said that. What I was saying is that ISPs aren't in the
habit of considering customers' privacy requirements during IPv4 address
assignment during assignment, both because there wasn't an evident need
(i.e. pre-Snowden), and there weren't enough IPv4 addressing bits to do so
anyway. (I've never done it, and as recently as within the last month or
so, I've split up a public IPv4 /24 into /29s for customer assignments for
the most recent of 5 ISPs I've worked for.)

Unless the ISP service or product specifically offers security and privacy
as a feature e.g. IPsec VPN product, in my experience ISPs consider
customer privacy and security to be the customers' responsibility.



> In the very common case where /64s are being assigned to
> individual devices, all addresses created by the device will share a
> common unique prefix. The device is trackable based on the /64 prefix
> alone. The IIDs used by the device can change constantly, but that
> does nothing to prevent tracking of the device. This concern is
> mentioned in passing in RFC4941 and we examine it in more detail in
> draft-herbert-ipv6-prefix-address-privacy.
>

I think that is unrelated to the size of the IID itself, and is a privacy
issue related to and caused by the assignment of a single prefix to a
single device. As you've observed, the prefix becomes the host identifier.

Reducing the default size of the IID, or abandoning a default IID size,
isn't going to have any positive influence on host addressing privacy in
that prefix-per-host scenario. Reducing the IID size significantly would
help confirm to a remote attacker that the prefix-per-host assignment model
is being used, when e.g. despite their being a possible 2^64 IID values
within a conventional /64 prefix assignment (i.e. assignment to link or
host), all the IIDs come from within e.g. a /120 within an assumed /64
address space.

Regards,
Mark.



>
> Tom
>
> > Remove that boundary, and it won't suddenly be considered, and I expect
> will
> > be lost. I think ISP would be likely to inadvertently sacrifice customer
> > addressing privacy and security to retain IPv4 addressing methods and
> > practices because of their much more than a decade of familiarity with
> them.
> >
> > So /64 might not be a "MUST" or even a "SHOULD" to give the ability to a
> > host to have its own globally unique address to send IPv6 packets with.
> > However, from an address security and privacy perspective, probably not a
> > MUST, but I would certainly say a strong SHOULD.
> >
> > The IETF may not be able to dictate what operators do (and I agree with
> > that). However, the IETF is in a strong position to signal and emphasise
> > what's best to do (hence, BCPs). Default for parameters are the signals
> that
> > provide the properties that the IETF design to and for are those signals.
> >
> > Regards,
> > Mark.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>