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

Ted Lemon <mellon@fugue.com> Tue, 16 February 2021 14:19 UTC

Return-Path: <mellon@fugue.com>
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 B23073A0D75 for <opsec@ietfa.amsl.com>; Tue, 16 Feb 2021 06:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=fugue-com.20150623.gappssmtp.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 Qle6r7ji6KWh for <opsec@ietfa.amsl.com>; Tue, 16 Feb 2021 06:19:26 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 0D9ED3A0D50 for <opsec@ietf.org>; Tue, 16 Feb 2021 06:19:25 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id t63so9511959qkc.1 for <opsec@ietf.org>; Tue, 16 Feb 2021 06:19:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GlDlad69icTTK3ZsmRgsFfqkAGEWnXsJQfXTbrw7Jsw=; b=z3Z9s2ex+NaKRYJs/FlaKM4mzOPhfsfqegszoxQf3YWrDyNUIqPI6hVjfRaqAuQDOy YlInrAm5XqVaE3gb2eEN9oEWi4KT4WBFfsKWCRcf2t9ptrO9vU4rrjd/KRr2lOJb92x3 /hRcDpi9LPEyv1cLtdaYas+G6FGOksllmsl8h6YGuonLgT2qi1ct4qvAaA00Z9HQLUAq uk6U/IOB3uWBvWbqdMki1OFq4R80mPj4pCLn4/ZEoBJwrjtmMYXwwJlbxaJgCSXeOp5r px9iX1QneXgNjjf8Qd1pDm2dkMQ+LCWnnP/Lv7wwd9Fhqd3ypg2kF5Wlph2epl5MSoh3 rCZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GlDlad69icTTK3ZsmRgsFfqkAGEWnXsJQfXTbrw7Jsw=; b=XfOcUWPm1cO8bsGV60s9Y1QrQSddKHqkyZ4Qd24D5e00UnaQkRY+d0a/aXVJKtEnxr A/HbmO1iNsVOwJAoHzBKGJYDU9sOdNUyYZXcEVjIoPDOIA17zZTKkA6KbX8vGrXBjOtC onk1HMibWZSUCQwuMmirtEVJqaaaHbdZeOgEBCe2FeXxXUaBJA9s5zjaLcwe/GNuHA4i b2pc549Pb8P2+eZr5WP/8TVDPvfWFaIlnslttrlGaQiU1xsiwFRGlNVieleqVjWKH5W5 Z7BY4a3rkUHnpkYdzHxNFQpSig+iN/cIiScgpsT3LRNcES8LUu9RUabA0jVQz2eRBE/c OYdQ==
X-Gm-Message-State: AOAM533Fakowv2rRMTfJNDV0ObN7+y6uIU+CiK2SE22QYeamV4YB5Smi 2UH3RrF6Rrnz0BTaHiyWc1lyNr+bRNwzpw==
X-Google-Smtp-Source: ABdhPJxpFwJbOidti+GSP+z8OpBBXonXZKCZ4meRtzw66FF+qrF0fF7yapaMVGHQNtKGBGUVPoET0w==
X-Received: by 2002:a37:5841:: with SMTP id m62mr8650649qkb.452.1613485164965; Tue, 16 Feb 2021 06:19:24 -0800 (PST)
Received: from smtpclient.apple (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id r25sm11638711qtt.89.2021.02.16.06.19.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Feb 2021 06:19:24 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <8F6D4189-A7DB-4154-B4C4-13839C2988CB@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D394AB23-CD7D-4403-A80B-5BD90B675734"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.32\))
Date: Tue, 16 Feb 2021 09:19:23 -0500
In-Reply-To: <YCvQmJftlWHrkUEx@Space.Net>
Cc: Stuart Cheshire <cheshire=40apple.com@dmarc.ietf.org>, =?utf-8?Q?=C3=89ric_Vyncke?= <evyncke@cisco.com>, opsec@ietf.org, Warren Kumari <warren@kumari.net>
To: Gert Doering <gert@space.net>
References: <YCuf0JXkQLngR2Y1@Space.Net> <923E8868-047C-4FB4-B625-6E74E4262B5B@fugue.com> <YCvKok+GGWE6JuGy@Space.Net> <6D897ABF-B27C-4E82-A1A6-F2AB23FFAA28@fugue.com> <YCvQmJftlWHrkUEx@Space.Net>
X-Mailer: Apple Mail (2.3654.80.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/zYWv0Wl8QYr4bdfI4jcK1xhAKEk>
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:19:30 -0000

On Feb 16, 2021, at 9:03 AM, Gert Doering <gert@space.net> wrote:
> So, where would that IoT network get their addresses from?

To reach out to the cloud, it can use NAT64. To reach in, it needs IPv6, because there is no practical way to do NAT64 in the other direction. So the IoT router advertises an on-link autoconf prefix on the infrastructure link if there is no prefix on the link, and it advertises a non-default route to the prefix it’s advertising on the IoT network. Both prefixes are ULA prefixes, so it gets them by making them up with a random number generator. :)

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

If you have a multi-subnet home network, you will get the same behavior you get now for IoT devices connected to different links: they won’t be useable other than on the link to which they are attached. In the case of an IoT stub network, you will be able to use devices on the stub network on the link to which it is attached. If you want more than that, you can set up prefix delegation. In principle the stub router could do HNCP where it’s available, but since that’s nowhere, and since HNCP doesn’t solve the naming problem, there’s not much point.

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

Actually that would be Babel. HNCP doesn’t solve this problem.

> 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’"


What distinguishes a “random device” from a “not random device”? That’s the problem. If you are really concerned, you could have your “not a random device" filter out default RAs, but that would still cause operational problems—just fewer of them.

And BTW HNCP is no more secure than RA. And on an HNCP network RAs are vital for informing hosts of which router to communicate with, because default routes won’t work in a self-configuring mesh topology.

You might want to read the document I pointed you to.