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

[David Farmer <[e-mail]>]

Not mandating anything, suggesting how they will me useful. Your suggesting
a cut and paste, from what? A PCAP,

On Sat, Jun 18, 2022 at 05:20 Ted Lemon <[e-mail]> wrote:

> 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
>> ===============================================
>>
> --
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================