Re: WG Last Call for for draft-ietf-6man-rfc6874bis

[Ted Lemon <[e-mail]>]

It sounds like you’re reinventing dns-sd + mDNS. I think the usual use case
for IPv6 address literals is that you cut and paste them from the terminal.
I don’t think we need to mandate LLAs printed on the box.

On Fri, Jun 17, 2022 at 23:51 David Farmer <[e-mail]> wrote:

>
>
> On Thu, Jun 16, 2022 at 9:55 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> On 17-Jun-22 01:36, Ted Lemon wrote:
>> >
>> > In the security considerations section, I think if the syntax were only
>> allowed in the case of input into the browser's dialog box, then most of
>> the possible attacks would go away. If there is no anticipated use case
>> other than manual input (perhaps a scripted input would also count) then
>> unless the script would be allowed to open the URI but not otherwise probe
>> IPv6 address literals, it's hard to see what additional vulnerability this
>> would create.
>>
>> I still have to review Phillip Tiesel's comment carefully, but if there
>> is a real exploit, I'm pretty sure it would have to be Javascript, trying
>> to find other devices on the LAN. I'm not sure why that would be more
>> interesting than trying to find other devices with routeable IPv6 addresses
>> in the same prefix, which is feasible today (and the reason why we
>> recommend pseudo-random interface IDs). And at least on a Windows target,
>> you don't need a Zone ID, so you could do it today. But the search space is
>> still 2^64 in all cases. That's our primary defence against such attacks.
>>
>> I can, however, see use cases where embedding such a URL in a web page
>> would actually be useful to a service technician, so I'm fairly sure that
>> saying "don't do this" won't work.
>
>
> This got me thinking a bit;
>
> Maybe a short discussion, probably in an appendix, of LLA
> assignment strategies that are operationally useful for devices that
> intended support or require the use of manually entered Link-Local IPv6
> literals would be helpful and warranted.
>
> If you are going to manually enter a Link-Local IPv6 Literal into a
> browser the LLA, it would be very helpful for the LLA to either be known or
> discoverable by non-technical means, like being printed on the device's
> label or made available through a device's user interface, for example,
> printed on a printers test page, displayed on a video screen the device is
> attached to, etc...
>
> A naive device manufacturer, especially for a device with no user
> interface, could be tempted to use an LLA like fe80::1, which would be
> similar to the common IPv4 addresses used to bootstrap devices like
> 192.168.1.1 or 10.0.0.1. However, this is obviously a bad idea, because of
> the high probability of address collision and the trivially easy
> susceptibility to the types of attacks being discussed in this thread, but
> I think this is worth pointing out just how bad of an idea it is.
>
> Nevertheless, temporary or otherwise changing LLAs, perhaps generated on a
> per attachment basis, create a different problem, for devices that have no
> user interface, requiring a technical means to discover the LLA, in order
> to manually enter it. While for highly technical users, this would not be a
> problem. However, if this is intended to be useful to more general users,
> then requiring a technical means to discover the LLA would greatly limit
> the useability of Link-Local IPv6 Literals. While this could be a desirable
> feature, however, in that case, I suspect this entire endeavor is doomed to
> failure, as in order to get browsers to implement this feature it probably
> needs to be of some level of general usability for them to bother to
> implement the feature.
>
> So, from a usability perspective, and even though not recommended in most
> cases, a EUI-64 based LLA could be a good choice for devices with no user
> interface, as many, if not most, devices already have their MAC addresses
> printed on their label for a whole host of other reasons, making the LLA
> easily discovered by non-technical means. However, if a EUI-64 based LLA is
> provided, it probably should be limited to LLA HTTP(S) access and not for
> sourcing more automated Link-Local tasks, such as Neighbor Discovery
> [RFC4861].
>
> That being said, EUI-64 based LLAs are still a bad idea for
> general-purpose devices or any device with even a minimal user interface
> capability, especially mobile devices.
>
> Another option could be a pseudo-random LLA generated at device
> manufacture, and also printed on the label, in addition to the MAC address.
>
> Finally, while most of the above are fairly obvious to members of the 6MAN
> and v6OPS working groups. However, they are probably not obvious to most
> IoT device implementers. Furthermore, helping IoT device implementers make
> good LLA assignment choices should help strengthen the case for browsers to
> support this feature.
>
> Thanks
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>