Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21

Gert Doering <gert@space.net> Tue, 16 February 2021 14:03 UTC

Return-Path: <gert@space.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCBD3A0CED for <opsec@ietfa.amsl.com>; Tue, 16 Feb 2021 06:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=space.net
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 4urqxzv-bSkA for <opsec@ietfa.amsl.com>; Tue, 16 Feb 2021 06:03:08 -0800 (PST)
Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955773A0CF0 for <opsec@ietf.org>; Tue, 16 Feb 2021 06:03:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1613484187; x=1645020187; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=zrIe+T3xx/TUXwedOyDQ764DrHaf/pL4ECcCM6wsRLg=; b=X5EdyMy+F8bXOn7s0fiOFMnnHkrIYWeNN+Yk8mgQYlYM9g9Ls67K5fZa mxBbReJqN0uKIF62yeKY0O2JC3Lk8cCmOt0NXQ0U8tYXVtMqWf/MMCiMx PU4gO0C32V51TXGd+KmSb2WOX3Ul9D9tKae3Gr5PsqbKi6Z3bNdooXU/7 GdvI4LbTIPJg9ZfqPW81s6b8Um4+y3ECsiw5xkIrgFBn3mL/GWFfyDi+H GFUIHsmgOHSyKvqYiUglkVmxbma1GfxMgT1//HbLor0YqmqQuv3WrsZGv gTLk/C9WlnMOJ/nRkhA61jWF65Z//SkDWAKprAwlw3lyxHhWFRj/Bl5Lt g==;
IronPort-SDR: YmcHbAxB9dS4AbgxBrQkXqXuA601QTrJOof4PP/1wbhWq3cH48/sTXmoKzKYtEDemh3Y5+2sX9 Go7dPQcsBwUhUYeTIzxIoCqhczsA+OcBzUYJ/+pVOIA5luut+XAxpUV2p7LT2ruNtOXjxttpuc kJc4jl7goFCPAt23LqjCwUvdnTBXwD1ygGQ5HVR9/+RpSo6O6Tga/Qw3de83oWzb76jIwJRaqZ VOpj43zMMaDPbOHqFw4fNTtf2st7Zx8WpiNEbkZlV9NHFYOIB4OR1Vj9jtScFKGbbXJrbvCaOR zEE=
X-SpaceNet-SBRS: None
Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2021 15:03:05 +0100
X-Original-To: opsec@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0F0C643B83 for <opsec@ietf.org>; Tue, 16 Feb 2021 15:03:05 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8401A43B80; Tue, 16 Feb 2021 15:03:04 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 82534F7115; Tue, 16 Feb 2021 15:03:04 +0100 (CET)
Date: Tue, 16 Feb 2021 15:03:04 +0100
From: Gert Doering <gert@space.net>
To: Ted Lemon <mellon@fugue.com>
Cc: Gert Doering <gert@space.net>, Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>, =?iso-8859-1?Q?=C9ric?= Vyncke <evyncke@cisco.com>, opsec@ietf.org, Warren Kumari <warren@kumari.net>
Message-ID: <YCvQmJftlWHrkUEx@Space.Net>
References: <YCuf0JXkQLngR2Y1@Space.Net> <923E8868-047C-4FB4-B625-6E74E4262B5B@fugue.com> <YCvKok+GGWE6JuGy@Space.Net> <6D897ABF-B27C-4E82-A1A6-F2AB23FFAA28@fugue.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1nXQYjBayxAeUbl3"
Content-Disposition: inline
In-Reply-To: <6D897ABF-B27C-4E82-A1A6-F2AB23FFAA28@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/SRbWP0yhYmAbo5uA6FWFoYwQnnI>
Subject: Re: [OPSEC] Iotdir early review of draft-ietf-opsec-v6-21
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 14:03:10 -0000

Hi,

On Tue, Feb 16, 2021 at 08:49:58AM -0500, Ted Lemon wrote:
> On Feb 16, 2021, at 8:37 AM, Gert Doering <gert@space.net> wrote:
> > Not sure what of that is "of course" and what "routes to the IoT network"
> > might be???
> 
> Router Advertisements advertise routers, prefixes, and routes, among 
> other things. They can advertise a default router (and hence a default 
> route), or they can advertise a non-default router that provides more 
> specific routes, for example to an IoT stub network. 

You say!  I wouldn't have guessed that.

So, where would that IoT network get their addresses from?

How would the router in my house know that it should listen to this
RA, so other routed segments will be able to reach the IOT segment?
(Routers do usually do not listen to RAs)

How would my machines be able to differenciate between "this is a good
RA" and "everything else that is sending a RA around is not"?


> FWIW, the situation for IoT (stub) networks is no different than
> the situation for multi-homing: you have two routers connected to
> the same link, both multicasting RAs to the link. Which one do you
> want your network infrastructure to automatically filter?

Arguably dual-RA multihoming is not working very well today.  

Like, "not at all".

Because hosts do not send their outgoing packets to the "right" router,
depending on source address, even if they should - and because routers do
not honour RAs, so if the hosts sends a packet to the "wrong" router, 
it will not be forwarded by "router A" to "router B", so it can be sent
to the correct ISP.  Assuming BCP38 filtering on the ISP side, of course.

HNCP had/has the potential to make that work in a very nice way.


Coming back to the original question: I think permitting some random
device to inject RAs into arbitrary networks to connect IoT stub networks
fully conforms to the mantra "the 'S' in IoT stands for 'Security'"...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279