Thoughts and comments on draft-linkova-6man-grand-01

Mark Smith <markzzzsmith@gmail.com> Sun, 19 January 2020 05:55 UTC

Return-Path: <markzzzsmith@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 B719112004A for <ipv6@ietfa.amsl.com>; Sat, 18 Jan 2020 21:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCKlag_56zqz for <ipv6@ietfa.amsl.com>; Sat, 18 Jan 2020 21:55:35 -0800 (PST)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57A120041 for <ipv6@ietf.org>; Sat, 18 Jan 2020 21:55:34 -0800 (PST)
Received: by mail-ot1-x32f.google.com with SMTP id k14so26040208otn.4 for <ipv6@ietf.org>; Sat, 18 Jan 2020 21:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=b90XKuj4Gz1kfcirFsc4L1OZR1y05qqLEBt4YixR98A=; b=evZFhKjT73uQSoogibPuDB5TpiX1mRnE8iUKwhjy3NqvkGUP1VAezvS1tAW5OXgEzS erBdsypOeII1pdNujrmkLFknuK7/vCylc44BjmeflDiZdj3XLkhMaRJtEx5aOcMPmZIG Os0YWHO3czORcBw1DwtTLs+CIIJilow5Rc/HTgmMqLGBOAqMW6OUm0MwI5C+7VN5diLZ vlheZ1s4KdsqhQ2yaBDDDB0iIaJOBtPttRkWuMxyv309tpU1aoEG9D76zDkpnSbc9r7p dYtckpsVIOtXFEqnsKszQOt01LjaD3Z7SxhnP+SZaaXOD7LqEOMhwl8r6BDwuTE7iq/g m3Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=b90XKuj4Gz1kfcirFsc4L1OZR1y05qqLEBt4YixR98A=; b=CqjBNbdW7C2NjOa2gIcv5NNLvHsig1MICPYIGkgEAUC2x1HR4CkgRswG79gA+2TxzR li2S1msQd3tk46fSgA7JkBZQ6Uf8P3ZvumYroOBstnAwpw7kbEUs0hGH7RPP74hWi3Xy 2psUj9ADM8iXxmfRIKj1AJgn1dsuvxG/Zkp3ZU4OqX2umt+eINRcfTHSe5RmMQd0vNCI l+HVAsd+oSBP3IqSvMo9XRPQsVvyfjwVwp7U51E6X2XgeGHTEmuSHfvc5wDLr87ts7n3 mGw1006aYPAVjEnx7j2J9DIlUsy6Vt1KhSkyGCrXdSKnxs3wlC+AvoNMHtOKsoNCUePq Fq8w==
X-Gm-Message-State: APjAAAXg+WAhvN4a0bqax7/J5PksgyCvR/grJjOr58HWPR2oWe8iDrTM kHKP/nnQPW/CKIC4u8MQIw3iIOYYnx8SSvKXJU0cBA==
X-Google-Smtp-Source: APXvYqwx0hMPPp4y7StCbd4vBMXKTBZxIs/PQSkApXHicAP/pe0snvKx92yMyAgml2rIuqQCkqZ5tgi7f2WCyF1iLgo=
X-Received: by 2002:a9d:65cb:: with SMTP id z11mr11322986oth.348.1579413333315; Sat, 18 Jan 2020 21:55:33 -0800 (PST)
MIME-Version: 1.0
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 19 Jan 2020 16:55:21 +1100
Message-ID: <CAO42Z2xxNrd0kf5ZpFajUHQkKARyGyT3Cork87edN2v_eyyeSw@mail.gmail.com>
Subject: Thoughts and comments on draft-linkova-6man-grand-01
To: Jen Linkova <furry@google.com>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000af94ac059c77d24d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ntjhPYaJsluLdFS1OJ1NUWwj4Vk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 19 Jan 2020 05:55:38 -0000

Hi,

Some thoughts and comments on draft-linkova-6man-grand-01.

Firstly, I think this is a good solution.

I initially was concerned about an increase in multicasts, which I think we
need to remember to try to minimise because of how common Wifi is. However,
I've since realised that these gratuitous unsolicited ND NAs towards
routers are generally replacements for the ND NSes the routers would be
sending, so it probably isn't going to result in an increase in multicasts,
or at least be a significant increase in multicasts. It might be worth
mentioning this in the ID.

It is also probably worth mentioning that if the link layer devices are
performing MLD snooping per RFC4541, then these unsolicited NAs towards the
link's routers will only be sent to the routers on the link rather than
flooded to all nodes due to being sent to the all-routers multicast
address. This is a mitigation to the Security Considerations 3rd paragraph
concern about announcing new host addresses.

As the number of routers on a link is likely and usually small, the node
could perform the multicast packet replication itself for each router and
then link-layer unicast the unsolicited NA to each router, per RFC6086,
"Address Mapping of IPv6 Multicast Packets on Ethernet". I think this
should probably be a recommendation way to send these gratuitous ND NAs, as
it not only avoids link-layer multicasts entirely for these gratuitous NAs,
it also mitigates the security issue described in the Security
Considerations 3rd paragraph regarding hosts announcing their new
addresses. It's a better mitigation than MLD snooping because that's a
capability that needs to be available and switched on, where as link-layer
unicast is of course inherent. (It's not a perfect prevention though
because of the possibility of link-layer Unknown DA frame flooding.)

This mechanism would only be needed if there are routers on the link, so
sending gratuitous unsolicited NAs to all routers could be made dependent
on routers being present on the link. It could and probably should be even
be more narrowly limited to only being used when the host can send traffic
off-link. For example, a host might have received RAs, however if the RAs
Router Lifetimes are Zero (so they're not announcing default routers), and
those RAs don't contain RA Route Information Options for off-link
destinations, then these gratuitous NAs don't need to be sent.

As this is effectively a simple address registration mechanism for hosts to
register their new addresses with routers, it also further assists with
mitigating ND cache exhaustion DoS attacks as described in RFC3756, 4.3.2.,
so it is probably worth mentioning this further mitigation assistance and
referencing that RFC.



"As hosts willing to speed up their network stack
   configuration are most likely to be affected by the problem outlined
   in this document it seems reasonable for such hosts to advertise
   their optimistic GUAs by sending unsolicited NAs."

This problem can of course happen with ULAs too, so it might be better to
just say something more general, such as "their optimistic non-link local
addresses by sending unsolicited NAs."


I was going to do some more thorough reading and comments on the text for
this email however I don't think I'll get to it now before the end of this
weekend, so I'll send this feedback now.

Regards,
Mark.