Re: [v6ops] [Iot-directorate] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 18 September 2020 19:20 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085BB3A0C94; Fri, 18 Sep 2020 12:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OFjRjc1iHwqG; Fri, 18 Sep 2020 12:19:58 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065F83A0ABB; Fri, 18 Sep 2020 12:19:54 -0700 (PDT)
Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 7D8C91F45B; Fri, 18 Sep 2020 19:19:53 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 044241A022D; Fri, 18 Sep 2020 15:19:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
cc: Jen Linkova <furry13@gmail.com>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
In-reply-to: <MN2PR11MB3565BF7E140C68AAFFD93849D8210@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB35651BFF4671D89D12E7703DD8270@MN2PR11MB3565.namprd11.prod.outlook.com> <CAFU7BATkRYD6m++gb6_is6oU=PGpQDTx8V2vm0gcJEcAnc1Tgg@mail.gmail.com> <3A6E80C9-07FC-4B4E-9A20-D02C8743448F@cisco.com> <CAFU7BATk7k_6Xfis2yXxjEEx+1N6GaKZg5MZTkPXpLrsdU8mzw@mail.gmail.com> <MN2PR11MB3565BF7E140C68AAFFD93849D8210@MN2PR11MB3565.namprd11.prod.outlook.com>
Comments: In-reply-to "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org> message dated "Wed, 16 Sep 2020 10:13:07 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 18 Sep 2020 15:19:51 -0400
Message-ID: <101699.1600456791@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2l5GcMQpLDnCn2-tDUdOohVRXcs>
Subject: Re: [v6ops] [Iot-directorate] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 19:20:00 -0000

Pascal Thubert \(pthubert\) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
    > Note to your points below (where we lost sync): this must be
    > *completely transparent to the applications*. The idea in 1) would be
    > that something like a tentative state where the address was formed in
    > the stack but not available to the apps. There are a number of reasons
    > for the stack to send a probe like this: prepare the NCE in the router
    > as GRAND does, find a captive portal as my phone and PC do, assess the
    > reachability from a ULA, check the MTU on the last mile...

If there is a captive portal, as indicated by RA and/or DHCP, then
communicating with it will do exactly the desired NCE actions.

My understanding is that iOS will start rotating MAC addresses *even on the
same network* every 12hours.
I have no idea what they will do with their L3 addresses. 
I imagine they get recycled...  but it would be interesting if they were
allowed to be kept for open sockets.

There is an assumption is that WPA-X will need to be invoked at that point,
and that will re-establish the identity of the phone to an upper layer, but
layer-2 snoops will not be able to track beyond that point.

(Maybe they won't bother on unenccrypted wifi, which is often used in
airports/hotels where captive portals are?)

At that point, the NCE will need to be updated again and any captive portal
will either have to be connected to the WPA auth-server (to get the updated
l2 address), or the phone will need to visit the captive portal again.

    > That OS magic is largely OS -specific, unspecified and
    > undocumented. Which means that we cannot validate its value and
    > effects, we cannot count on it, and, as opposed to WiND, we cannot
    > refer to it to explain what it is we dismiss as a possible
    > solution. Since there is no standard, GRAND is bound to explain what it
    > is dismissing so the reader can decide to buy the argument of not.

I understand your point.
It would be good to describe method (1) somewhere, if only because hosts will
continue to have to do this until the other methods are widely supported.

    > Note that in the text above the stack does not need to get the
    > packet(s) back. All it cares is too get an NS from a router in a very
    > short time.

Do you propose that the host is actually looking to receive that NS?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [