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

[Ted Lemon <[e-mail]>]

Sure, from a packet capture, or if you're trying to reach the router's UI
and DNS-SD isn't working, you might dump the routing table and copy the
address out of the default route. Usually the MAC address is already
printed on the box, so you can take a picture of that with your phone and
cut and paste it into the terminal if you want to grep through the neighbor
table for the corresponding IP address. My point is just that us doing work
to set up circumstances in which there would be a small, typeable IPv6 LLA
is certainly an attractive idea for those of us who are accustomed to
typing http://192.168.1.1 into the address bar, but I don't think we can
replicate that experience for IPv6—there's not enough utility in it to
actually finish writing a document that explains how to do it (e.g., what
if you have /two/ routers?). And if we wrote such a document, it's hard to
see why router vendors would pay any attention to it.


On Sat, Jun 18, 2022 at 7:27 AM David Farmer <[e-mail]> wrote:

> 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
> ===============================================
>