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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 18 June 2022 22:16 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F00C14CF0A for <ipv6@ietfa.amsl.com>; Sat, 18 Jun 2022 15:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.74
X-Spam-Level:
X-Spam-Status: No, score=-7.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.876, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9WGiy45kzwP for <ipv6@ietfa.amsl.com>; Sat, 18 Jun 2022 15:16:18 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EA9C14F6EB for <ipv6@ietf.org>; Sat, 18 Jun 2022 15:16:18 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id o6so6685636plg.2 for <ipv6@ietf.org>; Sat, 18 Jun 2022 15:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=NvdUAY0pNg4eb+1wXCAZOAh7ZsFWHFEGopa7H7QFL48=; b=LI+/XODrqYdjidbJMc+NU5Lze6xHtga4wMqhRrUkH0HfBY89tbjhpJxWcHef1iu2oT zMvaboIMv3PqMR6prIQqZZI9632PL9q3rdtnh46iQT6V6BruPeMHFwkdejB0tatHJQB9 4AExQzUd+cIIcwQ43jIkQmBo3PAanoJZNM2aomUkQWr60N8vJ1tF4nYOxOFCeRlJ6tCy sDF5PXv7HKCQR97UG1DE8fExYkkM5wuZNU3Birj3hoC5rlWPBJeaUgCqDPlCoF9ab5g/ zxj3A8MfiGXHN8NEcM6xoBJd5QRlMBsKr6o3PJWIXAUzAZHC1712KjWr79MhUdOYHYPv k3XA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=NvdUAY0pNg4eb+1wXCAZOAh7ZsFWHFEGopa7H7QFL48=; b=GBy8DK2Bo/SwJUvwVYcyf19ruqW8zqaKGAKFoURf8xn+yhnxLneMWjHAk6Ede81JiT BMpIQN3HgZWQoURikkK1NpOtTpjM+7SNueHZMmivqk17IeY2fgxvZmAr2eJbI1evEaBv Z1gHHRytpwkKma/KBY16A2RMf2ySnNy4NpbuiS10iPNl8OmV0lOtWpNz7JSS81Oujfb7 ENfCBKklIBhWHib1Sk7A170bUiDHawd0WIwH+EL6x7idslaH7jMnkHStDVnxH+o1izWr 0L878LSHjZHB2JHAzzDGHngrh9XrDHu0mpt6VAS8hKOjlQe7zH2JmD/QN+GM8h3b2EI/ DFoA==
X-Gm-Message-State: AJIora+7T5aVa6fE/EOVFo+g4S1ye9APBpambvaJZBXdz7eymgvAxYNp y+75zJp/4WVocEUOS8YxgfLSIQ/fJakVOzVB
X-Google-Smtp-Source: AGRyM1v5nOWA6eycxejLsh9/4eaFgaKliBtWarCQ4kC75Lg1jh7/KmQQn8qd3STyF8UWfWJH9BZFMg==
X-Received: by 2002:a17:90b:1d83:b0:1e2:f63e:bc37 with SMTP id pf3-20020a17090b1d8300b001e2f63ebc37mr28957394pjb.119.1655590577672; Sat, 18 Jun 2022 15:16:17 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u5-20020a17090add4500b001df264610c4sm14699065pjv.0.2022.06.18.15.16.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Jun 2022 15:16:16 -0700 (PDT)
Message-ID: <f9d62963-3286-3139-8721-b50bb78d12a2@gmail.com>
Date: Sun, 19 Jun 2022 10:16:10 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Subject: Re: WG Last Call for for draft-ietf-6man-rfc6874bis
Content-Language: en-US
To: Ted Lemon <mellon@fugue.com>, David Farmer <farmer@umn.edu>
Cc: 6man <ipv6@ietf.org>
References: <CAFU7BAQVr_UMK_v7O7DGTV363j7q25X9GwrgraTEypzq_Lz3gQ@mail.gmail.com> <CAPt1N1m+g8Yu9rPyvfvrxG_bST_9_z3siByOCsMmeTpWAfAiZA@mail.gmail.com> <223eeed3-40f0-1958-5df4-a6b310a29706@gmail.com> <CAN-Dau14A+GANWRBwHH=+NTkcdaOTfrNN3wcfzo_iiWwo4LzLQ@mail.gmail.com> <CAPt1N1mt=ykhOcb8bXBw4antBBdprhVMNa2iHMBJ3GsR-VX5tg@mail.gmail.com> <CAN-Dau2LaLAu-phD0daBO=+KizdENLka1FTO2Nr-Yr5FHtOnFA@mail.gmail.com> <CAPt1N1kRv-mpkFRXBtbcpexDBQ_wXbvi0iTQFb1dd8vQ33LRCg@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAPt1N1kRv-mpkFRXBtbcpexDBQ_wXbvi0iTQFb1dd8vQ33LRCg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KjPIxFoQ5kyLV6-P1wKZi6K8ayM>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2022 22:16:22 -0000

1) While this is an interesting issue, I'm not convinced by David's suggestion to add it here as an appendix. I fear that it would distract as much as it would help.

2) For older home routers, the installation instructions told me something like "type 10.1.1.1 into your browser" (I'm looking at the instructions for a D-Link purchased in 2007). But my current  home router simply provides "fritz.box" in local DNS. For IPv4, that resolves to 192.168.178.1. But for IPv6, it resolves to a ULA and a GUA with pseudorandom IIDs. Problem solved. (It does have an LLA too, of course, also with a pseudorandom IID.)

This is a case where IPv6 is clearly safer than IPv4. You can find a home router's IPv4 address in public documentation or by a very short search. You can find its IPv6 address by searching a space of size 2^64.

Regards
    Brian

On 19-Jun-22 01:26, Ted Lemon wrote:
> 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 <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 <farmer@umn.edu <mailto:farmer@umn.edu>> 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 <mellon@fugue.com <mailto:mellon@fugue.com>> 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 <farmer@umn.edu <mailto:farmer@umn.edu>> wrote:
> 
> 
> 
>             On Thu, Jun 16, 2022 at 9:55 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> 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:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
>             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: 612-626-0815
>             Minneapolis, MN 55414-3029   Cell: 612-812-9952
>             ===============================================
> 
>     -- 
>     ===============================================
>     David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
>     Networking & Telecommunication Services
>     Office of Information Technology
>     University of Minnesota
>     2218 University Ave SE        Phone: 612-626-0815
>     Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     ===============================================
>