From nobody Wed Dec 2 13:18:22 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE74E3A1802; Wed, 2 Dec 2020 13:18:13 -0800 (PST) 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 2_y1-iqsGSDX; Wed, 2 Dec 2020 13:18:11 -0800 (PST) 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 CD5FF3A1913; Wed, 2 Dec 2020 13:16:46 -0800 (PST) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 295971F45D; Wed, 2 Dec 2020 21:16:45 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 232081A02BA; Wed, 2 Dec 2020 16:16:00 -0500 (EST) Received: from dooku (localhost [127.0.0.1]) by dooku.sandelman.ca (Postfix) with ESMTP id 202CB1A026C; Wed, 2 Dec 2020 16:16:00 -0500 (EST) From: Michael Richardson To: Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Fri, 10 Jul 2020 02:25:25 -0400." 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: Wed, 02 Dec 2020 16:16:00 -0500 Message-ID: <689918.1606943760@dooku> Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:18:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (trying to clean out my inbox) Ted Lemon wrote: > I mentioned prior to IETF 107 that I wanted to start a conversation > about this problem, but didn=E2=80=99t have time to write a draft. I= =E2=80=99ve > written one, which I think describes my view of the problem pretty > well; I=E2=80=99d like to know if what I=E2=80=99ve written here make= s sense to others. Ted, I think that your work addresses a problem space that is in some ways similar to the "share64" concept. Not the same, but similar. I think that the use of ULA which is advertise to the "LAN" for reachability does not have to be mutually exclusive with NAT64 for "cloud" reachability. Since your document does not actually require any new protocol, but just explains how to do something new using existing mechanism, I think that it would fit into the current IOTOPS charter. In answer to your question: State of the Art Currently there is one known way to accomplish what we are describing here [[Michael, does ANIMA have a second way?]].=20 The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC6550) storing mode. > https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.= txt =20=20=20=20 > Abstract: IETF currently provides protocols for automatically > connecting single hosts to existing network infrastructure. This > document describes a related problem: the problem of connecting a stub > network (a collection of hosts behind a router) automatically to > existing network infrastructure in the same manner. Your criticism if HNCP is all true, but an important part is that it really only provides for allocation of prefixes; not routing. (I still think that the WG made a mistake not extending OSPFv3) HNCP is not the part that's missing: it's the routing protocol in the home that is what's needed to do something more complicated. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl/IAwYACgkQlUzhVv38 QpAkYwgAjNIRi6vX5UBoHnGmDFuTGgVJpY3AJylZbrqC6QZAnnFpBis8NWDIUihc qjrhNd8PaAWY+cPQNft8O757Pbh90cax1nx0D51gmtmSW446c7WNoumoawbYgw1f T/ZMwb/v3Nr190OmEUPiIHF+sYaaST4wy4GDrAu49JjlkKJjVdGvyWYG/R4f205P kRif1geXetZqPQD8pruWGcaSMOWexg9HR+rJ0vMAP1i2m7zKm0DWPPwOh56rn1Gg 680Om1YvuGmEiKDZKmBWY06FMQYLz7qC3l0JnzZ5S+W0UDt4/+SI0RhFkXtlqN58 cQW3OeJQMvKsSRhYn180FA1WxJ9kzQ== =nqlv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 2 15:24:13 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58123A15D3 for ; Wed, 2 Dec 2020 15:24:07 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 UdmVAHjdlajg for ; Wed, 2 Dec 2020 15:24:05 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 157EC3A15E0 for ; Wed, 2 Dec 2020 15:24:04 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id ek7so102776qvb.6 for ; Wed, 02 Dec 2020 15:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=i+VojTx+Su0FhCmNt+OckTXVWYHrK29+lbZ7m1IdqO4=; b=cFL6Ccm3C56tHUErq5om8ROjSLtW5+o41LTN1VQZD+iruE/QKBAz82idO0FYb05Y7C Kf/Yx1p6+uD62JeFFSsHhzECFxPIwHdP6j39iGV0KlJbQ8tiJeKZ1XSJJWVncDnf9jOp NguAtwRhWD9MtBaC4JZ+FzAUE+7Lt49Lnt9A9SXIctE3g+JKbavZ3+72BxXUjOl5j0Dc yqGrE48Xwo4AYdAq3Tgq2EMR2ubcyx0MFxHMNEd8sLvXzj1UPFTu15fhfHyCqLD1CZjP md/UopPNmmNcL2D1+3ded2ka3SLzb1tPzJZXRsyspiGdW8ttdqvfZkLXLyNpMDjOf5OQ D/tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=i+VojTx+Su0FhCmNt+OckTXVWYHrK29+lbZ7m1IdqO4=; b=XpfCmeRZTS7TOJOuC1r0S3hLTzGnlfSodmhHO5lA5N6n+xrgC2MRi10uI7SOE8oVfG LjzuGSKNVXvBTpZr0mifu8hT0TvQgO+isbU7bNTvl2v8HxLX5kWSBMMVm37GKZILHRCK 6+SJQitGfy7Gn1KY4bJDLlybLuADcdXROfv4+imvQqpBxIhX8Za94vX/vuUP68kMT3BU FM7SuH5QBqRycF7+4gC+2sRIHrvTo5uWVhzaT7wncD3afdfu9+Jl+WutoNdbivT4DEgE j4uVzgvJSXaHnFCbYpr/NiOC/nqz2FA4cJyjVhtgckzqahvadcGKuBw+4ahgfx81Bcb/ 1W0A== X-Gm-Message-State: AOAM530zh/FSqyoDy/rRKhDmN+SBWFwg7Dz5qBjIUgiRo7lP7pcsrzdZ UmbbyUgqwaJ2v6ndXQ5sw2P/9w== X-Google-Smtp-Source: ABdhPJyWYQyBe1pgwXfhibGlIVWe0cYzTCrM7AnaS7fEIvW37rfyrK7k+4jfmmfFX3EAaJT9ierxCg== X-Received: by 2002:a05:6214:493:: with SMTP id ay19mr379819qvb.36.1606951443797; Wed, 02 Dec 2020 15:24:03 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z186sm153832qke.100.2020.12.02.15.24.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:24:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 2 Dec 2020 18:24:01 -0500 Message-Id: References: <689918.1606943760@dooku> Cc: 6MAN <6man@ietf.org>, iotops@ietf.org In-Reply-To: <689918.1606943760@dooku> To: Michael Richardson X-Mailer: iPhone Mail (18C62) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 23:24:08 -0000 On Dec 2, 2020, at 16:16, Michael Richardson wrote: > (trying to clean out my inbox) >=20 > Ted Lemon wrote: >> I mentioned prior to IETF 107 that I wanted to start a conversation >> about this problem, but didn=E2=80=99t have time to write a draft. I=E2=80= =99ve >> written one, which I think describes my view of the problem pretty >> well; I=E2=80=99d like to know if what I=E2=80=99ve written here makes se= nse to others. >=20 > Ted, I think that your work addresses a problem space that is in some ways= > similar to the "share64" concept. Not the same, but similar. Yes. But I think share64 on a WiFi network would require proxy ND, which doe= sn=E2=80=99t scale well, particularly if you have multiple unmanaged routers= providing readability and transit.=20 > I think that the use of ULA which is advertise to the "LAN" for reachabili= ty > does not have to be mutually exclusive with NAT64 for "cloud" reachability= . Absolutely. That=E2=80=99s what we=E2=80=99re thinking for the ipv4 and dual= stack cases. Doesn=E2=80=99t work for v6-only.=20 > Since your document does not actually require any new protocol, but just > explains how to do something new using existing mechanism, I think that it= > would fit into the current IOTOPS charter. I don=E2=80=99t think this is IoT-specific. I would prefer to do the work in= intarea.=20 > In answer to your question: > State of the Art >=20 > Currently there is one known way to accomplish what we are describing > here [[Michael, does ANIMA have a second way?]].=20 >=20 > The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC6550= ) > storing mode. I don=E2=80=99t get a mental picture from this of how it helps.=20 FWIW, Apple is now shipping a product (HomePod Mini) that does stub network r= outing for thread networks, and there=E2=80=99s also an open source implemen= tation. Right now it only does the ULA solution. I=E2=80=99ll be writing a d= raft that describes this soon.=20 Thanks for the review and comments! >=20 >> https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt >=20 >> Abstract: IETF currently provides protocols for automatically >> connecting single hosts to existing network infrastructure. This >> document describes a related problem: the problem of connecting a stub >> network (a collection of hosts behind a router) automatically to >> existing network infrastructure in the same manner. >=20 > Your criticism if HNCP is all true, but an important part is that it reall= y > only provides for allocation of prefixes; not routing. > (I still think that the WG made a mistake not extending OSPFv3) > HNCP is not the part that's missing: it's the routing protocol in the home= > that is what's needed to do something more complicated. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh networ= ks [=20 > ] Michael Richardson, Sandelman Software Works | network architec= t [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 > =20 >=20 >=20 From nobody Wed Dec 2 15:42:45 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAE43A04BC; Wed, 2 Dec 2020 15:42:39 -0800 (PST) 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 u2z2w-JIbN_r; Wed, 2 Dec 2020 15:42:37 -0800 (PST) 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 6583A3A046A; Wed, 2 Dec 2020 15:42:35 -0800 (PST) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 528691F45D; Wed, 2 Dec 2020 23:42:34 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id BF5AE1A02BA; Wed, 2 Dec 2020 18:42:32 -0500 (EST) Received: from dooku (localhost [127.0.0.1]) by dooku.sandelman.ca (Postfix) with ESMTP id BDF1D1A026C; Wed, 2 Dec 2020 18:42:32 -0500 (EST) From: Michael Richardson To: Ted Lemon Reply-To: iotops@ietf.org cc: 6MAN <6man@ietf.org>, iotops@ietf.org In-reply-to: References: <689918.1606943760@dooku> Comments: In-reply-to Ted Lemon message dated "Wed, 02 Dec 2020 18:24:01 -0500." 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: Wed, 02 Dec 2020 18:42:32 -0500 Message-ID: <695953.1606952552@dooku> Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 23:42:39 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > On Dec 2, 2020, at 16:16, Michael Richardson > wrote: >> (trying to clean out my inbox) >>=20 >> Ted Lemon wrote: >>> I mentioned prior to IETF 107 that I wanted to start a conversation >>> about this problem, but didn=E2=80=99t have time to write a draft. = I=E2=80=99ve >>> written one, which I think describes my view of the problem pretty >>> well; I=E2=80=99d like to know if what I=E2=80=99ve written here ma= kes sense to >>> others. >>=20 >> Ted, I think that your work addresses a problem space that is in some >> ways similar to the "share64" concept. Not the same, but similar. > Yes. But I think share64 on a WiFi network would require proxy ND, > which doesn=E2=80=99t scale well, particularly if you have multiple u= nmanaged > routers providing readability and transit. I wasn't saying that the same solution applies, but rather the problem space is the same. Device-X has some IPv6 on a network "behind" it, and wants to share addresses on a wifi/LAN in front of it in order to enable connectivit= y. I'm unclear from reading your document if the RA's would have L=3D0 or L=3D= 1. >> I think that the use of ULA which is advertise to the "LAN" for >> reachability does not have to be mutually exclusive with NAT64 for >> "cloud" reachability. > Absolutely. That=E2=80=99s what we=E2=80=99re thinking for the ipv4 a= nd dual stack > cases. Doesn=E2=80=99t work for v6-only. So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I think it's a fail for cloud connectivity. In particular, in this case, it= 's hard to report the failure to anyone offsite! It might be worth describing how this failure case could be reported intell= igently. This is an operational kind of thing which is in charter for IOTOPS. >> Since your document does not actually require any new protocol, but >> just explains how to do something new using existing mechanism, I >> think that it would fit into the current IOTOPS charter. > I don=E2=80=99t think this is IoT-specific. I would prefer to do the = work in > intarea. I don't think something needs to be IoT-only to belong in IOTOPS. >> In answer to your question: State of the Art >>=20 >> Currently there is one known way to accomplish what we are describing >> here [[Michael, does ANIMA have a second way?]]. >>=20 >> The ANIMA ACP sets up an overlay network with /128 routing via >> RPL(RFC6550) storing mode. > I don=E2=80=99t get a mental picture from this of how it helps. I'm sorry, I didn't finish the thought. "It does not help at all" > FWIW, Apple is now shipping a product (HomePod Mini) that does stub > network routing for thread networks, and there=E2=80=99s also an open= source > implementation. Right now it only does the ULA solution. I=E2=80=99ll= be > writing a draft that describes this soon. I'm unclear what "this" is. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl/IJmgACgkQlUzhVv38 QpABgwf+KvLG9UyvXgKS4ujhODI72myJufhbSD5AKwJtRrrnQ230BUxVtUtFmzxf 1TdFut0wL80jF67FMLi/u88gHtkxyogU9A8cKLMxCAbDMWS5yaAbeIEezKhB+eoJ 34vxkwxmBQ5K3WNQOGRfcg2SAc8xbvK4aoByD2Zbsh6D0O2imLAD9MVXjDTVQ1bO QvnEFIidU6rzhuDUQuGdES72zf4s/pC39v4A+5vgX9xPI0hh+k3q/sHzZUE+Ro6/ nZiq3y8qWSf6RjSJlYHLfwrVZQNxSyPCT/9zhAR2SoCxTHtuu8KCbsWy110226qr 0XWpE2lHtFFci5nMS7iCaCUKQOTbmw== =92l5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 2 15:47:48 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05C63A0AB1 for ; Wed, 2 Dec 2020 15:47:43 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0i9-N2PCDBQP for ; Wed, 2 Dec 2020 15:47:41 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 6DF1F3A0AB5 for ; Wed, 2 Dec 2020 15:47:41 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id 62so113340qva.11 for ; Wed, 02 Dec 2020 15:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AY6sdN2A9hmCopdDnf/my9estnpsksdYOcjq+Qn9ICs=; b=q1XRd9Fbm8U4k/rZDx1Yw22zP1GJPaICwQsOGNT+rq2a/Ar+JtukvVL81PY6seZfKa QQjd5gIbpTcU2ltajdxuimKUc2Hd7an5UJpww9iaXkuHIyeYP0DN4Xw3yWotqp0ZAgbV yKqvynpO59T4w1j8xmbBWgyjurk/yJEHVhvIRFsX6JtzC4hlKuxyFScV3PqFHzSAIDLs LJCAjrWwWQ2CZUBEXoe6XDSfO0dsX6qggL/Bf1XvrIOfinDHC4pHNyRy2tAUFrYXyDoP OxV4Zrd5IAtrSzTLz4yqT5x8Ig0LzRa2mrepkxkdpyo2vBvqWxzO2nuGx/CpWt8LNua3 Rdfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AY6sdN2A9hmCopdDnf/my9estnpsksdYOcjq+Qn9ICs=; b=QjFfoFwUgnvrrvIGPw2fq4onc/8lXOIMJvYM+g+NrlYUVo916lDZpaRIxqBjJvEjC5 v4gcyoDZdqCjGu+5ZO2XYvXfda3RasDwYmr6Qumgu2dmfS+VQQtEoijRGJoacx+eKjsW PVtOlZDl1IIjFxEpQ6KuY6Tm9COBeG7IU8QU9bsFw+BKpDUvE7AuJW0nf+9OPjMBu8k6 Vf7MclHb+T7xi0FCtZeQJ1apwf970kjj6iHqFn1hQNl99MQmdYxEdqLeZni9Savg61XB PKsla8/Y7MCUty5x0ZZCVYtfLPjYzyuwBrRn04av1EokjTH2WVIx6I9AVm1v9fRrbdGD WKgQ== X-Gm-Message-State: AOAM5335Kfz92B37ZwZQpqgLuvbrGTaRpvyUcQGsVt4FvK0EW5SRGbRD gH5YUJ9dUTgR06GNYe18yvsZDu6crwVPYHST X-Google-Smtp-Source: ABdhPJzIKWlgfhZpiWFYC5MRLuO/B8Jprb6bZteK0k+gx4KsUE7XntnYQRiBS5lME7zmkrEYa6orDw== X-Received: by 2002:ad4:524d:: with SMTP id s13mr371558qvq.19.1606952859896; Wed, 02 Dec 2020 15:47:39 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id e3sm494489qts.8.2020.12.02.15.47.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 15:47:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 2 Dec 2020 18:47:38 -0500 Message-Id: References: <695953.1606952552@dooku> Cc: 6MAN <6man@ietf.org> In-Reply-To: <695953.1606952552@dooku> To: iotops@ietf.org X-Mailer: iPhone Mail (18C62) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 23:47:44 -0000 =E2=80=9CThis=E2=80=9D is what we did in the Apple thread border router. I=E2= =80=99m nervous about anything in the IETF with IoT in the title because it w= ill be subject to the Carsten Bormann DoS attack.=20 I don=E2=80=99t know if we have visibility into the right part of Google to g= et the chrome problem fixed. Their IoT team is fairly far removed from their= browser team. What=E2=80=99s the use case? > On Dec 2, 2020, at 18:42, Michael Richardson wrote= : >=20 > =EF=BB=BF > Ted Lemon wrote: >>> On Dec 2, 2020, at 16:16, Michael Richardson >>> wrote: >>> (trying to clean out my inbox) >>>=20 >>> Ted Lemon wrote: >>>> I mentioned prior to IETF 107 that I wanted to start a conversation >>>> about this problem, but didn=E2=80=99t have time to write a draft. I=E2= =80=99ve >>>> written one, which I think describes my view of the problem pretty >>>> well; I=E2=80=99d like to know if what I=E2=80=99ve written here makes s= ense to >>>> others. >>>=20 >>> Ted, I think that your work addresses a problem space that is in some >>> ways similar to the "share64" concept. Not the same, but similar. >=20 >> Yes. But I think share64 on a WiFi network would require proxy ND, >> which doesn=E2=80=99t scale well, particularly if you have multiple unman= aged >> routers providing readability and transit. >=20 > I wasn't saying that the same solution applies, but rather the problem spa= ce > is the same. Device-X has some IPv6 on a network "behind" it, and wants t= o > share addresses on a wifi/LAN in front of it in order to enable connectivi= ty. >=20 > I'm unclear from reading your document if the RA's would have L=3D0 or L=3D= 1. >=20 >>> I think that the use of ULA which is advertise to the "LAN" for >>> reachability does not have to be mutually exclusive with NAT64 for >>> "cloud" reachability. >=20 >> Absolutely. That=E2=80=99s what we=E2=80=99re thinking for the ipv4 and d= ual stack >> cases. Doesn=E2=80=99t work for v6-only. >=20 > So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I= > think it's a fail for cloud connectivity. In particular, in this case, i= t's > hard to report the failure to anyone offsite! >=20 > It might be worth describing how this failure case could be reported intel= ligently. > This is an operational kind of thing which is in charter for IOTOPS. >=20 >>> Since your document does not actually require any new protocol, but >>> just explains how to do something new using existing mechanism, I >>> think that it would fit into the current IOTOPS charter. >=20 >> I don=E2=80=99t think this is IoT-specific. I would prefer to do the work= in >> intarea. >=20 > I don't think something needs to be IoT-only to belong in IOTOPS. >=20 >>> In answer to your question: State of the Art >>>=20 >>> Currently there is one known way to accomplish what we are describing >>> here [[Michael, does ANIMA have a second way?]]. >>>=20 >>> The ANIMA ACP sets up an overlay network with /128 routing via >>> RPL(RFC6550) storing mode. >=20 >> I don=E2=80=99t get a mental picture from this of how it helps. >=20 > I'm sorry, I didn't finish the thought. "It does not help at all" >=20 >> FWIW, Apple is now shipping a product (HomePod Mini) that does stub >> network routing for thread networks, and there=E2=80=99s also an open sou= rce >> implementation. Right now it only does the ULA solution. I=E2=80=99ll be >> writing a draft that describes this soon. >=20 > I'm unclear what "this" is. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh networ= ks [=20 > ] Michael Richardson, Sandelman Software Works | network architec= t [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 > =20 From nobody Wed Dec 2 16:14:32 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738F23A163D for ; Wed, 2 Dec 2020 16:14:26 -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, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 muXjEEcvY2JY for ; Wed, 2 Dec 2020 16:14:25 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 1CC5A3A1643 for ; Wed, 2 Dec 2020 16:14:24 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id g19so164005qvy.2 for ; Wed, 02 Dec 2020 16:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=AXUckOe/KZmG5Dt8UC6jBLR2nfV6sQVPxn2K9rywpNs=; b=bUi0+5cbbaj8sMktVyrrA4pBYGzCvRR9UyBI5b72cH9IsH/F+/JJzG2CU9CS8iIacX LOnhN2qA1qdCscM/ivqD3/ndsrAoSsOhR3j2oPF7vDfU9ii6qVEXcsWbC39JIM/XO5g4 PlrshOjXWZsHvrSjjkgkPNgYLtbuyY8Bg4rVfcT/fovxWmLUonbXLrSJAkVGZC9dsm2z iufKQF0NNx+3ZgJ9QzA5y4YJgCg1sPDcAeb4v4/coz3i0dqxAemXx+96/xGnGTgxN/zX jdAb2uQYR2ZPIFmkW8SoPRF+bIRuzpXRV5DCdDD/JYtDfI3U80UG1e8KfXi6YNjhPmLP VpGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=AXUckOe/KZmG5Dt8UC6jBLR2nfV6sQVPxn2K9rywpNs=; b=I+ZQ0asNiqundUdDDWFTwMb/53gGN03t22+EfT8VOPyH59wQcjCH4rx9tvYHxCaMBA St9r4Ddk/W0F5EmYG/MmMhi+mvNsJfPycFKhsjWHmDDX9VzGwol5l1a/tNtJJAkvPk+G Smmm0WbQbAk/pnGSsF4UIE0Nywaf2sSq/p5Ge2Nxo0LepTiUiDNAUtJlmgJ3sIbFQcYx OWB5uWvC8orDEk5hElaMt6h9cT0qLvwMIf0lTSBGAr3d8H5t/e4WI4q99raxSPP/06fL E5O4V7eKI/lMJ0uiEDvr4mMBAchfcUeFJOPfdGDLtrwP0H0oY+NEJ/rz9UtpNnpOsFzx lcmA== X-Gm-Message-State: AOAM533JKYgudXWt87hLTMX0cip3G4NyZ6T3a6TmK8mUtL10m110gXEg M7ATAX8iL9uMVfnJKrChdcZkWxOJauYFT1kb X-Google-Smtp-Source: ABdhPJwg6htjGEPTpWYUE+9hxX3xpDrMzSUHXSxAMoIhKtsoMO/xNNPtCD1WYVnxjeAm20m6YuZNhQ== X-Received: by 2002:a0c:cb8f:: with SMTP id p15mr551611qvk.43.1606954463567; Wed, 02 Dec 2020 16:14:23 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id q123sm315989qke.28.2020.12.02.16.14.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 16:14:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 2 Dec 2020 19:14:21 -0500 Message-Id: References: Cc: 6MAN <6man@ietf.org> In-Reply-To: To: iotops@ietf.org X-Mailer: iPhone Mail (18C62) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:14:27 -0000 On Dec 2, 2020, at 18:47, Ted Lemon wrote: > the Carsten Bormann DoS attack BTW, I=E2=80=99m sorry for having ascribed this to Carsten. What I=E2=80=99m= taking any is the tradition in some IoT working groups of having biweekly I= nterims. It=E2=80=99s a great idea on theory, but generally means I can=E2=80= =99t participate in that WG because the time hit is too much.=20= From nobody Wed Dec 2 16:23:04 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022403A0115 for ; Wed, 2 Dec 2020 16:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 5xTXEiLRLePb for ; Wed, 2 Dec 2020 16:22:53 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D17003A005C for ; Wed, 2 Dec 2020 16:22:52 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id h20so615938qkk.4 for ; Wed, 02 Dec 2020 16:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=9/p5DbQDJYIEL7I+o2MkNfp3QQv21aVG2f/8FkYsRh4=; b=OtXm0J6iiIA6rmBpuxM49LNki5X5185vNFw7mzRtr1oS2Bdx7SH1B9I6iUOHqQHKJp 43t1IS7plV/N/7YZT4r1GNtWupMPhDWLDVQ22LOes/w4fDoPiNZq6EruZ40ufmHvjMJq 9RhjEpaVyRIhGdlRiV5j/VDGdJtTxwhQI4w5akUTXDIzwU7oTf8p7rnhAZyEfFlbX81M QfV7HEKk3n5XDDpqmwMzQlIC9FoFnhDgMFaMMwpjsaUQnFPvSotto6CLWjsb0EDjCTx6 uftlFTvC2Q7iFMOwcNpPJRqE3JKL1wRpOy8WK0aUFW+GJ0dRrb7NKjCQ5Y0WnU3f70XV jwYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=9/p5DbQDJYIEL7I+o2MkNfp3QQv21aVG2f/8FkYsRh4=; b=uHHPcsY54qzF00Rw4u5pChxVgJRMeblC51yfkbhgDMEYReUzQZ9JFIydcXlEUr7sVB ro5XYEMXBkIaAE5nD5n7tyRaTOL+5UqK1Wx+hN/METOoVRebjf7EJIgG0wdkmSGnOGQI MHjrcMUeWvxQPeSXTZz1SCTJoVI8ULvUiPVqIWfIS/m66a9Szr031+dQf1TtAji9TsgG XYlsOe/c4rPd8y8m9qhTShQsOkKLN0dUMwIN9oosJaOqYb1tAxXZxJkHzfSso2flctj0 YFWPJL+dIsKa3aX5MnXY7usnpWnHpQkSWBYr0agM008UsBci4c61RzH3bI9d0y2Kbgf9 cnTw== X-Gm-Message-State: AOAM53035nCTJLVhPYUBIZ7+LjQsxIce4qiM55e05ugzyrxYNpqv98P2 aL1Wlw/iISsRCh+zCYxk+zwxSEHOKSFgxyrd X-Google-Smtp-Source: ABdhPJyVj9bv5r9DfbjBptm5aoVFKgal4YZiR5icSC8Wakma2i8IEhmFtoCkpBGzRtEo9MhzaY2dOg== X-Received: by 2002:a05:620a:20c9:: with SMTP id f9mr452289qka.378.1606954971557; Wed, 02 Dec 2020 16:22:51 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z51sm727436qth.7.2020.12.02.16.22.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Dec 2020 16:22:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Wed, 2 Dec 2020 19:22:50 -0500 Message-Id: References: Cc: 6MAN <6man@ietf.org> In-Reply-To: To: iotops@ietf.org X-Mailer: iPhone Mail (18C62) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:23:04 -0000 On Dec 2, 2020, at 19:14, Ted Lemon wrote: > What I=E2=80=99m taking any Talking about. Sigh.=20= From nobody Thu Dec 3 04:48:59 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF03A08DA; Thu, 3 Dec 2020 04:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1Emycy77v_bg; Thu, 3 Dec 2020 04:48:56 -0800 (PST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1903A08C5; Thu, 3 Dec 2020 04:48:08 -0800 (PST) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CmwYK3BVJz67LP2; Thu, 3 Dec 2020 20:45:41 +0800 (CST) Received: from fraeml704-chm.china.huawei.com (10.206.15.53) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Thu, 3 Dec 2020 13:48:04 +0100 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Thu, 3 Dec 2020 13:48:04 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.161]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0487.000; Thu, 3 Dec 2020 20:48:00 +0800 From: Qin Wu To: "iotops@ietf.org" , Ted Lemon CC: 6MAN <6man@ietf.org> Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AdbJcmHVuL+YIanTQYOZyQxG9/eyaw== Date: Thu, 3 Dec 2020 12:47:59 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.101.103] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 12:48:58 -0000 ICAgID4+IEluIGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uOiBTdGF0ZSBvZiB0aGUgQXJ0DQogICAg Pj4gDQogICAgPj4gQ3VycmVudGx5IHRoZXJlIGlzIG9uZSBrbm93biB3YXkgdG8gYWNjb21wbGlz aCB3aGF0IHdlIGFyZSBkZXNjcmliaW5nDQogICAgPj4gaGVyZSBbW01pY2hhZWwsIGRvZXMgQU5J TUEgaGF2ZSBhIHNlY29uZCB3YXk/XV0uDQogICAgPj4gDQogICAgPj4gVGhlIEFOSU1BIEFDUCBz ZXRzIHVwIGFuIG92ZXJsYXkgbmV0d29yayB3aXRoIC8xMjggcm91dGluZyB2aWENCiAgICA+PiBS UEwoUkZDNjU1MCkgc3RvcmluZyBtb2RlLg0KSSBhbSB3b25kZXJpbmcgaG93IEFDUCtSUEwgaXMg ZGlmZmVyZW50IGZyb20gSE5DUCtCYWJlbD8gQXJlIHRoZXkgZXF1aXZhbGVudD8NCg== From nobody Thu Dec 3 05:55:56 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7598A3A0B5D; Thu, 3 Dec 2020 05:55:55 -0800 (PST) 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 SxnmYw4UudnK; Thu, 3 Dec 2020 05:55:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1522C3A0B5C; Thu, 3 Dec 2020 05:55:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F3C32389D4; Thu, 3 Dec 2020 08:57:43 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sHX_yPVR26O8; Thu, 3 Dec 2020 08:57:43 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7751D389CE; Thu, 3 Dec 2020 08:57:43 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3973E1FB; Thu, 3 Dec 2020 08:55:51 -0500 (EST) From: Michael Richardson To: Qin Wu , "iotops\@ietf.org" , Ted Lemon , 6MAN <6man@ietf.org> In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 13:55:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Qin Wu wrote: >>> In answer to your question: State of the Art >>> >>> Currently there is one known way to accomplish what we are describi= ng >>> here [[Michael, does ANIMA have a second way?]]. >>> >>> The ANIMA ACP sets up an overlay network with /128 routing via >>> RPL(RFC6550) storing mode. > I am wondering how ACP+RPL is different from HNCP+Babel? Are they equ= ivalent? They are not equivalent. They do different things. They could be used at the same time. Both can benefit from BRSKI for enrollment of new devices, but both could do enrollment via another method. There are similiarities in how some things work. For instance, both use multicast, and both use IPv6. Both contain mechanisms to do prefix assignment at different layers. [ACP/RPL assigns /128s to nodes. An ANIMA ASA can use the ACP to do prefix delegation. The HNCP is used for prefix delegation directly] (They also both use network byte order... so) The ACP is an overlay network of point-to-point tunnels that tries hard to = be resilient, and does not *optimize* for shortest path. HNCP is a consensus protocol which is used to for many things, including prefix assignment, and the uses Babel to announce them. It is not an overlay. It does find the shortest path. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/I7mYACgkQgItw+93Q 3WV5IwgAp+C5KH2iUjw1GlwSedpAsQUu05Fd3qf4HJR2khmIVIOfUxSEmGWDBA5A CGulRLllkGM5n+NAH3H5XWyzudw9zrApIS63Lan2l/ioNg3ntD/aRMu98YZGkFXt YQIy575WSL7BDfarUqZkENtOhqkzqBMvOn0BoekIdibMifJ7rR2XUJkI9708yzK5 ZVSHDidZDccixT4pjfo1cYGnfcEJMxHEe0a5EH2OpDWL8XQzpciGGOEVle2h+sw8 7tuZVgdnOCISPY2hrd+9BHhQAry5Cw3uhvhZ46rHyKfApKySCVRzcgbthbwh1Ufx LHaS4SexSILhyh76frln0MOK3B4zVw== =ycRT -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 3 08:24:28 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6423A0F02; Thu, 3 Dec 2020 08:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwq-Oupg4_p4; Thu, 3 Dec 2020 08:24:21 -0800 (PST) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 0AAF13A0DDC; Thu, 3 Dec 2020 08:24:21 -0800 (PST) Received: by mail-yb1-xb34.google.com with SMTP id x17so2538683ybr.8; Thu, 03 Dec 2020 08:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=FZZ2cu0HGBILl7o19VPEwfefZzpN8T7oQQnmGvjIygs=; b=QD1u5ne0/03+xA76c0aXvVQzJFSNnKg57KKLazyFMFhueHq4RQjYghpm67SXmNdEgt 8JN7CyCxxiblEEqOnr+c7NUNeOiyh/Uegn1UE8wnzwkORhvBEj5pbvL7zNNoywxSnAHr kDNlNEpnQxwLL93yb316+wmBRgzYaQWsgZnFoxpee2P7xJoV35p9lRsDSJlKQIVpSqcJ 9zEaeRYMwH4fewWeJJoXDHdmu89ucAhb7aVQzWwsXzwxSeuwqTycRkTu5KuQ+TerYkiz EyiyF0teysDZ0CRb8m9WKw2xNwmrs+M5QQW9iysG5Fm9FG3iYY3EPDeAFL1/a8agtBGI 5K4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=FZZ2cu0HGBILl7o19VPEwfefZzpN8T7oQQnmGvjIygs=; b=nilRA9vPgYBthkn5Ejqkn/Ur25EeUX6rQzfpyfV/meMG64EvMmkAquYfd9YXQViKfe cPvYKiLAVUvzRIDIzaBXzFysdgyRlHGM+ZsnQEHZ4xpCBxzOp8gujTxOoNOVAhc/2Plh MUHheMrmUzDhRrrKXTgrUo+xISMEA8w0ikUeldfd83tR43nE1gFUbATBqdbGAxVKf7Q0 e+1L/yaySXDX8e+pKugNmaHp6tNRdcggBVAglpW/5QLxL8uWvoSFEeBwIsGU+AIBoY83 MVYxxTFAjQX5xMa7whSWaNjN5Q+4AStcRt353cfyvymn/kJKQC/XeWq+jzqGdoOqQ6/6 MzWg== X-Gm-Message-State: AOAM530EJKG+t1YZFEIJu5Qg/vJVs6yPn18hP5p9ptARd2UXRSZCobdT lqcgikIlMFEldPWXyvXNRK3vgXyu7z5t8aBfjVo= X-Google-Smtp-Source: ABdhPJw5nDVtF4cG6dZUo/d/twxgfde7S5Dr0eS0v9TXQyQn1oq73qzUABORVTtXWNhOJpTZ27rePZxiygpQg9/xE0o= X-Received: by 2002:a25:dc8d:: with SMTP id y135mr5479194ybe.175.1607012660250; Thu, 03 Dec 2020 08:24:20 -0800 (PST) MIME-Version: 1.0 References: <689918.1606943760@dooku> In-Reply-To: <689918.1606943760@dooku> Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Thu, 3 Dec 2020 10:24:09 -0600 Message-ID: To: Michael Richardson Cc: Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000c38a8c05b591caa7" Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 16:24:24 -0000 --000000000000c38a8c05b591caa7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Michael, On Wed, Dec 2, 2020 at 3:36 PM Michael Richardson wrote: > > (trying to clean out my inbox) > > Ted Lemon wrote: > > I mentioned prior to IETF 107 that I wanted to start a conversation > > about this problem, but didn=E2=80=99t have time to write a draft. = I=E2=80=99ve > > written one, which I think describes my view of the problem pretty > > well; I=E2=80=99d like to know if what I=E2=80=99ve written here ma= kes sense to > others. > > Ted, I think that your work addresses a problem space that is in some way= s > similar to the "share64" concept. Not the same, but similar. > > I think that the use of ULA which is advertise to the "LAN" for > reachability > does not have to be mutually exclusive with NAT64 for "cloud" reachabilit= y. > > Since your document does not actually require any new protocol, but just > explains how to do something new using existing mechanism, I think that i= t > would fit into the current IOTOPS charter. > What is IOTOPS? Behcet > > In answer to your question: > State of the Art > > Currently there is one known way to accomplish what we are describing > here [[Michael, does ANIMA have a second way?]]. > > The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC655= 0) > storing mode. > > > > https://www.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt > > > Abstract: IETF currently provides protocols for automatically > > connecting single hosts to existing network infrastructure. This > > document describes a related problem: the problem of connecting a > stub > > network (a collection of hosts behind a router) automatically to > > existing network infrastructure in the same manner. > > Your criticism if HNCP is all true, but an important part is that it real= ly > only provides for allocation of prefixes; not routing. > (I still think that the WG made a mistake not extending OSPFv3) > HNCP is not the part that's missing: it's the routing protocol in the hom= e > that is what's needed to do something more complicated. > > -- > ] 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 [ > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000c38a8c05b591caa7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,



On = Wed, Dec 2, 2020 at 3:36 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

(trying to clean out my inbox)

Ted Lemon <mellon@= fugue.com> wrote:
=C2=A0 =C2=A0 > I mentioned prior to IETF 107 that I wanted to start a c= onversation
=C2=A0 =C2=A0 > about this problem, but didn=E2=80=99t have time to writ= e a draft.=C2=A0 I=E2=80=99ve
=C2=A0 =C2=A0 > written one, which I think describes my view of the prob= lem pretty
=C2=A0 =C2=A0 > well; I=E2=80=99d like to know if what I=E2=80=99ve writ= ten here makes sense to others.

Ted, I think that your work addresses a problem space that is in some ways<= br> similar to the "share64" concept.=C2=A0 =C2=A0Not the same, but s= imilar.

I think that the use of ULA which is advertise to the "LAN" for r= eachability
does not have to be mutually exclusive with NAT64 for "cloud" rea= chability.

Since your document does not actually require any new protocol, but just explains how to do something new using existing mechanism, I think that it<= br> would fit into the current IOTOPS charter.

<= div>What is IOTOPS?

Behcet=C2=A0

In answer to your question:
=C2=A0 =C2=A0State of the Art

=C2=A0 =C2=A0Currently there is one known way to accomplish what we are des= cribing
=C2=A0 =C2=A0here [[Michael, does ANIMA have a second way?]].

The ANIMA ACP sets up an overlay network with /128 routing via RPL(RFC6550)=
storing mode.

=C2=A0 =C2=A0 > https://w= ww.ietf.org/internet-drafts/draft-lemon-stub-networks-ps-00.txt

=C2=A0 =C2=A0 > Abstract: IETF currently provides protocols for automati= cally
=C2=A0 =C2=A0 > connecting single hosts to existing network infrastructu= re.=C2=A0 This
=C2=A0 =C2=A0 > document describes a related problem: the problem of con= necting a stub
=C2=A0 =C2=A0 > network (a collection of hosts behind a router) automati= cally to
=C2=A0 =C2=A0 > existing network infrastructure in the same manner.

Your criticism if HNCP is all true, but an important part is that it really=
only provides for allocation of prefixes; not routing.
(I still think that the WG made a mistake not extending OSPFv3)
HNCP is not the part that's missing: it's the routing protocol in t= he home
that is what's needed to do something more complicated.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000c38a8c05b591caa7-- From nobody Thu Dec 3 09:49:18 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4563A0A2B; Thu, 3 Dec 2020 09:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 wW91CyatE7lg; Thu, 3 Dec 2020 09:49:10 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319303A0A26; Thu, 3 Dec 2020 09:49:09 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7DD8C548049; Thu, 3 Dec 2020 18:49:01 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 76169440059; Thu, 3 Dec 2020 18:49:01 +0100 (CET) Date: Thu, 3 Dec 2020 18:49:01 +0100 From: Toerless Eckert To: Ted Lemon Cc: iotops@ietf.org, 6MAN <6man@ietf.org> Message-ID: <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> References: <695953.1606952552@dooku> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:49:13 -0000 On Wed, Dec 02, 2020 at 06:47:38PM -0500, Ted Lemon wrote: > ???This??? is what we did in the Apple thread border router. I???m nervous about anything in the IETF with IoT in the title because it will be subject to the Carsten Bormann DoS attack. Whow, i guess its christmas time, so you're trying to spread some love ? What's a CBDA ? Is that a badge of honor to wear ? I have a Van-o-Gram from the 1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i need to do to get one ? Back to business. Some high level suggestions for your doc: - Move your rants about HNCP to an appendix - Maybe also the rant about service discovery being an integral part of the problem to an appendix. although i agree that a good part of the IETF community may not have gotten the message how it is, but its still disturbing the flow of reading when preaching to the choir like me. - Put IPv6 into the title if all you care about is really only IPv6. Before this gets adopted by a WG, native support for also IPv4 should be a key scope discussion. Not everybody may have the same IP6 centric only business goal. (I Have No Opinion. Just saying). - It would be nice to start section 2 with a description of a generic model without being specific to the protocol so one can check if/what protocol options do meet the model - as opposed to only the two ones you think are in your interest. - For example: Why not simply start with DHCP-PD ? IMHO, every home router getting a prefix via DHCP-PD from a service provider is a provider of such a stub network. Of course, service discovery as you expect does usually not work in that environment, so that would need to be added. - Would be lovely to detail exaple use-cases such as that Apple device (e.g.: in an appendix) to provide better motivation and also justification for the proposed protocol choices... Cheers Toerless > I don???t know if we have visibility into the right part of Google to get the chrome problem fixed. Their IoT team is fairly far removed from their browser team. What???s the use case? > > > On Dec 2, 2020, at 18:42, Michael Richardson wrote: > > > > ??? > > Ted Lemon wrote: > >>> On Dec 2, 2020, at 16:16, Michael Richardson > >>> wrote: > >>> (trying to clean out my inbox) > >>> > >>> Ted Lemon wrote: > >>>> I mentioned prior to IETF 107 that I wanted to start a conversation > >>>> about this problem, but didn???t have time to write a draft. I???ve > >>>> written one, which I think describes my view of the problem pretty > >>>> well; I???d like to know if what I???ve written here makes sense to > >>>> others. > >>> > >>> Ted, I think that your work addresses a problem space that is in some > >>> ways similar to the "share64" concept. Not the same, but similar. > > > >> Yes. But I think share64 on a WiFi network would require proxy ND, > >> which doesn???t scale well, particularly if you have multiple unmanaged > >> routers providing readability and transit. > > > > I wasn't saying that the same solution applies, but rather the problem space > > is the same. Device-X has some IPv6 on a network "behind" it, and wants to > > share addresses on a wifi/LAN in front of it in order to enable connectivity. > > > > I'm unclear from reading your document if the RA's would have L=0 or L=1. > > > >>> I think that the use of ULA which is advertise to the "LAN" for > >>> reachability does not have to be mutually exclusive with NAT64 for > >>> "cloud" reachability. > > > >> Absolutely. That???s what we???re thinking for the ipv4 and dual stack > >> cases. Doesn???t work for v6-only. > > > > So, if the LAN is v6-only and does not have DHCPv6-PD or HNCP+Babel, then I > > think it's a fail for cloud connectivity. In particular, in this case, it's > > hard to report the failure to anyone offsite! > > > > It might be worth describing how this failure case could be reported intelligently. > > This is an operational kind of thing which is in charter for IOTOPS. > > > >>> Since your document does not actually require any new protocol, but > >>> just explains how to do something new using existing mechanism, I > >>> think that it would fit into the current IOTOPS charter. > > > >> I don???t think this is IoT-specific. I would prefer to do the work in > >> intarea. > > > > I don't think something needs to be IoT-only to belong in IOTOPS. > > > >>> In answer to your question: State of the Art > >>> > >>> Currently there is one known way to accomplish what we are describing > >>> here [[Michael, does ANIMA have a second way?]]. > >>> > >>> The ANIMA ACP sets up an overlay network with /128 routing via > >>> RPL(RFC6550) storing mode. > > > >> I don???t get a mental picture from this of how it helps. > > > > I'm sorry, I didn't finish the thought. "It does not help at all" > > > >> FWIW, Apple is now shipping a product (HomePod Mini) that does stub > >> network routing for thread networks, and there???s also an open source > >> implementation. Right now it only does the ULA solution. I???ll be > >> writing a draft that describes this soon. > > > > I'm unclear what "this" is. > > > > -- > > ] 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 [ > > > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Thu Dec 3 10:26:20 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136CA3A0B8A; Thu, 3 Dec 2020 10:26:15 -0800 (PST) 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 rAT5LqZsIyr5; Thu, 3 Dec 2020 10:26:13 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520D43A0CA2; Thu, 3 Dec 2020 10:26:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EF875389CD; Thu, 3 Dec 2020 13:27:53 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hgdyKcgg8dlu; Thu, 3 Dec 2020 13:27:50 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 52904389CC; Thu, 3 Dec 2020 13:27:50 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 623EB1FB; Thu, 3 Dec 2020 13:25:57 -0500 (EST) From: Michael Richardson To: sarikaya@ieee.org cc: 6MAN <6man@ietf.org>, iotops@ietf.org In-Reply-To: References: <689918.1606943760@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 18:26:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Behcet Sarikaya wrote: >> Since your document does not actually require any new protocol, but = just >> explains how to do something new using existing mechanism, I think t= hat it >> would fit into the current IOTOPS charter. >> > What is IOTOPS? https://datatracker.ietf.org/wg/iotops/about/ Proposed WG. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/JLbUACgkQgItw+93Q 3WUeQAgAj401bqYHy0YDUW1clzdBPevaeIYL4mJmMD253Uoky3V7hfK1n24DjsX/ gBaMBDZmHgMyZ9DtPA68sU5eLg0XPN/xWC9i2wpHTYCTuV3iH3wGFUZlBtI1g74Q wAnv9TYfv/nY1+ssYoi1HjTU6lNz8ae39G8LrVQIlwomNBAR9eFD6Y763rKVMw2L 3BFhKg0vrMDD5c3YEL+uoxLjYqlBddZGn5wBMf+5k3ZUz9cXHD29UMPO3K1qJCNb 4XCnwPklnyi9CuewRVu1IoX7cX2tQnR7JUhAQsb57ZlQ1cTJNHYgMSaBIfRWwNDm CdXbYxK0S+UluWUeT20syB+G1R1TRA== =8Lgu -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 3 10:32:06 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1553A0B36 for ; Thu, 3 Dec 2020 10:32:04 -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=ham 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 Ix03n-HWh9yG for ; Thu, 3 Dec 2020 10:32:02 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 148F43A0B1F for ; Thu, 3 Dec 2020 10:32:01 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id x25so3067490qkj.3 for ; Thu, 03 Dec 2020 10:32:01 -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=6bk8A26dS/aHEPxYqPlRH+h4t9LqF8i8IoTPgPVKyu8=; b=WT5Q9Wh7k4uonyyvD5xO0XQ8s21mBPtdxO5lo7+Je43Wc+2Yzgea4qpbLRs6U1veb+ j3f2zMYxmoYgOIK2XKF5NS22s8dWHXbn0UUimW0xTXtJoQH+AkFvQ8OMwxoF8gCXtQuk uwrU+/h3pt6VuvYEDx8i6QR2hZDEixtIjVdWjm91HkuGQLG/NzY7cl05ch1kIXRuUkv2 Y3/+j2UWomjF2u/VKJDftc2uXaLRW53IbS4a9D5megiVOV3V6kMw7RBzdcM1aVAnbEqW yE860IxCVK1f2f1qeLwEfmk+F1w4ePlCNwgVZvfnXpg2bN7kOaN1wwrbcV0CP4uihhPy MqeA== 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=6bk8A26dS/aHEPxYqPlRH+h4t9LqF8i8IoTPgPVKyu8=; b=IvTZe0oJxi7ZI7NbyQV31KdiS2r59brZvZ/J1mJ+b+pm2KAYvFfncI/Fck2/6Gj8Wa aAwZcFfzpzTZzo11Askd59Cg/JLq71NtrMEfSL+iM9ZAVnas41Fd2T7SD9aQSOEhSN7q fNxPSBlDfPExs0hJMmA9TqDDe4QQA8DP0VKaNcV6v+nTUtl7NqWCA8LQeoeMQzaIIW87 gIX4rZ+BSfxHPqmNVpRDc6wTDdNDXWWQ5KMMaSLmemjHI6b9Jwq/Y29ODQg5OzZ2RbO/ 1ciw57GKEjtDPsaCTT2P/wlKefzhWeeWKOnhy31W1lzvI0SwDz1zxevyCwxB7Zu3rE8R sR0Q== X-Gm-Message-State: AOAM531/TfhbaeuiAwg8NV0UUPuKVnZidjFXRu50sTLxXkSh9/NJEQAx f9BoUBZpqpSXNruCizN6Pxd3Y9Igq23MHKTC X-Google-Smtp-Source: ABdhPJyotHOFWo+MEb3LZALTbceBcFchEVhL3YDVzs4JRXBNSUb1/69PH4wiZZI8ppWPWBvV0cU5xw== X-Received: by 2002:a05:620a:4047:: with SMTP id i7mr4233753qko.3.1607020320886; Thu, 03 Dec 2020 10:32:00 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x124sm2241647qkc.25.2020.12.03.10.31.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 10:32:00 -0800 (PST) From: Ted Lemon Message-Id: <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_44C417F7-5790-44D9-A303-583EE6FA7A76" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 3 Dec 2020 13:31:57 -0500 In-Reply-To: <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> Cc: iotops@ietf.org, 6MAN <6man@ietf.org> To: Toerless Eckert References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 18:32:04 -0000 --Apple-Mail=_44C417F7-5790-44D9-A303-583EE6FA7A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 3, 2020, at 12:49 PM, Toerless Eckert wrote: > What's a CBDA ? Is that a badge of honor to wear ? I have a Van-o-Gram = from the > 1990'th. Maybe i can upgrade by breast plating with a CBDA ? What do i = need to do to get one ? It=E2=80=99s me being a jerk. Sorry about that. > Back to business. Some high level suggestions for your doc: >=20 > - Move your rants about HNCP to an appendix They aren=E2=80=99t rants. There is no deployable HNCP. HNCP was the = first solution we thought of, and was my original preference for a = solution, but it isn=E2=80=99t a solution for the reasons stated. = That=E2=80=99s part of the problem statement. If you have specific text = that you think is a rant, and not a problem statement, please propose = changes. > - Maybe also the rant about service discovery being an integral part = of the problem to an appendix. > although i agree that a good part of the IETF community may not have = gotten the message how it is, > but its still disturbing the flow of reading when preaching to the = choir like me. In what sense is this a rant? How do you discover hosts on the stub = network without some kind of service discovery protocol? How do hosts on = the stub network discover services on the infrastructure network? = Consider this: is your internet connection useful if DNS is not = available? (I mean _really_ not available, not just that you didn=E2=80=99= t get the IP address of a resolver from your ISP). > - Put IPv6 into the title if all you care about is really only IPv6. > Before this gets adopted by a WG, native support for also IPv4 should = be a key scope discussion. > Not everybody may have the same IP6 centric only business goal. > (I Have No Opinion. Just saying). I don=E2=80=99t know of a way to solve this with IPv4 without HNCP or = something like it. That is, there=E2=80=99s no automatic mechanism that = we could use in IPv4 that=E2=80=99s similar to what=E2=80=99s available = in IPv6. > - It would be nice to start section 2 with a description of a generic = model > without being specific to the protocol so one can check if/what = protocol options > do meet the model - as opposed to only the two ones you think are in = your interest. Fair point. > - For example: Why not simply start with DHCP-PD ? IMHO, every home = router getting > a prefix via DHCP-PD from a service provider is a provider of such a = stub network. > Of course, service discovery as you expect does usually not work in = that environment, > so that would need to be added. We didn=E2=80=99t start with DHCPv6-PD because we needed something that = will work in any network, not just in networks where DHCPv6-PD is = present. > - Would be lovely to detail exaple use-cases such as that Apple device = (e.g.: in an appendix) > to provide better motivation and also justification for the proposed = protocol choices=E2=80=A6 That sounds like a good idea. When I submitted the draft, this wasn=E2=80=99= t an option because the product hadn=E2=80=99t yet been announced=E2=80=A6= :) Thanks for the review and feedback. Sorry about being a jerk, and please = let me know if there=E2=80=99s specific text that feels like it=E2=80=99s = a rant. --Apple-Mail=_44C417F7-5790-44D9-A303-583EE6FA7A76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 3, 2020, at 12:49 PM, Toerless Eckert <tte@cs.fau.de> wrote:
What's a CBDA ? Is that = a badge of honor to wear ? I have a Van-o-Gram from the
1990'th. Maybe i can upgrade by breast plating with a CBDA ? = What do i need to do to get one ?

It=E2=80=99s me being a jerk. Sorry about = that.

Back to = business.  Some high level suggestions for your doc:

- Move your = rants about HNCP to an appendix

They aren=E2=80=99t rants. There is no deployable HNCP. = HNCP was the first solution we thought of, and was my original = preference for a solution, but it isn=E2=80=99t a solution for the = reasons stated. That=E2=80=99s part of the problem statement. If you = have specific text that you think is a rant, and not a problem = statement, please propose changes.

- Maybe also the rant about service discovery being an = integral part of the problem to an appendix.
 although = i agree that a good part of the IETF community may not have gotten the = message how it is,
 but its still disturbing the flow of reading when = preaching to the choir like me.

In what sense is this a rant? How do you discover hosts = on the stub network without some kind of service discovery protocol? How = do hosts on the stub network discover services on the infrastructure = network? Consider this: is your internet connection useful if DNS is not = available? (I mean _really_ not available, not just that you didn=E2=80=99= t get the IP address of a resolver from your ISP).

- Put IPv6 = into the title if all you care about is really only IPv6.
 Before = this gets adopted by a WG, native support for also IPv4 should be a key = scope discussion.
 Not everybody may have the same IP6 centric only = business goal.
 (I Have No Opinion. Just saying).

I don=E2=80= =99t know of a way to solve this with IPv4 without HNCP or something = like it. That is, there=E2=80=99s no automatic mechanism that we could = use in IPv4 that=E2=80=99s similar to what=E2=80=99s available in = IPv6.

- It would be = nice to start section 2 with a description of a generic model
 without = being specific to the protocol so one can check if/what protocol = options
 do meet = the model - as opposed to only the two ones you think are in your = interest.

Fair = point.

- For = example: Why not simply start with DHCP-PD ? IMHO, every home router = getting
 a = prefix via DHCP-PD from a service provider is a provider of such a stub = network.
 Of = course, service discovery as you expect does usually not work in that = environment,
 so that = would need to be added.

We didn=E2=80=99t start with DHCPv6-PD because we = needed something that will work in any network, not just in networks = where DHCPv6-PD is present.

- Would be lovely to detail exaple use-cases such as that = Apple device (e.g.: in an appendix)
 to provide better motivation and also justification for = the proposed protocol choices=E2=80=A6

That sounds like a good idea. When I = submitted the draft, this wasn=E2=80=99t an option because the product = hadn=E2=80=99t yet been announced=E2=80=A6 :)

Thanks for the review and feedback. Sorry = about being a jerk, and please let me know if there=E2=80=99s specific = text that feels like it=E2=80=99s a rant.

= --Apple-Mail=_44C417F7-5790-44D9-A303-583EE6FA7A76-- From nobody Thu Dec 3 10:52:05 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970553A0475; Thu, 3 Dec 2020 10:52:03 -0800 (PST) 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 zIreh9p86rIJ; Thu, 3 Dec 2020 10:52:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA283A03FC; Thu, 3 Dec 2020 10:52:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 20CA7389CD; Thu, 3 Dec 2020 13:53:53 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3cP2K0LXr_Y3; Thu, 3 Dec 2020 13:53:52 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A30DE389CC; Thu, 3 Dec 2020 13:53:52 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9C2221FB; Thu, 3 Dec 2020 13:51:59 -0500 (EST) From: Michael Richardson To: Toerless Eckert , Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org In-Reply-To: <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 18:52:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Toerless Eckert wrote: > - For example: Why not simply start with DHCP-PD ? IMHO, every home r= outer getting > a prefix via DHCP-PD from a service provider is a provider of such a = stub network. > Of course, service discovery as you expect does usually not work in t= hat environment, > so that would need to be added. While there is a CableLabs spec that argues for stacked DHCPv6-PD (and it w= as presented in Homenet a few years back), to date, I'm aware of no deployed home routers that operate a DHCPv6-PD server on their southbound interface. Conceptually it's simple to implement. Architecturally there are some who thinks it is gross, and some who think it's brilliant. I'm still sitting on the fence myself. But, fundamentally, the issue Ted is trying to address is enabling communications within the Home between layer-2s that can not, or should not, be bridged. I agree with your other suggestions for re-organization. I have some ideas about how I would write this document. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/JM88ACgkQgItw+93Q 3WWJuQf/SFUIHSf/myAg8APhYzTsu5ULCiYuGKEoazveAa7xs4E4qC8G07k0Gp2c vRA0ysrO33oSCiZ2Ds8sEuL3c4gomhJYfJx0WGgXOiLR0iDEbE9TWRhUQwlrTYqE lzBLdi9/dB1lBCHybdIjY/4EF+HXAvO0MA/njGDtyxSmKPach8qvphJQc7N16myE Y+N3m9nt2EVsOU66GSqnYYcIK1DF5vi8ea7S6ueENXpcFd1qIF8sh9y9HKsu4mrH y/llqQ5clvKV9CrUtefrOKuv9Msp6TrnsMqDJtZYRItqGQteKG61tqbW1jJbBjK1 KytP6lEfX8LBIUVpiBeH2Z3ArbPRtg== =pf79 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 3 11:08:46 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B163A074B for ; Thu, 3 Dec 2020 11:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 OGB1EB7g_MpL for ; Thu, 3 Dec 2020 11:08:39 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 C26773A0769 for ; Thu, 3 Dec 2020 11:08:39 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id i199so3177453qke.5 for ; Thu, 03 Dec 2020 11:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T314dZOcDBM8ecEOeJIn3BZE0zaFZN0j/Ho6kuLgcCE=; b=K3gn2KeJ45/1MfkrbFhUSJL8bWkpkpZtWT4bMMw3asSPk2N5+58DNZuI2Gc4iEq5AN ea7PGbPiGuRfas9YxaX4FdwTQjuEmZn1MvR4Xc3p8z2nytaaDPGaH9zPBUxVhTxmALn2 BV/XL3vl55UCfDcjJeQDPWNmMDLzJt5Vi5B+fGn3W7tNWhpxo3LmtJRwKkJWHOI7Lqiw swUmPCm3Exj3cyMwF0kF1QpFtXaPFq2FBBDYQjso12i0f/5l5wyd2gofMZC/MfVo/SNF sI7SbTc65/Xcfl9oyJxAVAjJNRkQkfEBsis0l6MJLOqgCbT4l7ItRfkkHWw+VS0if+ml suJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T314dZOcDBM8ecEOeJIn3BZE0zaFZN0j/Ho6kuLgcCE=; b=Y7OHUXSQVcJyvYHczadiX+mFJAGOrZqlzFF42pcQHHQZRmL94HHBzIwxVtk67HTNep EiYelQhaS3gt4w4tVUs+uhlltNlN9a6nMmjm7nTleP5xG+EJKs5qtnZkkTdEVgS/KSRo jUsRMsU8opVXT9DSdUA4qBMVIRji8n9VbNngmCZhC94KZWGhJcUz0eme9LbWDzf2qs88 HC7jC0Vn9CSAjP3udJhNXAmfSBDArDyPxGZsHBnKPDgtCv+cqEqq57iTe+6b0GN1FFj7 qzQE9hiPsJ9ZsBCi84Jdka/FxBK8obg0UxDDOd1RzWqLAL/Y50WXebCvBYj+IqdfOnsS Gqnw== X-Gm-Message-State: AOAM532+9SXdYamUo0v4CysyyLg7d2epwOwoIukM9py5bzUJCEyOz0HQ 1DGbZNZvwkppCttZelqmU/3cySpCFTkJ0VWV X-Google-Smtp-Source: ABdhPJxlfq/FsfvelDkpIAZa7KtYW/qXc3KeC45esFn+0XM6E48QHf/ZGvwGn+sP0U1cPg2aA4oNJw== X-Received: by 2002:a37:5156:: with SMTP id f83mr4506037qkb.197.1607022518481; Thu, 03 Dec 2020 11:08:38 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 5sm2058632qtp.55.2020.12.03.11.08.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 11:08:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Ted Lemon In-Reply-To: <3988.1607021519@localhost> Date: Thu, 3 Dec 2020 14:08:35 -0500 Cc: Toerless Eckert , 6MAN <6man@ietf.org>, iotops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:08:42 -0000 If we were to stack PD, that would not be a stub network, although I = think it=E2=80=99s an interesting increment. But the way to do it is = with DHCPv6 relays on the (no longer) stub routers. Otherwise you have a = tree balancing problem that=E2=80=99s totally unnecessary. And you still = need Babel or OSPF or something to manage routing. I=E2=80=99d be happy to have a co-author, if you are interested, = Michael. :) > On Dec 3, 2020, at 1:51 PM, Michael Richardson = wrote: >=20 >=20 > Toerless Eckert wrote: >> - For example: Why not simply start with DHCP-PD ? IMHO, every home = router getting >> a prefix via DHCP-PD from a service provider is a provider of such a = stub network. >> Of course, service discovery as you expect does usually not work in = that environment, >> so that would need to be added. >=20 > While there is a CableLabs spec that argues for stacked DHCPv6-PD (and = it was > presented in Homenet a few years back), to date, I'm aware of no = deployed > home routers that operate a DHCPv6-PD server on their southbound = interface. >=20 > Conceptually it's simple to implement. > Architecturally there are some who thinks it is gross, and some who = think > it's brilliant. I'm still sitting on the fence myself. >=20 > But, fundamentally, the issue Ted is trying to address is enabling > communications within the Home between layer-2s that can not, or = should not, > be bridged. >=20 > I agree with your other suggestions for re-organization. > I have some ideas about how I would write this document. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 From nobody Thu Dec 3 15:26:29 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002F33A09A8; Thu, 3 Dec 2020 15:26:22 -0800 (PST) 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 F06ZXrDGYbNN; Thu, 3 Dec 2020 15:26:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEE03A0EF5; Thu, 3 Dec 2020 15:26:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2F17B389CD; Thu, 3 Dec 2020 18:28:11 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1C6TwvWVzNCC; Thu, 3 Dec 2020 18:28:04 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ACE0C389CC; Thu, 3 Dec 2020 18:28:04 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id ED22C6B9; Thu, 3 Dec 2020 18:26:10 -0500 (EST) From: Michael Richardson To: Ted Lemon cc: 6MAN <6man@ietf.org>, iotops@ietf.org In-Reply-To: References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 23:26:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > If we were to stack PD, that would not be a stub network, although I > think it=E2=80=99s an interesting increment. I think that we must be talking past eachother. 1) DHCPv6-PD x 1: home-router to ISP. 2) DHCPv6-PD x 2: stub-router to home-router. Behind the stub-router there would be no DHCPv6-PD, just RPL or Zigbee or Thread, or whatever. But, no current home routers support (2), so it won't work. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/JdBIACgkQgItw+93Q 3WWvqQf+LZrUN0i5i3DIWcI5etZB3CzA3ryKtGqJUD2XXk5GZTXWwkK20/BDAH5e 9Hs0XfrYi2veLLnEn6E+WKQikjyPDo+qiy/4kLHrZkcbZwMvYrX9ERTyQkXusfRe jfiEKka1b3YKc1LnSQFXSf4E9sEnf1LLni1VzrSlKHe+p74Gre+/6tiI4co7pS62 kbyxbJHxe28XbIGyWwgU/1xZTy7sjaq0KYi1yg2LqqksbhvaaFcI21HYEaaUQ0vD n2qk9dy/Kx2jYne/uHOdpG/nG8q2lQ1k/rXhhjn4vuvD6YRo6s4RQlRMpMmb9Gv0 0QZCrYheXXcA0MosECHck5qNtJlApw== =3IVD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 3 16:05:48 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524B33A10D3 for ; Thu, 3 Dec 2020 16:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 D8RytRVzz4ki for ; Thu, 3 Dec 2020 16:05:45 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 DF0883A10CD for ; Thu, 3 Dec 2020 16:05:44 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id q22so3980811qkq.6 for ; Thu, 03 Dec 2020 16:05:44 -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=vj975XWrQeFr3y0T/dnpGUdQU3vdsi4lzKkiZzc8z8o=; b=a7hFQYzqFSUhSooq4eyuf430fz1TaxWGnC2/IBpQdfW8PJgGA57DGfsAmltNcd99wI qwGndVir/bmh84JkF+mqvHgOuwQb8XjY42JFVE3f5NsVpbPeeWBstg2E3vymh+RdLhQ8 0umJPudW/hv9oJJNMeAg2+wAhqFrFi8BwkO2E+ioKc7uB1GMtMHqkt50DX/GAULNPRJH Camzask/Gl0S/KRqtjD7fNk91wTcrTHwxIdDfq1qFei/joZenqve+VVNYQupW5AKgPft uPa/69VhhBwEKUNSu1suszMAO+nvhuHiyoyp+KAm8IxUOj9aV+HmEXSYNjqpt4bM9R4y chrw== 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=vj975XWrQeFr3y0T/dnpGUdQU3vdsi4lzKkiZzc8z8o=; b=MQngk5MmncgWEPyR53P8TDUpiUXFILtjhTC/0AnFXeR8yAzjH3H1OcU2EboZr4i0Nq q0q9kjqEYIRJTlMMZprRzqHkr6Vnw60OvbqruuFpsZQj7VdKcO+Xe+ZXEXEJ7KcoXE7Y gvifbILI4lGRY5Vyp3eolR9jiq26YiIaukdWU8gI+Pgif9kKAIK26TwdHoh2HKCZRyw+ sn7DO+In1GSSqNWHmps0SWRti+788pi1W6Mlhgz2uEi3fTwPgQxH8ArEbGCX6poZUK6+ IHNI0AVK5gbmkcMwllnaGso5wbBVtICjOlqvueiWpzIA/mPWbw+oNPO+rj2qw6b4ZnlP +PJA== X-Gm-Message-State: AOAM533GpJOolllruUCpMMVMqxTr8AXnhExtexkflIVlZ2yyyMeSZo32 TiMwjoqddfs1deSkYHhTj+AWBg== X-Google-Smtp-Source: ABdhPJwwYUd5a/ZQfzRoNS8X/sTiPEi/Mll+u9ngwl5ZDZRdn7WakjfUDzgprm6KsSUwbdIPzEWnrA== X-Received: by 2002:a05:620a:a9a:: with SMTP id v26mr5822937qkg.56.1607040343695; Thu, 03 Dec 2020 16:05:43 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id n21sm3272767qke.21.2020.12.03.16.05.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 16:05:43 -0800 (PST) From: Ted Lemon Message-Id: <70EE1AE0-BF1B-4FE2-932D-6A39542AE0FD@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B9D972FA-0E71-49EA-A600-8001100358EC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 3 Dec 2020 19:05:41 -0500 In-Reply-To: <4424.1607037970@localhost> Cc: 6MAN <6man@ietf.org>, iotops@ietf.org To: Michael Richardson References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> <4424.1607037970@localhost> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 00:05:46 -0000 --Apple-Mail=_B9D972FA-0E71-49EA-A600-8001100358EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 3, 2020, at 6:26 PM, Michael Richardson = wrote: > But, no current home routers support (2), so it won't work. I don=E2=80=99t think this assertion is true. I=E2=80=99m pretty sure = Comcast put quite a bit of effort into making it not be true a few years = back. It=E2=80=99s certainly true (last time I checked) that OpenWRT = doesn=E2=80=99t support it, though. --Apple-Mail=_B9D972FA-0E71-49EA-A600-8001100358EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 3, 2020, at 6:26 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
But, no current home routers support (2), so it won't = work.

I don=E2=80=99t think this assertion is true. I=E2=80=99m = pretty sure Comcast put quite a bit of effort into making it not be true = a few years back. It=E2=80=99s certainly true (last time I checked) that = OpenWRT doesn=E2=80=99t support it, though.

= --Apple-Mail=_B9D972FA-0E71-49EA-A600-8001100358EC-- From nobody Thu Dec 3 22:49:45 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A69B3A13C2; Thu, 3 Dec 2020 22:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9JAUlyAhBtXt; Thu, 3 Dec 2020 22:49:41 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E7E3A13C0; Thu, 3 Dec 2020 22:49:39 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0F017548005; Fri, 4 Dec 2020 07:49:31 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 03197440059; Fri, 4 Dec 2020 07:49:30 +0100 (CET) Date: Fri, 4 Dec 2020 07:49:30 +0100 From: Toerless Eckert To: Ted Lemon Cc: iotops@ietf.org, 6MAN <6man@ietf.org> Message-ID: <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 06:49:44 -0000 On Thu, Dec 03, 2020 at 01:31:57PM -0500, Ted Lemon wrote: > > Back to business. Some high level suggestions for your doc: > > > > - Move your rants about HNCP to an appendix > > They aren???t rants. I was just referring to the style, not payload "long passionate explanation, i am sure was given repeatedly already" ;-)). > There is no deployable HNCP. HNCP was the first solution we thought of, and was my original preference for a solution, but it isn???t a solution for the reasons stated. That???s part of the problem statement. If you have specific text that you think is a rant, and not a problem statement, please propose changes. I probably don't disagree with whats said in the text, except that i am only aware of all the discussion and alternatives back when it was designed, but i lost track for the past few years,so i'd need to upgrade my current status before i could say i fully agree. Just don't make it disturb the flow and move it down into some appendix or the like. > > - Maybe also the rant about service discovery being an integral part of the problem to an appendix. > > although i agree that a good part of the IETF community may not have gotten the message how it is, > > but its still disturbing the flow of reading when preaching to the choir like me. > > In what sense is this a rant? How do you discover hosts on the stub network without some kind of service discovery protocol? How do hosts on the stub network discover services on the infrastructure network? Consider this: is your internet connection useful if DNS is not available? (I mean _really_ not available, not just that you didn???t get the IP address of a resolver from your ISP). IMHO, its a rant because everybody should know and agree. And explanations for those not in the know should be in an appendix. > > - Put IPv6 into the title if all you care about is really only IPv6. > > Before this gets adopted by a WG, native support for also IPv4 should be a key scope discussion. > > Not everybody may have the same IP6 centric only business goal. > > (I Have No Opinion. Just saying). > > I don???t know of a way to solve this with IPv4 without HNCP or something like it. That is, there???s no automatic mechanism that we could use in IPv4 that???s similar to what???s available in IPv6. > > > - It would be nice to start section 2 with a description of a generic model > > without being specific to the protocol so one can check if/what protocol options > > do meet the model - as opposed to only the two ones you think are in your interest. > > Fair point. To pick on on HNCP for example: The generic part could raise requirements, e.e.: Clients ---infra-network---- infra-router [A] Clients ----stub-network ---stub-router --- (new)-signaling --- infra-router [B] infra-network Goal of the document (IMHO) would be to: a) make stub-network in [B] perform as much as possible equally to infra-network in [A] ideally no changes. Of course,we'd need to define infra-network accordingly to support all required functions. Such as DNS-SD. b) focus on defining the information elements on the [B] infra elements between infra-router and stub-router, so that stub-router can create stub network. b) is IMHO fundamental, because it would allow for supporters of protocols, let's say HNCP that is not considered in this draf to equally build their own extension draft also implementing the information elements from b) in a separate draft. > > - For example: Why not simply start with DHCP-PD ? IMHO, every home router getting > > a prefix via DHCP-PD from a service provider is a provider of such a stub network. > > Of course, service discovery as you expect does usually not work in that environment, > > so that would need to be added. > > We didn???t start with DHCPv6-PD because we needed something that will work in any network, not just in networks where DHCPv6-PD is present. Given how seemingly new signaling extensions are required, the question is what protocol is the best basis to extend, and DHCPv6 with PD seems like a good basis. I understand how there are religious DHCP lower and haters though, but from past work with SPs, i just know a lot of things DHCP can much more nicely do than just RA. for example transparently passing through additional DHCP options from the infra router through the stub-router to the clients. So in doubt count me in as weak DHCP lover... Of course, if the information elements are embodied into DHCP, then it is of course also much easier to support IPv4 natively. > > - Would be lovely to detail exaple use-cases such as that Apple device (e.g.: in an appendix) > > to provide better motivation and also justification for the proposed protocol choices??? > > > That sounds like a good idea. When I submitted the draft, this wasn???t an option because the product hadn???t yet been announced??? :) THanks. I am always motivated by real world data/needs. > Thanks for the review and feedback. Sorry about being a jerk, and please let me know if there???s specific text that feels like it???s a rant. I am sure carsten isn't worried and i do appreciate to have folks (such as him) in the community that help to improve our technologies for their field of expertise, even if that turns out to be a pain in unnamed body parts. Wouldn't want security folks to have a monopoloy on that role. Wrt. "rant", consider it to be term of friendly stylistic nitpicking.. Cheers Toerless -- --- tte@cs.fau.de From nobody Fri Dec 4 00:19:28 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2653A15B2; Fri, 4 Dec 2020 00:19:22 -0800 (PST) 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 KdYOGPBydOo2; Fri, 4 Dec 2020 00:19:17 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17233A151C; Fri, 4 Dec 2020 00:19:17 -0800 (PST) Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 4245B4E11B08; Fri, 4 Dec 2020 08:19:16 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 1532746DF105; Fri, 4 Dec 2020 09:19:14 +0100 (CET) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C3382936-5006-4ECA-A9BD-6A577EA63BEA"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Fri, 4 Dec 2020 09:19:13 +0100 In-Reply-To: <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> Cc: Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org To: Toerless Eckert References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 08:19:23 -0000 --Apple-Mail=_C3382936-5006-4ECA-A9BD-6A577EA63BEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let's me see if I can dissect Ted's arguments against HNCMP in = https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00#section-1.3, = and if restricting the problem to only allowing stub routers to be = connected to a single router helps. (A topology with a single root = router and a single level of branches). 1) HNCP only works if all routers in the AS runs it. It's a routing = protocol so that's not surprising. Solutions would have to either participate in routing and a prefix = assignment protocol. The degenerate case for routing is default route upstream and a static = route for the assigned prefix downstream. All traffic to sieblings would go via root router. Ted also mentions that HNCP does not deal with the case where only a /64 = has been delegated to the site. In homenet we did a conscious choice of requiring a site to get enough = addressing to get a /64 for each link. I do know that the implementation in OpenWRT does support a single /64 = (it subnets into /80s and does DHCP address assignment). How to deal with a case of not enough addresses assigned is not a = problem unique to HNCP though. The degenerate case for addressing is: a) Split up a /64 in pools of addresses for DHCP b) If less than a /64 (e.g. already shared) then NAT 2) HNCP is too complex and does too much and is not implemented. Not enough details to make any arguments for or against this one. If one standard isn't deployed and implemented is a weak argument for = inventing a new protocol and standardising that, that's neither = specified, implemented nor deployed. Question, what are the requirements here? A) Stub network. Is it possible to restrict the topology to a single = root/single level of leafes? It prohibits multi-homing. What about the case where a node is attached = to the stub with a hypervisor and VMs requiring addressing? Is sending all traffic via the root acceptable? Instead of short-cutting = between stub routers? B) Is it possible to restrict the solution to the site having been = delegated enough address space? Or do you need to handle the cases where the site has: a) not received enough /64s to number all links b) have only been delegated a single /64 c) have only a shared /64 d) have only a single address Cheers, Ole --Apple-Mail=_C3382936-5006-4ECA-A9BD-6A577EA63BEA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdu1h07DO3As4hPTA3JCvLd9yNkgFAl/J8QEACgkQ3JCvLd9y NkjsVw/+KrPQDID5NXNYI2JMAo1RQI9HSp5+eQmBdrKB+gfTc0hN2ScMXN09xRws 4K6YPKpf+8y1JNpMmcdoaN7vxYipAeSKWpoATObXT3/m3PjzRVvyeCMBhA5SHvlj aJ+3KEezCZujUxAfR2SH/YbXDiSFJbEtyfDZQw/pIdVxBbVwiSKcEqpMNOrb8sYm a2pZMucRtoAESDvkdgDQRvzBUDwR4unwzPBfJ4b/xZm3ZO3OmeSThWavfOFLOdJ/ EMPbDbwBRA4fKVsBNjNvMrRXI1Q9RbOhqqpa5+PHdu1zmpINTzwxajyXFiOI9/Uu 0t/L4m6sK61mUzdNJ+T4S5FigpGs2EuZXXX0dePYF6xMafF8MVT5WBoeUXLDGsow JNM4DKJOSmHXUExUDnRPzr5XVsomlDDFr75KGAIncYja9bJNfV0tGxf01wQFtcka RYQwiUFv60sursis2vw4GHCrN7RLXpBVPKLqHFPBWsyGIC2YD9IAw5sticoSPyJF r+poSw6UgEY1Qk58v9Fobm4z10+rV7jeDORQdgYSjKLXUsWo1gC3n7UMYd23dDR5 VahJtCczs+bAMJmaqrSv61VW4Cl21S8dNC/DVNfzRqgRf6FS6WD/zTlLBlWS7gaA 6cjqmnZSyehYRANOWjUvji3vUcRBB5/dbVJwU4lL4i0TZ/RXVtM= =9dA6 -----END PGP SIGNATURE----- --Apple-Mail=_C3382936-5006-4ECA-A9BD-6A577EA63BEA-- From nobody Fri Dec 4 00:57:54 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022313A135B; Fri, 4 Dec 2020 00:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 9NNnqD5Y6JNh; Fri, 4 Dec 2020 00:57:46 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2457C3A1163; Fri, 4 Dec 2020 00:57:45 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9402A548053; Fri, 4 Dec 2020 09:57:38 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8CF86440059; Fri, 4 Dec 2020 09:57:38 +0100 (CET) Date: Fri, 4 Dec 2020 09:57:38 +0100 From: Toerless Eckert To: otroan@employees.org Cc: Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org Message-ID: <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 08:57:49 -0000 On Fri, Dec 04, 2020 at 09:19:13AM +0100, otroan@employees.org wrote: > Question, what are the requirements here? Indeed. Lets first focus on that. > A) Stub network. Is it possible to restrict the topology to a single root/single level of leafes? I would fear the current business cases might be fine with such a limitation, but i for once would find it dissatisfactory if the protocol solution would be limited to just one level. > It prohibits multi-homing. What about the case where a node is attached to the stub with a hypervisor and VMs requiring addressing? > Is sending all traffic via the root acceptable? Instead of short-cutting between stub routers? > > B) Is it possible to restrict the solution to the site having been delegated enough address space? > Or do you need to handle the cases where the site has: > a) not received enough /64s to number all links > b) have only been delegated a single /64 > c) have only a shared /64 > d) have only a single address Not trying to answer all these points, but: To me the most simple model is around the following constraints/requirements: stub-router ----link --- infra-router a) stub-router and infra-router are potentially different admin, aka: we do not want to use signaling between them such as a typical link-state-routing protocol where you can not create good trust-domain boundries within the topology. Dijkstra protos are a bit better, but i think no one has tried to come up with good definitions for "internal" trust boundaries. b) infra-router hands out prefix(es) to stub-router. It shouldn't have anything to say about how stub-router uses them. So stub-router could subtend sub-prefixes as it sees fit. Infra router does NOT accept prefixes back from stub-router. Not sure yet about similar rules for the naming / services for DNS-SD, but there may need to be some similar rules. And from service provider use cases, i remember various other DHCP options that infra-router may need to see proxied across stubb-router to clients if/when clients rely on DHCP opions instead of DNS-SD to discover specific services. Which for example in the home a lot of the service-provider equipment such as IPTV STBs expects to be able to do. Cheers Toerless > > Cheers, > Ole > -- --- tte@cs.fau.de From nobody Fri Dec 4 01:19:46 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6C3A1224; Fri, 4 Dec 2020 01:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Jv2ctSNBUXvU; Fri, 4 Dec 2020 01:19:39 -0800 (PST) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8DD3A0B0B; Fri, 4 Dec 2020 01:19:38 -0800 (PST) Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id EF5784E11B75; Fri, 4 Dec 2020 09:19:37 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D29A446E316F; Fri, 4 Dec 2020 10:19:35 +0100 (CET) From: otroan@employees.org Message-Id: <784BB35E-D9A3-413B-912D-46D12CCB34B8@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_2629654B-2178-464A-8A6D-4417C8ADF2E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) Date: Fri, 4 Dec 2020 10:19:35 +0100 In-Reply-To: <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> Cc: Ted Lemon , 6MAN <6man@ietf.org>, iotops@ietf.org To: Toerless Eckert References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 09:19:41 -0000 --Apple-Mail=_2629654B-2178-464A-8A6D-4417C8ADF2E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Question, what are the requirements here? >=20 > Indeed. Lets first focus on that. >=20 >> A) Stub network. Is it possible to restrict the topology to a single = root/single level of leafes? >=20 > I would fear the current business cases might be fine with such a = limitation, > but i for once would find it dissatisfactory if the protocol solution > would be limited to just one level. Right, I already gave an example where that topology fails. >> It prohibits multi-homing. What about the case where a node is = attached to the stub with a hypervisor and VMs requiring addressing? >> Is sending all traffic via the root acceptable? Instead of = short-cutting between stub routers? >>=20 >> B) Is it possible to restrict the solution to the site having been = delegated enough address space? >> Or do you need to handle the cases where the site has: >> a) not received enough /64s to number all links >> b) have only been delegated a single /64 >> c) have only a shared /64 >> d) have only a single address >=20 > Not trying to answer all these points, but: >=20 > To me the most simple model is around the following = constraints/requirements: >=20 > stub-router ----link --- infra-router >=20 > a) stub-router and infra-router are potentially different admin, aka: > we do not want to use signaling between them such as a typical > link-state-routing protocol where you can not create good = trust-domain > boundries within the topology. Dijkstra protos are a bit better, but > i think no one has tried to come up with good definitions for = "internal" > trust boundaries. Yes, I believe this was also discussed in homenet. In Ted's case as well as many others devices are controlled with = umbilical cords to other administrative domains. They should in theory not be more trusted inside the network than a host = from the outside. This is a hard one. > b) infra-router hands out prefix(es) to stub-router. It shouldn't have > anything to say about how stub-router uses them. So stub-router = could > subtend sub-prefixes as it sees fit. Infra router does NOT accept > prefixes back from stub-router. Routing is of course tightly coupled with prefix assignment. I also believe Ted's use case involves a stub network coming with it's = own ULA that it wants to advertise routing for within the rest of the = site(?). > Not sure yet about similar rules for the naming / services for DNS-SD, > but there may need to be some similar rules. >=20 > And from service provider use cases, i remember various other DHCP = options > that infra-router may need to see proxied across stubb-router to = clients > if/when clients rely on DHCP opions instead of DNS-SD to discover = specific > services. Which for example in the home a lot of the service-provider > equipment such as IPTV STBs expects to be able to do. There has to be a way of distributing configuration information (from = multiple sources). Cheers, Ole --Apple-Mail=_2629654B-2178-464A-8A6D-4417C8ADF2E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdu1h07DO3As4hPTA3JCvLd9yNkgFAl/J/ycACgkQ3JCvLd9y Nkg+Og/9H4AuONj772wcHRg5LbyV4lL21b/VpXnGVnI+JzssLgrEO+cJ0rwqe5A5 xbTeOMKXmETIWaqaMv7Fas9SVCy2EZMT4XqPnst7t4Ei2ZSEA0BvzEKhyhpJiGqx 0AHCRPMVhDnXWQb+WWMXlpO9cXmTt2HXKLx/WeYfInOMsOGhmXXPD9bGP29FeaI2 ATdM+h9kjMwp2JGjeZRLPtsSiAL5FPTUxLB6kDB8kYItlwqjT8MJYcPj8LdpBCyR 64rbY/Rx4nOex9m06fQGo94mu0aCM9z5YHwYo7X5oAQZ74EHc57m0nzDHPTrkSB5 9aoeMr4+EJ8pFdht2R0QZLRlO9bn5LzD9+JycJktGSDXzdXNFHtQREptO2TBn7qS KI8Dch6lpTYr2o9VKh/YSDYQf0/PLYUR0GOzdfTvQjKV5EQSReNvNTbhT+emuHkO 3lFDiQZA9jgkPtxp1AsKvikxbXICc0qQVoF9UvWtHCOOx4WP6eBwZH4zRaQqBTFt IGo+lgAG+J6E1pbAVa9yMZAE5EenkBWSXpWg+Z1YSftAAnnpFcH8rdPuYw54BLXE YaPMmVwKGYmUa9icKZzHFdN39uWtvqrmnFUgNLDz4KVdYfGeR+wv0POzXSX9Izq3 cQ6GnqiN4ueLYLA6fQ4qvFlwZfESPGayjSWM9NtOpjqnnPhYH3M= =VKHP -----END PGP SIGNATURE----- --Apple-Mail=_2629654B-2178-464A-8A6D-4417C8ADF2E2-- From nobody Fri Dec 4 05:42:15 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C443A0CE3; Fri, 4 Dec 2020 05:42:14 -0800 (PST) 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 fYTH-zD9LnMh; Fri, 4 Dec 2020 05:42:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F84B3A0CD9; Fri, 4 Dec 2020 05:42:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A80A389C7; Fri, 4 Dec 2020 08:44:05 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cNS1wbLMb1lQ; Fri, 4 Dec 2020 08:44:00 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C37A3389C1; Fri, 4 Dec 2020 08:44:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CBB625DE; Fri, 4 Dec 2020 08:42:04 -0500 (EST) From: Michael Richardson To: Philip Homburg cc: ipv6@ietf.org, iotops@ietf.org In-Reply-To: References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Fri, 04 Dec 2020 08:42:04 -0500 Message-ID: <17101.1607089324@localhost> Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 13:42:14 -0000 Philip Homburg wrote: > Indeed. We need to have a model where there can be a 'core network' = that > either runs HNCP/Babel in the case of homes, small business or OSPF = (or equiv) > and static configuration in the case of entrerprise. > Attached to those core routers are small trees that do not run a rou= ting > protocol, but use a hierarchical mechanism to obtain prefixes. > A core router should provide the root of each tree with as many /64s= as is > needed to number the tree. In essence, this describes ISPs today, with the customers are the "small t= rees" > We currently have a mechanisms for the hierarchical part, which is D= HCPv6 PD. > It is far from ideal, but we can try to specify how it should be dep= loyed. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Fri Dec 4 12:33:24 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C433A0FBD; Fri, 4 Dec 2020 12:33:11 -0800 (PST) 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 R0DleDaZdIc4; Fri, 4 Dec 2020 12:33:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF993A0BB1; Fri, 4 Dec 2020 12:33:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B87A7389C1; Fri, 4 Dec 2020 15:35:03 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 63B-3cV-Dm3g; Fri, 4 Dec 2020 15:35:03 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 24E9B389BE; Fri, 4 Dec 2020 15:35:03 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1A5BB1FB; Fri, 4 Dec 2020 15:33:06 -0500 (EST) From: Michael Richardson To: anima@ietf.org, acme@ietf.org, iot-onboarding@ietf.org, iotops@ietf.org, lamps@ietf.org cc: "Max Pritikin \(pritikin\)" In-Reply-To: References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <600.1585687336@localhost> <5633.1585770340@localhost> <13227.1586052088@localhost> <14837.1586479192@localhost> <23785.1605650162@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Iotops] ACME integrations with BRSKI and the cmcRA EKU X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 20:33:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Please excuse the long intro. Due to the cross-post, I want to make sure that everyone has the right cont= ext. draft-ietf-acme-integrations proposes some best practices on how to use an ACME certification authority like LetsEncrypt with an onboarding protocol like BRSKI (draft-ietf-anima-bootstrapping-keyinfra) BRSKI is based upon RFC7030 -- Enrollment over Secure Transport. (One of three methods the IETF has, including CMP and now SCEP) A "burden" of using BRSKI is that there are two (possibly private) PKIs: one run my the manufacturer, and one run by (or for) the owner. { draft-richardson-t2trg-idevid-considerations and draft-richardson-anima-masa-considerations is about the manufacturer PKI } BRSKI is essentially the authorized replacement of a device's manufacturer identity with a local identity. This protocol (and others like it) are critical to having true ownership of devices. The ACME integration document lightens some of the burden of having the operator run PKI in smaller environments. It does not remove the necessicity of having some kind of "home base" which will manage the enrollment. The converged 6tisch/BRSKI term for this is JR= C, R being for Registrar. RFC7030 defines the cmcRA EKU. The Registrar's EE certificate is supposed = to have this bit set. This is an indication that the Certification Authority has effectively authorized that Registrar as legitimate. If not for this bit, then a peer in the same CA could claim to be a Registrar, and then could (re-)enroll entities into a different CA. For the Autonomic Control Plane (ACP/ANIMA) use of BRSKI, this would be a problem, and draft-ietf-anima-autonomic-control-plane section 6.2.5 discuss= es this. The ACP determines where the edges of the domain are by looking for nodes that share the same CA. Homenet participants will remember that determining the perimiter of the (home) domain was a problem. Now, if a "public" CA is used via ACME, such as LetsEncrypt, then the edge-of-domain checks become meaningless. This is likely not a problem for many of the IoT uses of BRSKI that would benefit from draft-ietf-acme-integrations, as they don't need/want to form = an ACP. A Registrar that uses RFC8555 to talk to it's CA could have three different kinds of anchors: 1) it could use an RFC8555/ACME EE certificate that it obtained for itself. In that case, the cmcRA bit is most likely not set. 2) it could have a self-signed EE certificate, where the cmcRA bit could in fact be set. {Would it have any real meaning?} 3) it could use a raw-public-key. The RFC8366 voucher system can cope with of these three things. BRSKI does not require that the Registrar have a publically validatable EE = certificate. (nor does it forbid it) Note that MASA can in fact evaluate these things! The question whether there might be some rules that I haven't thought about. One thing that occurs to me that a pledge which *can* form an ACP, probably should *not* if the cmcRA bit is not set. Or perhaps, the MASA should do this evaluation, and should a TBD attribute in the voucher. One thought that I had was whether ACME/8555 uses like envisioned in draft-friel-acme-subdomains-03 could/should allow the entity requesting authorization for a subdomain to request an EE certificate for the apex of that zone with some bit set. Would some kind of qualified cmcRA EKU make s= ense? ofriel> Is this pretty much true for both self-signed and private-CA signed ofriel> registrar certs? The pinned-domain-cert in the voucher could be EE = or ofriel> CA cert, and in either case it=E2=80=99s the MASA that tells the pl= edge to ofriel> trust it. As long as the cert (EE or CA) is added to the trust store ofriel> of the pledge, you would need different pledge logic to check '(if = RA ofriel> cert =3D=3D self-signed then ignore cmcRA) else (if RA cert =3D=3D = EE cert ofriel> then check cmcRA) which seems clunky. ofriel> And as I believe you cannot get cmcRA from a public CA today, we ofriel> don=E2=80=99t even have the halfway house of getting the RA EE cert= manually ofriel> from a public CA with the cmcRA EKU set, but automating the bluk ofriel> pledge certs via ACME. ofriel> Seems like mixing two sort of orthogonal things - subdomains and cm= cRA.. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/KnQEACgkQgItw+93Q 3WWXTAgAlAdLbiv9v1n5bKgPlzL9YAaWTC3lJbgx+YvwCOwSeTblWrUAxwAYGoiT PWdFFJ8DQztdWJpbyKRkxsFNd4iAuTSMSNpaWI5xSclFaPZ28r5Q2EzVOs8Rmndm XgfsyDXCKCisJTGISssdcE/zXQBOsWR52vwq1xanJqOguNeVIp1Qe/kkibVe7/Zq +bKDWIXTGTmdhANquUdZhxL37EcHahHLaLI+7m1Mbz03D0Onvjo+ivDx5GNnxaom VomREgDpsz/3PcJneOdoQtL9/qT+Iybq076gUC6bnzlzv/6HhmrP9lKFJB75BUpZ EExBkc7Pd+7YdJPVuK87XyVd1BtWmA== =4S9S -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 4 13:19:49 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DA43A0FD7 for ; Fri, 4 Dec 2020 13:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 t6cravDtCyUb for ; Fri, 4 Dec 2020 13:19:41 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 C36803A0FD8 for ; Fri, 4 Dec 2020 13:19:41 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id u21so5002778qtw.11 for ; Fri, 04 Dec 2020 13:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T3qWtqgdYZV+Xv/1XuhVu8OdoTRZDJky3CNd57ev/kk=; b=JghT2+Spb1j13Xw8K6tukXOyd2SdVKJ0EuPx1Hv0rtNAnUZ6c1LRlTXniuxHOHmItV hXUxqsRfL86GnK/VjLv7HO00L8R9h9yglk9s0/FXE4GikGmejYQmJ9NX6k5ODpk7Xda7 2s4hBtUw4uKg5T6Ln676zbVjh4wd0wEkAXcgGkKhf0rrIQGCifaxMygOSffvhPY2YpLn jKGPJcFwnT2IhzhSquR0QHf/AJPqdSXzFZGSewT4yJxF0FT7PJ57fo9SP0vnhSza0ufS m82EXFCg4jJdZOwGJBn8d6/8b5UqfImNvk/BPybrAEn4L8EAVfGj4cQC2wunNYcRtiTD P3xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T3qWtqgdYZV+Xv/1XuhVu8OdoTRZDJky3CNd57ev/kk=; b=J2+TY1dBd2Bkakszdhb+mqHq8zRxtSZY3l9a0HkGEt92+piex52UEIhCRsSLt95Fio V7UQRPRWvw394UVgwts+MTz2Fg5/XplRgqHlwMamn7/PkTD7mjMFb82x3G0jNK0TgewS GnAH7pe1/aU1+tfAZHSfOEWfPCkgRdtSq/uPGag4f0l+13qflO5nho1waRUP9cukw0NS aOYcMqeHiXrK+xTrv/nrbTftB3Uk5TEUGai1m+Ba07JAKNwPiG7sn5E40OXEmVbCapmW 7ALXKWGFXHhd9BhOLPnPXH6XU9Ylamgd5HT3raTnJzG9uB+O5KtA4zuAj+MSi11tVQJ+ 9aCw== X-Gm-Message-State: AOAM531UU1EA+lxXqV6AkBOU0RVgpJ7ogRxEH28u3Lv5NevoRMOQbgPZ W+MxAtduGBTtqazts6mn+qs3Aw== X-Google-Smtp-Source: ABdhPJzrg5gtPqvk27l3cX/DOSZdtWKzalcUTAMNiMwlzxn7Qq/LpDDSYVk3AOfjBN/FBSLukYebXQ== X-Received: by 2002:a05:622a:303:: with SMTP id q3mr11339175qtw.24.1607116780361; Fri, 04 Dec 2020 13:19:40 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id g70sm6182144qke.8.2020.12.04.13.19.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 13:19:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Ted Lemon In-Reply-To: Date: Fri, 4 Dec 2020 16:19:37 -0500 Cc: Toerless Eckert , 6MAN <6man@ietf.org>, iotops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1B0BE9D0-5428-4E6E-B1DC-AA8FA6BA4256@fugue.com> References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> To: Ole Troan X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 21:19:44 -0000 On Dec 4, 2020, at 3:19 AM, otroan@employees.org wrote: > Let's me see if I can dissect Ted's arguments against HNCMP in = https://tools.ietf.org/html/draft-lemon-stub-networks-ps-00#section-1.3, = and if restricting the problem to only allowing stub routers to be = connected to a single router helps. (A topology with a single root = router and a single level of branches). >=20 > 1) HNCP only works if all routers in the AS runs it. It's a routing = protocol so that's not surprising. > Solutions would have to either participate in routing and a prefix = assignment protocol. > The degenerate case for routing is default route upstream and a static = route for the assigned prefix downstream. > All traffic to sieblings would go via root router. HNCP is not a routing protocol. Babel is a routing protocol. HNCP is a = mesh discovery protocol. It has a lot in common with routing protocols, = but it=E2=80=99s really its own beast. For the stub network case, HNCP simply isn=E2=80=99t necessary. I think = the disconnect with HNCP is that it is aimed at a problem nobody wants = to solve. The stub network problem is a problem that we wanted to solve = enough that we spent two years working on it. HNCP was a choice we = considered, but it simply wasn=E2=80=99t an option. I guess if you want = routable IPv4, HNCP would help with that for the stub network case, but = I don=E2=80=99t find this compelling=E2=80=94IPv6 works fine. > Ted also mentions that HNCP does not deal with the case where only a = /64 has been delegated to the site. > In homenet we did a conscious choice of requiring a site to get enough = addressing to get a /64 for each link. > I do know that the implementation in OpenWRT does support a single /64 = (it subnets into /80s and does DHCP address assignment). > How to deal with a case of not enough addresses assigned is not a = problem unique to HNCP though. The point of saying that is that we need some way to do outbound = connectivity in this case. Our solution to this problem is to use NAT64. = Hopefully as v6only deployments happen, service providers will get real = about assigning narrower prefixes. > The degenerate case for addressing is: > a) Split up a /64 in pools of addresses for DHCP > b) If less than a /64 (e.g. already shared) then NAT No point in doing NAT66 when you can do NAT64. > 2) HNCP is too complex and does too much and is not implemented. > Not enough details to make any arguments for or against this one. > If one standard isn't deployed and implemented is a weak argument for = inventing a new protocol and standardising that, that's neither = specified, implemented nor deployed. =46rom my perspective, needing to ship a product that will work on real = networks, and not rely on imaginary networks, the fact that there are no = implementations and none coming meant that we simply couldn=E2=80=99t = use HNCP, even though because of my time in the Homenet WG I was = personally predisposed to do so and spent quite a bit of time evaluating = it as a solution before abandoning it. > Question, what are the requirements here? >=20 > A) Stub network. Is it possible to restrict the topology to a single = root/single level of leafes? > It prohibits multi-homing. What about the case where a node is = attached to the stub with a hypervisor and VMs requiring addressing? > Is sending all traffic via the root acceptable? Instead of = short-cutting between stub routers? I see no reason to do this. > B) Is it possible to restrict the solution to the site having been = delegated enough address space? > Or do you need to handle the cases where the site has: > a) not received enough /64s to number all links > b) have only been delegated a single /64 > c) have only a shared /64 > d) have only a single address Our solution works in all of these cases except the v6-only /64-only = case. (I say our solution meaning what we did in the HomePod Mini and the open = source Thread border router=E2=80=94we don=E2=80=99t have a = specification yet, and didn=E2=80=99t actually do any protocol work.) From nobody Fri Dec 4 13:22:55 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC423A0FD8 for ; Fri, 4 Dec 2020 13:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 eg-bPr88oqZs for ; Fri, 4 Dec 2020 13:22:51 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 BAAA63A0D70 for ; Fri, 4 Dec 2020 13:22:51 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id v11so4995643qtq.12 for ; Fri, 04 Dec 2020 13:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HvjMG1ENi8j0TKptL/7qlPm6ACOwbTVQR8DiNmCkRks=; b=kyXKafaxbLDqgdEqRdQLmoV20/9g5n4fqdHwiTZG8iy+oEdXRjZqoLUtWxT7F9KdWh L3TinkKTyKCIfS3dyE0FQlf/HYSKSb7P7wPUPbk1yckpAz6EdCK23jQEpvTG4J+28cQw 2DpLXhyjPHyfSaCY1HHBVQWVCvpHh16OyUjPGMXnnS5UPAzFNrRc8+D2s6AQzxIwqbv6 g2probvGTasmh+nHNK3HJ0cs3b2I4AwKo9MrvuRZ46+G/PXLBoayb8NQPxGS9zdDOYsP uWRMUklWx/4NSqbGJiiBkikQS4Ubi9tA+KmDc9mY9Hti/aTHD00r+/4g09VUNad2zNi3 zn0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HvjMG1ENi8j0TKptL/7qlPm6ACOwbTVQR8DiNmCkRks=; b=PVIy1sGfUabNzaZqh0zBL8e5BsF/DatAdpjY/y8wWhpTEHgYuY/gpKwdA6s7tdc00X 7lCQCsN5RNhX9t54rcndb/v0On5aucws8XWEzj2Xu2XyWRmz2qXtI1cxBgX4KcEeV+Q/ T3qWlAXHQEFxAPXiTCyziKB3G42hS1LmF0NrH5V0DIS5xkUnhVyQKA1q22M7VXJUHgEZ 2xmKUeTQHsK/etvI/XpvfnJAldpnjK95vh/e6mUy0AWBGXw5gz+MivgGmEPjmOFj7w96 ee/4DsGZ8ptUSMwIQ0aTngtXZ/J4xlD98M08TWwzYis/IwsfNkads0ooJ47U+DNaSew8 O+6Q== X-Gm-Message-State: AOAM5323SAVVyf9l6fVc/3yPNrendDh9FPtCWYj0TMrAVdVHij8NYD83 zrCsCvWRuAw2ro+UxgxXL0OmtiF9U1ngZTKJ X-Google-Smtp-Source: ABdhPJwpYRZsXqSw8SKnN65TBEDW4pXpOTbG4UF7FwlgxCFgJBifjaPaHIzoh1yLwnV6IL5SEE2o9g== X-Received: by 2002:ac8:545a:: with SMTP id d26mr11721303qtq.390.1607116970668; Fri, 04 Dec 2020 13:22:50 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 13sm6238987qkp.16.2020.12.04.13.22.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 13:22:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Ted Lemon In-Reply-To: <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> Date: Fri, 4 Dec 2020 16:22:48 -0500 Cc: Ole Troan , 6MAN <6man@ietf.org>, iotops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1ABBA0B7-AEAA-4018-A113-365C9B77306F@fugue.com> References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 21:22:53 -0000 On Dec 4, 2020, at 3:57 AM, Toerless Eckert wrote: > I would fear the current business cases might be fine with such a = limitation, > but i for once would find it dissatisfactory if the protocol solution > would be limited to just one level. There isn=E2=80=99t really any new protocol work required. >=20 >> It prohibits multi-homing. What about the case where a node is = attached to the stub with a hypervisor and VMs requiring addressing? >> Is sending all traffic via the root acceptable? Instead of = short-cutting between stub routers? >>=20 >> B) Is it possible to restrict the solution to the site having been = delegated enough address space? >> Or do you need to handle the cases where the site has: >> a) not received enough /64s to number all links >> b) have only been delegated a single /64 >> c) have only a shared /64 >> d) have only a single address >=20 > Not trying to answer all these points, but: >=20 > To me the most simple model is around the following = constraints/requirements: >=20 > stub-router ----link --- infra-router >=20 > a) stub-router and infra-router are potentially different admin, aka: > we do not want to use signaling between them such as a typical > link-state-routing protocol where you can not create good = trust-domain > boundries within the topology. Dijkstra protos are a bit better, but > i think no one has tried to come up with good definitions for = "internal" > trust boundaries. >=20 > b) infra-router hands out prefix(es) to stub-router. It shouldn't have > anything to say about how stub-router uses them. So stub-router = could > subtend sub-prefixes as it sees fit. Infra router does NOT accept > prefixes back from stub-router.=20 >=20 > Not sure yet about similar rules for the naming / services for DNS-SD, > but there may need to be some similar rules. >=20 > And from service provider use cases, i remember various other DHCP = options > that infra-router may need to see proxied across stubb-router to = clients > if/when clients rely on DHCP opions instead of DNS-SD to discover = specific > services. Which for example in the home a lot of the service-provider > equipment such as IPTV STBs expects to be able to do. Does anybody actually do that? I ask because I don=E2=80=99t know of any = routers that support it. I guess some ISPs do custom routers and don=E2=80= =99t let the customer choose? Anyway, best is the enemy of good enough. We already have a solution for = the self-configuring mesh; if that=E2=80=99s what we want, HNCP is our = best option at present. There=E2=80=99s no need to do additional = protocol work here. From nobody Fri Dec 4 13:27:38 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEFF3A0CD8 for ; Fri, 4 Dec 2020 13:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 94t1Dberwupr for ; Fri, 4 Dec 2020 13:27:35 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 47ECB3A0C17 for ; Fri, 4 Dec 2020 13:27:35 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id z188so6875374qke.9 for ; Fri, 04 Dec 2020 13:27:35 -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=VNvcFvBKhtQxoq7eOZlAOn4ltVkrsZPVsZB1zY8vNFM=; b=WCj/eWiuW8Uu0S16ABsG7sEcnpYv23HcV0yAzMAYxCguHDB11LfDvvId09OBFz9Dkc DNzJTixWbop6TlYLkrKKZdCqRTKtsCIjYU32iZjfixd5RLV7THDTyzcJek340Y36Uy0b SRXiEWRCrj5C+4xjHSrnvpxchB/qV8Jak305qiF5Yk+GyIz9iqMnTTMP6CEIycyXKtDA MK6j+ngCBK/NbwkTG0TErCkuR/Jbk2KSWbsRsBI4dINFH/IuPsxx3mD/1vF/b3MTUSQm ry5INzveK1zhkXjHu9YlTnmJFcXbqDozr4nYAzLAjbQ9+NYtppIUtfQTdt7rPiWQQ1R/ /ntQ== 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=VNvcFvBKhtQxoq7eOZlAOn4ltVkrsZPVsZB1zY8vNFM=; b=Oly6v9Lc0tUxrRPsspxAiP9c5MvH0u9R+DqatjCQhRtBsohGr2o7ffpPY11vf9GQP5 n4mQZlxwaZEllt+nQh4zvIbQisflGlKoQ7AJboO/BhbfxWvcPby+NX5WuE0j632s1SMN LszV4M7SV4ePlD8T1vAfbyFMw/9H07ATXnY8TMMBvRu8jV128FWTjXJqM+hm72w8cxN8 OFoASrFAMFBC0mSnruGXOH9rtFmqUXXsLrfziPswmqBvIHRTbeIUCUdA4Weik56RptHX qVt6SvA3tKzBLzu1hQVSZRAsyjgJ2pDEDcnn+BEvOhr+lkMBqGNjNSTCBJvyhgbFao5Q w4AA== X-Gm-Message-State: AOAM531+BxywqKpEvHzV3BTf63pTKyUjEuNZqDIKDYsXm7o877chhdC5 xsFuXKQTIl8AwHvJ2zC2lM2Mhg== X-Google-Smtp-Source: ABdhPJxWBgk/JJHOAAjIh5FVYVjCBcTyYI1TiZ0ucJm0dJyvN4cvocIQmHiC+FkiPyArsvz1piyAew== X-Received: by 2002:a37:6892:: with SMTP id d140mr11734812qkc.200.1607117254148; Fri, 04 Dec 2020 13:27:34 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o13sm5758814qkm.78.2020.12.04.13.27.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 13:27:33 -0800 (PST) From: Ted Lemon Message-Id: <25EB2B8B-2C16-4E79-9BC1-2654634FBD68@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8910F496-728F-4A0B-B3B3-05BE8170D1A7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 4 Dec 2020 16:27:30 -0500 In-Reply-To: <784BB35E-D9A3-413B-912D-46D12CCB34B8@employees.org> Cc: Toerless Eckert , 6MAN <6man@ietf.org>, iotops@ietf.org To: Ole Troan References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> <784BB35E-D9A3-413B-912D-46D12CCB34B8@employees.org> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 21:27:37 -0000 --Apple-Mail=_8910F496-728F-4A0B-B3B3-05BE8170D1A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 4, 2020, at 4:19 AM, otroan@employees.org wrote: > Yes, I believe this was also discussed in homenet. > In Ted's case as well as many others devices are controlled with = umbilical cords to other administrative domains. > They should in theory not be more trusted inside the network than a = host from the outside. > This is a hard one. I think generally for IoT devices controlled by the cloud reach out to = the cloud rather than the cloud reaching in. I think James Woodyatt = years ago said that Nest did this with an IPv6 tunnel, but in any case I = think these are provider-specific solutions and not really something the = IETF needs to work on. My goal in documenting our stub router solution is (1) so that people = can point out issues they see with what we=E2=80=99ve done. Real issues, = please. And (2) because it can serve as a base specification that = various specific documents can reference. I think it has general = utility, although my current use case is 802.15.4 mesh (Thread). --Apple-Mail=_8910F496-728F-4A0B-B3B3-05BE8170D1A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 4, 2020, at 4:19 AM, otroan@employees.org wrote:
Yes, I believe this was also discussed in homenet.
In Ted's case = as well as many others devices are controlled with umbilical cords to = other administrative domains.
They should in theory not be more trusted inside the network = than a host from the outside.
This is a hard one.

I think generally for IoT devices controlled = by the cloud reach out to the cloud rather than the cloud reaching in. I = think James Woodyatt years ago said that Nest did this with an IPv6 = tunnel, but in any case I think these are provider-specific solutions = and not really something the IETF needs to work on.

My goal in documenting = our stub router solution is (1) so that people can point out issues they = see with what we=E2=80=99ve done. Real issues, please. And (2) because = it can serve as a base specification that various specific documents can = reference. I think it has general utility, although my current use case = is 802.15.4 mesh (Thread).

= --Apple-Mail=_8910F496-728F-4A0B-B3B3-05BE8170D1A7-- From nobody Fri Dec 4 14:04:44 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95F3A1033; Fri, 4 Dec 2020 14:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 726h4QYH3ws8; Fri, 4 Dec 2020 14:04:30 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 C4D773A1028; Fri, 4 Dec 2020 14:04:30 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0B4Lsmtj018856; Fri, 4 Dec 2020 17:04:28 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 3574ynaxp5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Dec 2020 17:04:28 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0B4M4RCq030071; Fri, 4 Dec 2020 17:04:27 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0B4M4IMu029861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Dec 2020 17:04:19 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id F0DE44016D83; Fri, 4 Dec 2020 22:04:18 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (unknown [135.50.89.109]) by zlp30487.vci.att.com (Service) with ESMTPS id DB0F94016D81; Fri, 4 Dec 2020 22:04:18 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 4 Dec 2020 17:04:18 -0500 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Fri, 4 Dec 2020 17:04:18 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.100) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Fri, 4 Dec 2020 17:03:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WJuz2AVRMqkevGkXHzDukXIgDQOtR6cwQhyMvnTrN3RTWypQYfx2Yf5tUKHY4+144EG23Yq4EjvwsXX+lURKYfRxindSVptQJRqXg+6hN92ziNEjcYKh2oPI9NpJ2Mf1m4Lkjg9W+LdMbaEkfuiFI1oFLUmLgxPbB4ji9cKm6J2vHaa2Nwor1YhSVRNFqy7OowtdV6WzEnF3ie/Vt0ItNfHY7O83IfnPjSDXO4RuW0NfuhOgUzZMB6RDih5kwSxwxO5new2zLYVsTtQey/TcY5tKRIbkUsBoWePzEl1F/0iM1s8fOJgcSaSi3FFemU5uQbXAcFWFY3ttapy5blYEHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MumUpURzYnx/O2eMZiO/TVJwuUI8JaE663t7IJU95Qg=; b=BIuxA8M5fegR6K7XIzXD2o0UV1KIERVlmGRcRmQkQHBC8pta2dNS/2kT7Hia4vOWj71EkA3iZM0Bmcrs8kWDZ41l3dGThrBmd1YIu87wG3ySRCAxIzmclcyX3Ql/5TjlnTz/BRSbQ3WmtNwT0UWvVmBaaiGO8FINTqK/WCz3T6Xt/RmqwyN9lVLu5NC1YZW1xHNONGsm8LdFWW1DqInttCHmldD9sZmcl3PR+wqHVC81aTFweAOUqCo16B/okw/AswpTPimUrwzxDtFaLSmsDM83R7SRLwqRZpxcgaLxv20PQMW6/Zulglwe1Q/V1iU38LAZFVnjq65xcXqDGwaZow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MumUpURzYnx/O2eMZiO/TVJwuUI8JaE663t7IJU95Qg=; b=aE9hFo/6l7CHsbGA4nuvnrcmwMVeI+65DQoBQTpSavYdecCQdG1mVsRKW8YZEjU1V6f2Aykii0yNg7r4/48dWOVIvgwcawIvGZJMohXEtA02OfLdsQOYTRmkpU4PvTDEseVBksnx1rW/MHkSA0HD4zr6kGRKk2VXjnCnr/hd6W0= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB4078.namprd02.prod.outlook.com (2603:10b6:805:37::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.25; Fri, 4 Dec 2020 22:03:21 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::1813:2439:6aac:fc24]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::1813:2439:6aac:fc24%6]) with mapi id 15.20.3632.021; Fri, 4 Dec 2020 22:03:21 +0000 From: "STARK, BARBARA H" To: "'Michael Richardson'" , "'Ted Lemon'" CC: "'6MAN'" <6man@ietf.org>, "'iotops@ietf.org'" Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AQHWVoL2onAqMYjZtUCg6orRClX9iqnlM6QAgAAjxICAAAUtAIAAAW0AgAEuIoCAABGYgIAABKOAgABH+ACAARHYwA== Date: Fri, 4 Dec 2020 22:03:21 +0000 Message-ID: References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> <4424.1607037970@localhost> In-Reply-To: <4424.1607037970@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66a04160-75d8-4d69-e07b-08d898a06a32 x-ms-traffictypediagnostic: SN6PR02MB4078: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H9V3IpHWTiarj7a+CjypUNbaQ5dOHjNwLeGblmNxHtAhwUk3XXKNsc55mvUOz7l2J2RHtyU+SJpsULjsjJyocs2Lj1tyHSbD2VcOBOM6II7AVARd8xQ4YgwJCiUybtXGQ1htEaW9yrV3pDmPngmPnpwSPXLcYUAcD6M7jlHJ9NEZvf2iLAU6HpXcN6BTjB15UbQiDXFEz+oylsSQ1VnuHB15ThHyzVrqZQDrf+qZVx3OGI7af9vEesULUjljZo3Fpkc8kEkYFAsz+skz1GuVKQSq1qNGa4lWV/sH2pCAEEZsF5Rw1t1/pfcHC88vue7syADDgZgf0HV1dPTWtaZn3A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(396003)(346002)(376002)(66946007)(66446008)(6506007)(82202003)(4326008)(66476007)(54906003)(110136005)(5660300002)(55016002)(66556008)(9686003)(64756008)(26005)(33656002)(76116006)(316002)(186003)(71200400001)(8676002)(2906002)(4744005)(86362001)(478600001)(8936002)(52536014)(66574015)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q3lyVnBsWFkxa1FQQlFRd21ieDI4MmZRWDZlbjFBMy80TDhXU2Z3cG9QR29m?= =?utf-8?B?UUZkbmNFMURScjBmRGlVREN5RjBvQ003NDBCUEp2Rjl5d0kxbTloODNyMEQ5?= =?utf-8?B?TkF6UXVHVUxkajFkV2I5cWtuaWdEVnFISC9CaTNISkp0TkZCa0cyL0NWbE11?= =?utf-8?B?UFZhL2JPRGxuVzRZSHpzZUNpNUxlNzU5QlFGa2RNRDQyWmxBRlp5L3hzUm9s?= =?utf-8?B?R0F3c25NZVlLRE02bmtMMzc3S2lTaE5PS0M1TnFLR2E0TjVFRkZXMjZkWmNu?= =?utf-8?B?RlVlRHViak1GZUhxdHRpaUYrZGkvdlBzS3Y1K09Wam54akFBQWJpZVpVNkZX?= =?utf-8?B?cUpYM3crdWhxaml5azgweXpYV0hza0ZlRnd6U0NMZEUzSHZVeXdTa0hmRUZX?= =?utf-8?B?RUZEMjJ6SmVBU0p3dEYrdUpkMGNVNExoZFVVY3lNRWVqcFlQQS9Lam1VOGUr?= =?utf-8?B?b2p0eGZGZmFPaDlkWkx1MnljRU9QUEV4SjdnakZtUUVyL04xeUZZbjIvNVY5?= =?utf-8?B?VTVyaFY0Y0FjVTBGSmJuWGVGMW82MXVDSWxNbWFaWk1leDloSWxuQjNWVlpP?= =?utf-8?B?c2xlcWdhUlQ1dzd2dy9vY09nR0FqSnpyNFZlcFIwK1ZTOTJuQW5ZUGRrMWdS?= =?utf-8?B?Zzg3V1E1MHVSUXpLTmNlWlhVcHpWVS9tUEVOUTNaSkxndS9KcWlQOWhGWDNy?= =?utf-8?B?UndzZGNXZzhJTXVFTGtNZTJQSGVIQ3poV2ZITHUrWGJKQXlCSHNZcWxjbWU2?= =?utf-8?B?U0JYb0hNZGttSW40MHNacWFxbk1RS1BQWFJzSVgrV085My9BdExuOEdMaEZ5?= =?utf-8?B?S3NOUXZmaDNKRk5ORGJtTXFKWlpEQm92c0FWUUxkK1VROHB3eE9PWkw0b2Nq?= =?utf-8?B?WUZhSXdwMHlnc3JRaG8wQzZaZnJCcjMzWEdFS0ljaEhFT3lnK1lrUlc2dnpT?= =?utf-8?B?Z0tkdzhaRmhIWlRFL21oQ1ZjYVhVU0JOWHVhR3J5dEovN3JBZ2w4NmpOZFUz?= =?utf-8?B?VE5SY2w3SVczeUlyeGF5NXhYajhaNVBPY01wQnRVOVZmdWdldksxd3I3WVM5?= =?utf-8?B?dk1mbWtNZzBrSkUwNFFxYVJKdjd1RDRQL0tTVEdZMFVPcnlvUnNXUUhiVStX?= =?utf-8?B?RzlvcndJR2c0cjY3RUZWR3ZPNkNxdVN1bll3cXUvYitXWFJyMGdtNEFrODVh?= =?utf-8?B?VkNkWm51RG5lUll5Rk5NZFpmZU5Ib2N1T051aUtnSDZaL1lock9IRU9wVUNI?= =?utf-8?B?Q2hGU3Frc0p4ZzV6WnVqREJHWU1FYmpCNjllWG1tSld1YUJrUTdLbWpSZE53?= =?utf-8?Q?S/xAv1SUbc0Xc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66a04160-75d8-4d69-e07b-08d898a06a32 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 22:03:21.5684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BEIQoBJSaejFFBFmyHrU3FAl6egeXzia7zZJeWgStkiaQ+ADv3RFUyh7CuYMX6IV X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4078 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: B7833DDE331E7BA6DF2AA69F4899C9CB9EBE56088123445095B0E5E612ADC4892 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-04_12:2020-12-04, 2020-12-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 mlxscore=0 impostorscore=0 mlxlogscore=685 spamscore=0 adultscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 malwarescore=0 bulkscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012040123 Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 22:04:39 -0000 PiAgICAgPiBJZiB3ZSB3ZXJlIHRvIHN0YWNrIFBELCB0aGF0IHdvdWxkIG5vdCBiZSBhIHN0dWIg bmV0d29yaywgYWx0aG91Z2ggSQ0KPiAgICAgPiB0aGluayBpdOKAmXMgYW4gaW50ZXJlc3Rpbmcg aW5jcmVtZW50Lg0KPiANCj4gSSB0aGluayB0aGF0IHdlIG11c3QgYmUgdGFsa2luZyBwYXN0IGVh Y2hvdGhlci4NCj4gDQo+IDEpIERIQ1B2Ni1QRCB4IDE6IGhvbWUtcm91dGVyIHRvIElTUC4NCj4g MikgREhDUHY2LVBEIHggMjogc3R1Yi1yb3V0ZXIgdG8gaG9tZS1yb3V0ZXIuDQo+IA0KPiBCZWhp bmQgdGhlIHN0dWItcm91dGVyIHRoZXJlIHdvdWxkIGJlIG5vIERIQ1B2Ni1QRCwganVzdCBSUEwg b3IgWmlnYmVlIG9yDQo+IFRocmVhZCwgb3Igd2hhdGV2ZXIuDQo+IA0KPiBCdXQsIG5vIGN1cnJl bnQgaG9tZSByb3V0ZXJzIHN1cHBvcnQgKDIpLCBzbyBpdCB3b24ndCB3b3JrLg0KDQo/Pw0KUGxl bnR5IG9mIElTUCBob21lIHJvdXRlcnMgc3VwcG9ydCAoMikuIEkga25vdyBBVCZUJ3MgZG9lcy4N CkNhYmxlTGFicyBoYWQgdHJpZWQgdG8gcHVzaCBmb3Igc29tZSBzdGFuZGFyZGl6ZWQgYmVoYXZp b3IgYXJvdW5kDQp0aGlzIGluIGhvbWVuZXQgKHdoaWNoLCBJTU8sIHdhcyBvdmVybHkgY29tcGxl eCBpbiB3aGF0IGl0IHdhcyBkb2luZy4gDQpCdXQgdGhlcmUgd2Fzbid0IGVub3VnaCBpbnRlcmVz dCAtLSBldmVyeW9uZSB3YXMNCmZvY3VzZWQgb24gSE5DUCBvciBidXN0Lg0KQmFyYmFyYQ0K From nobody Fri Dec 4 15:13:01 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528F33A101A; Fri, 4 Dec 2020 15:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 wApcumCSk41I; Fri, 4 Dec 2020 15:12:54 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 6FFE83A1018; Fri, 4 Dec 2020 15:12:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B4NCowa026384; Fri, 4 Dec 2020 18:12:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607123572; bh=xZHqv06S3KSQ4gyN6nBu7wCj80ES4UwJ2afSYbL5ghI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mpR5oe/+y04+eX7X/X9JYlaBzkDjKz1QRASTh4LCIvgTztclvT0K6AF77epgT6Nh8 FSFbKnJyK2W3+mvE0v1TIN+PgbPp/+jTZnhVPJBFkzIxcYIcU+ANzQ1Q2dltzZXTpS ksl6s/Fvc65wev5nCBVv+re0TajpwTPm9+PErMw9OO+T7rEeSlrDaR6Z6QBECNgs58 6uD+X6wvAg8q20r/f0B+OZrd1SMQfm6RA8K/YUFEI4MRUikAnTninI/qDdJWpfa913 LsRdTp0JEnCkI8PkcciJGZRcnNQK7jmNZ4+0O4ny/M1OKVbYQq+FLAoykrdRa6hKti grV1zyZ2OaFRg== Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B4NCd4U026298 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 Dec 2020 18:12:39 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 4 Dec 2020 15:12:38 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 4 Dec 2020 15:12:38 -0800 From: "Templin (US), Fred L" To: "STARK, BARBARA H" , "'Michael Richardson'" , "'Ted Lemon'" , =?utf-8?B?T2xlIFRyw7hhbg==?= CC: "'6MAN'" <6man@ietf.org>, "'iotops@ietf.org'" Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AQHWVoL2onAqMYjZtUCg6orRClX9iqnlM6QAgAAjxICAAAUtAIAAAW0AgAEuIoCAABGYgIAABKOAgABH+ACAARHYwIAAfCYw Date: Fri, 4 Dec 2020 23:12:38 +0000 Message-ID: References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> <4424.1607037970@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 6E48CB6E794390C2D4F91164995452770E8CCF2011CC6F819256F80B9B9D99B12000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 23:12:55 -0000 REhDUHY2LVBEIGZhbnMsIHBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGUgbGF0ZXN0IE9NTkkgZHJh ZnQgYW5kIHNlZSBpZiBpdCBwcm92aWRlcw0KdGhlIGtpbmQgb2YgcHJlZml4IGRlbGVnYXRpb24g c2VydmljZXMgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGZvciBzdHViIG5ldHdvcmtzOg0KDQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLTZtYW4tb21uaS1pbnRl cmZhY2UvDQoNClRoYW5rcyAtIEZyZWQNCg== From nobody Fri Dec 4 15:15:33 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898293A102C for ; Fri, 4 Dec 2020 15:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 Tr8XkHQpCtWV for ; Fri, 4 Dec 2020 15:15:30 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 CFBD43A102A for ; Fri, 4 Dec 2020 15:15:29 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id d9so7119711qke.8 for ; Fri, 04 Dec 2020 15:15:29 -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=Sl0sz2iBDOcQ3alq/WtsP+hr0blpvleiNOLUTr4hy6k=; b=UKQdybTmloRXFcSjktPOcDhBndojJUVOIzsphED4bBBQuXYYvU3eAS0qMuIdANtr+2 QWuTzDM8OgnQQ7ZgJcphQ2lM3JZww33c/MFatVdWla4F+Gm8mK0Om0dqFWIaNxux4fSa hliEs0kO6Wq81seUjkGtHBTArtZLRQJ/GATV1gh9Lat0mBuQwJLL9GmcfwpNckETCr3T LnQ9aemyZZIm0txNCnuPOElDMf8k0mj+1Bws+Gk8u1P+QGjc3bP2KLbPMYBRcq2qvQ+y C3Z7HJUow0Mrom/YYPQldDK4jUn83occmpnasJWGoZoH3UumgLcYFXnFVXewA6V4N65M YxiA== 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=Sl0sz2iBDOcQ3alq/WtsP+hr0blpvleiNOLUTr4hy6k=; b=K2sAH0nMABKK2o6RMaeihiyU+ueyE9ATQdqnr6mvZ8nbVprqKRQqAuEEF3Nfqv+cW6 hdP6Bp7rlS/91Q0duINyWvZugw+2VNO3thOlatYxVQb3Lg7RmL4cUtmzViOMpvh/nU9+ vIuT+z1o25lw1Z35hdTZ6AF7nk2DloM3DtgnMjKJSr0yp/L+ciClUZQNWJqbtamAxEeH spT5gGcraHh5yvRV0ICuZRFmXGMV5UYUY/XrrpTJ2D6yyUZHt7wTb8MFv1lLQl8SXA/x JqRbm0caduKMCllMnsdQzseHuy8u42kDK/2I6DXj4hjSIM+TrEhgIydYtuzx/XjYod07 +SUw== X-Gm-Message-State: AOAM533TZbPRwiR/jtxNz1bjOBsifBL4GqcCsqgsdAq+Nx4Db////dcG iMKOjPU+YfVoJmZfqqhn/jJPVg== X-Google-Smtp-Source: ABdhPJxGaXa509m53ut5xQH2yQYChVnK4SrDhG7BHBVA2/Boj2EtDa00Ej4rGU1IyT8x5soSP/caNg== X-Received: by 2002:a37:9d04:: with SMTP id g4mr11765211qke.358.1607123728574; Fri, 04 Dec 2020 15:15:28 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id s30sm2516152qte.44.2020.12.04.15.15.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 15:15:27 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A798F95C-F61E-4225-A951-E6649532E380" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 4 Dec 2020 18:15:24 -0500 In-Reply-To: Cc: "STARK, BARBARA H" , Michael Richardson , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" To: "Templin (US), Fred L" References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> <4424.1607037970@localhost> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 23:15:32 -0000 --Apple-Mail=_A798F95C-F61E-4225-A951-E6649532E380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 4, 2020, at 6:12 PM, Templin (US), Fred L = wrote: > DHCPv6-PD fans, please have a look at the latest OMNI draft and see if = it provides > the kind of prefix delegation services you would like to see for stub = networks: If you are extending DHCPv6-PD for OMNI, you should really do it as a = separate document. OMNI is rather large, so making references to it = isn=E2=80=99t ideal. The only thing we need that isn=E2=80=99t specified anywhere is for the = infrastructure router to add the prefix and destination to the routing = infrastructure. --Apple-Mail=_A798F95C-F61E-4225-A951-E6649532E380 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 4, 2020, at 6:12 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
DHCPv6-PD fans, please have a look at the latest OMNI draft = and see if it provides
the kind of prefix delegation services you would like to see = for stub networks:

If you are extending DHCPv6-PD for OMNI, you = should really do it as a separate document. OMNI is rather large, so = making references to it isn=E2=80=99t ideal.

The only thing we need that isn=E2=80=99t= specified anywhere is for the infrastructure router to add the prefix = and destination to the routing infrastructure.

= --Apple-Mail=_A798F95C-F61E-4225-A951-E6649532E380-- From nobody Fri Dec 4 16:46:51 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F3E3A1115; Fri, 4 Dec 2020 16:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 OftPQzpDHjbj; Fri, 4 Dec 2020 16:46:47 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 957593A110F; Fri, 4 Dec 2020 16:46:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B50kYnl007301; Fri, 4 Dec 2020 19:46:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607129204; bh=UDDqe1UP3HAuB+tBIFPtUu51xRqhr6SyjRW0dlq53NM=; h=From:To:CC:Subject:Date:From; b=dA3RUoUbNXSmCqHMEoxUAYxoEF9O1FHwihS8PXDLVhJzifV0DY2jRW8XjBOFFD9sd DhEyq/Fx78wbtQC4nTsRDzkZPHbE2/88aA3MDZHE7wxNBY3EfBDzaVWiCK7kcli07B zdLoWi7EsnYHTieaQ5nUaLdQxlIeqnBpqm5VsLyIvKLWBSBoIrHo0e2WuTRzRJi2kx sgkt8VD/S99FHeQofhKsJCB/Ss6p1R0iVf130RV9Epq5zwGHQc1UiGrPU+IR0aSIqF vdX+ZbWK5RlDMP/aYXr13Y7bE0O9U4Jj7yLVWB/Pj1379UpbaOxg+q0bQp4di8pjEg JmbeDIotJK9Ng== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B50kUPo007282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 Dec 2020 19:46:30 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 4 Dec 2020 16:46:29 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 4 Dec 2020 16:46:29 -0800 From: "Templin (US), Fred L" To: Ted Lemon CC: "STARK, BARBARA H" , Michael Richardson , =?utf-8?B?T2xlIFRyw7hhbg==?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AdbKno8gonAqMYjZtUCg6orRClX9ig== Date: Sat, 5 Dec 2020 00:46:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: D8FC507F378D27BB6F041465F1D72DFBDB72B0FEFE782B0E84BC8BE2985F3B372000:8 Content-Type: multipart/alternative; boundary="_000_fd7723f643064600b8037105529017e1boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 00:46:49 -0000 --_000_fd7723f643064600b8037105529017e1boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkLCB0aGUgb25seSBhc3BlY3RzIG9mIE9NTkkgeW91IHdvdWxkIG5lZWQgdG8gc2VlIHRvIGdy YXNwIHRoZSBjb25jZXB0cw0KYXJlIGEgcXVpY2sgc2NhbiBvZiBTZWN0aW9ucyA5LjEuOSBhbmQg MTIuMyAoYXBwcm94LiAxLjI1IHRvdGFsIHBhZ2VzIG9mIHRleHQpLg0KDQpCYXNpY2FsbHksIGl0 IGltcG9ydHMgREhDUHY2IG9wdGlvbnMgaW50byBSUyBtZXNzYWdlcyBhbmQgYXNrcyB0aGUgcm91 dGVyDQp0byBzZW5kIGEg4oCccHJveHkgREhDUHY2LVBEIFNvbGljaXTigJ0gdG8gdGhlIERIQ1B2 NiBzZXJ2ZXIgb24gYmVoYWxmIG9mIHRoZQ0KbW9iaWxlIG5vZGUuIEFmdGVyIHRoZSByb3V0ZXIg Z2V0cyBiYWNrIHRoZSBESENQdjYtUEQgUmVwbHksIGl0IHNlbmRzIGFuDQpSQSB0byB0aGUgbW9i aWxlIG5vZGUgd2l0aCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbmZvcm1hdGlvbi4NCg0KVGhpcyBp cyBzb21ldGhpbmcgSSBzdWdnZXN0ZWQgYSBsb25nIHRpbWUgYWdvLCBidXQgdGhhdCB3YXMgYmVm b3JlIHdlIGhhZA0KdGhlIE9NTkkgb3B0aW9uIGNvbmNlcHQuIE5vdyB3aXRoIHRoZSBPTU5JIG9w dGlvbiwgaXQgY2FuIGNhcnJ5IG90aGVyDQpwcm90b2NvbCBpbmZvcm1hdGlvbiBsaWtlIERIQ1B2 NiBvcHRpb25zIGp1c3QgZmluZS4NCg0KRnJlZA0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzpt ZWxsb25AZnVndWUuY29tXQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAyMCAzOjE1IFBN DQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpD YzogU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IE9sZSBUcsO4YW4gPG90cm9hbkBlbXBsb3llZXMub3Jn PjsgNk1BTiA8Nm1hbkBpZXRmLm9yZz47IGlvdG9wc0BpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVS TkFMXSBSZTogW0lvdG9wc10gQXV0b21hdGljYWxseSBjb25uZWN0aW5nIHRvIHN0dWIgbmV0d29y a3MuLi4NCg0KT24gRGVjIDQsIDIwMjAsIGF0IDY6MTIgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPj4gd3JvdGU6DQpESENQdjYtUEQgZmFucywgcGxlYXNlIGhhdmUgYSBsb29rIGF0IHRoZSBs YXRlc3QgT01OSSBkcmFmdCBhbmQgc2VlIGlmIGl0IHByb3ZpZGVzDQp0aGUga2luZCBvZiBwcmVm aXggZGVsZWdhdGlvbiBzZXJ2aWNlcyB5b3Ugd291bGQgbGlrZSB0byBzZWUgZm9yIHN0dWIgbmV0 d29ya3M6DQoNCklmIHlvdSBhcmUgZXh0ZW5kaW5nIERIQ1B2Ni1QRCBmb3IgT01OSSwgeW91IHNo b3VsZCByZWFsbHkgZG8gaXQgYXMgYSBzZXBhcmF0ZSBkb2N1bWVudC4gT01OSSBpcyByYXRoZXIg bGFyZ2UsIHNvIG1ha2luZyByZWZlcmVuY2VzIHRvIGl0IGlzbuKAmXQgaWRlYWwuDQoNClRoZSBv bmx5IHRoaW5nIHdlIG5lZWQgdGhhdCBpc27igJl0IHNwZWNpZmllZCBhbnl3aGVyZSBpcyBmb3Ig dGhlIGluZnJhc3RydWN0dXJlIHJvdXRlciB0byBhZGQgdGhlIHByZWZpeCBhbmQgZGVzdGluYXRp b24gdG8gdGhlIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUuDQoNCg== --_000_fd7723f643064600b8037105529017e1boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGVkLCB0aGUgb25seSBhc3BlY3RzIG9mIE9NTkkg eW91IHdvdWxkIG5lZWQgdG8gc2VlIHRvIGdyYXNwIHRoZSBjb25jZXB0czxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5hcmUgYSBxdWljayBzY2FuIG9mIFNlY3Rpb25zIDkuMS45IGFuZCAxMi4zIChhcHByb3gu IDEuMjUgdG90YWwgcGFnZXMgb2YgdGV4dCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5CYXNpY2FsbHksIGl0IGltcG9ydHMgREhDUHY2IG9wdGlvbnMgaW50byBS UyBtZXNzYWdlcyBhbmQgYXNrcyB0aGUgcm91dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIHNlbmQg YSDigJxwcm94eSBESENQdjYtUEQgU29saWNpdOKAnSB0byB0aGUgREhDUHY2IHNlcnZlciBvbiBi ZWhhbGYgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm1vYmlsZSBub2RlLiBBZnRlciB0aGUgcm91 dGVyIGdldHMgYmFjayB0aGUgREhDUHY2LVBEIFJlcGx5LCBpdCBzZW5kcyBhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SQSB0byB0aGUgbW9iaWxlIG5vZGUgd2l0aCB0aGUgZGVsZWdhdGVkIHByZWZpeCBp bmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo aXMgaXMgc29tZXRoaW5nIEkgc3VnZ2VzdGVkIGEgbG9uZyB0aW1lIGFnbywgYnV0IHRoYXQgd2Fz IGJlZm9yZSB3ZSBoYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIE9NTkkgb3B0aW9uIGNvbmNlcHQu IE5vdyB3aXRoIHRoZSBPTU5JIG9wdGlvbiwgaXQgY2FuIGNhcnJ5IG90aGVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPnByb3RvY29sIGluZm9ybWF0aW9uIGxpa2UgREhDUHY2IG9wdGlvbnMganVzdCBmaW5l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86bWVs bG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDA0LCAy MDIwIDM6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDtGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gU1RBUkssIEJBUkJBUkEg SCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7OyBNaWNoYWVsIFJpY2hhcmRzb24gJmx0O21jciYjNDM7 aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBPbGUgVHLDuGFuICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9y ZyZndDs7IDZNQU4gJmx0OzZtYW5AaWV0Zi5vcmcmZ3Q7OyBpb3RvcHNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW0lvdG9wc10gQXV0b21hdGljYWxseSBjb25u ZWN0aW5nIHRvIHN0dWIgbmV0d29ya3MuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIERlYyA0LCAyMDIw LCBhdCA2OjEyIFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+REhDUHY2LVBEIGZhbnMsIHBsZWFzZSBoYXZl IGEgbG9vayBhdCB0aGUgbGF0ZXN0IE9NTkkgZHJhZnQgYW5kIHNlZSBpZiBpdCBwcm92aWRlczxi cj4NCnRoZSBraW5kIG9mIHByZWZpeCBkZWxlZ2F0aW9uIHNlcnZpY2VzIHlvdSB3b3VsZCBsaWtl IHRvIHNlZSBmb3Igc3R1YiBuZXR3b3Jrczo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5JZiB5b3UgYXJlIGV4dGVuZGluZyBESENQ djYtUEQgZm9yIE9NTkksIHlvdSBzaG91bGQgcmVhbGx5IGRvIGl0IGFzIGEgc2VwYXJhdGUgZG9j dW1lbnQuIE9NTkkgaXMgcmF0aGVyIGxhcmdlLCBzbyBtYWtpbmcgcmVmZXJlbmNlcyB0byBpdCBp c27igJl0IGlkZWFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhlIG9ubHkgdGhpbmcgd2UgbmVlZCB0aGF0 IGlzbuKAmXQgc3BlY2lmaWVkIGFueXdoZXJlIGlzIGZvciB0aGUgaW5mcmFzdHJ1Y3R1cmUgcm91 dGVyIHRvIGFkZCB0aGUgcHJlZml4IGFuZCBkZXN0aW5hdGlvbiB0byB0aGUgcm91dGluZyBpbmZy YXN0cnVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_fd7723f643064600b8037105529017e1boeingcom_-- From nobody Fri Dec 4 17:27:22 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4053A1155 for ; Fri, 4 Dec 2020 17:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 r6Ihyj1lyTxX for ; Fri, 4 Dec 2020 17:27:10 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 824673A1165 for ; Fri, 4 Dec 2020 17:27:10 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id cv2so3758819qvb.9 for ; Fri, 04 Dec 2020 17:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Rl2tEKWVP+TSoy1FXieUwPRZlKh9yUyKqO8A5TXvTCU=; b=Xb4u6vd95DAGcoLBUe/1pIkPiLZZLphb07NHyAlWpQ1wQxiaxAbC8TShPwiRQjlABn 0ew125f4jOcNZbKgGyXtiQYfV8zfVOTed7W8riCZx6Lr5oQ99j/LLsA39Xb3jDILsBdi YwU0mdA9ff/ZWcpA9MKH8zoHSXQkSg7GhBtbdQfECx7BY4d5jwa8ejf9jUTuiqz/QSK2 GJim8xcrht+rw1zWRmQ1KtVkMNtrMibqj9o8g+mKr3xEjQJNJnWNccIOdqK91ZKQOvff o5aLPveDZKGh3aKmqw7+V7ICtGEmOuPq+eGbH9q+mMI+AYT/3sAqjmlY1kgW/zJIVbmL WdyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Rl2tEKWVP+TSoy1FXieUwPRZlKh9yUyKqO8A5TXvTCU=; b=tFMwDegM1sMBUoMCXPnapG9ZKgYajQXEo9iCnc0HwERP7DNixvhgglpeoRPfU7wKsv gkWF+ykNdoEPr2m8j9jrH+eePdNcb+0H5gyn22xGCom4TxzpnZvBJ5n89XTSHUz8YeWR L706JqWWXZOX6nhAHnLJF0fwhw2ECxgk7rGIxMdGzfqTjEGdH+N7LXJLoxRZ4mBsvcAD veFZCePnpIupAJDntJp+7a2NnQqa7jU+coRoZxxnTzWUdGB3QYZx/g/BFLkyyL/AL1Ac ylRuoF3G9qpgQ+u/MwmeWM0CGdNzgGe9HB3tsIPNF5Ouh0QZP/NKhk/dtLzNJl4+xQbk pLkA== X-Gm-Message-State: AOAM532uAeYD+839vh3+yH4hgVUnHQ8mZjDVUxmLKc7oDczFtZjtbF2Z 2WNfg/7xsob/MBdusei1uw0UkHa7ehLCJ0ia X-Google-Smtp-Source: ABdhPJzPy7uvwqaCJWO3orHKMlfHyk+ptHoOvzyS9wcEhgnZGaKdMQeEq1bhaiu5/a7872Mqai5FaA== X-Received: by 2002:a05:6214:aa1:: with SMTP id ew1mr7969809qvb.55.1607131629111; Fri, 04 Dec 2020 17:27:09 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p76sm2694367qke.62.2020.12.04.17.27.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Dec 2020 17:27:08 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-F92C9FD0-65BD-4933-8FFB-21808CD7EBF9 Content-Transfer-Encoding: 7bit From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Fri, 4 Dec 2020 20:27:07 -0500 Message-Id: <32909550-3A0F-4D8F-AD32-98E40BED1F0E@fugue.com> References: Cc: "STARK, BARBARA H" , Michael Richardson , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6MAN <6man@ietf.org>, iotops@ietf.org In-Reply-To: To: "Templin (US), Fred L" X-Mailer: iPhone Mail (18C65) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 01:27:13 -0000 --Apple-Mail-F92C9FD0-65BD-4933-8FFB-21808CD7EBF9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can=E2=80=99t see that being useful for stub networks. The whole point of =E2= =80=9Cstub=E2=80=9D is to avoid complicated routing, since it=E2=80=99s not u= seful for a typical stub network.=20 > On Dec 4, 2020, at 19:46, Templin (US), Fred L = wrote: >=20 > =EF=BB=BF > Ted, the only aspects of OMNI you would need to see to grasp the concepts > are a quick scan of Sections 9.1.9 and 12.3 (approx. 1.25 total pages of t= ext). > =20 > Basically, it imports DHCPv6 options into RS messages and asks the router > to send a =E2=80=9Cproxy DHCPv6-PD Solicit=E2=80=9D to the DHCPv6 server o= n behalf of the > mobile node. After the router gets back the DHCPv6-PD Reply, it sends an > RA to the mobile node with the delegated prefix information. > =20 > This is something I suggested a long time ago, but that was before we had > the OMNI option concept. Now with the OMNI option, it can carry other > protocol information like DHCPv6 options just fine. > =20 > Fred > =20 > From: Ted Lemon [mailto:mellon@fugue.com]=20 > Sent: Friday, December 04, 2020 3:15 PM > To: Templin (US), Fred L > Cc: STARK, BARBARA H ; Michael Richardson ; Ole Tr=C3=B8an ; 6MAN <6man@ietf.org>; iotops= @ietf.org > Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks= ... > =20 > On Dec 4, 2020, at 6:12 PM, Templin (US), Fred L wrote: > DHCPv6-PD fans, please have a look at the latest OMNI draft and see if it p= rovides > the kind of prefix delegation services you would like to see for stub netw= orks: > =20 > If you are extending DHCPv6-PD for OMNI, you should really do it as a sepa= rate document. OMNI is rather large, so making references to it isn=E2=80=99= t ideal. > =20 > The only thing we need that isn=E2=80=99t specified anywhere is for the in= frastructure router to add the prefix and destination to the routing infrast= ructure. > =20 --Apple-Mail-F92C9FD0-65BD-4933-8FFB-21808CD7EBF9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I can=E2=80=99t see that b= eing useful for stub networks. The whole point of =E2=80=9Cstub=E2=80=9D is t= o avoid complicated routing, since it=E2=80=99s not useful for a typical stu= b network. 

On Dec 4= , 2020, at 19:46, Templin (US), Fred L <Fred.L.Templin@boeing.com> wro= te:

=EF= =BB=BF

Ted, the only aspects of OMNI you would= need to see to grasp the concepts

are a quick scan of Sections 9.1.9 and 1= 2.3 (approx. 1.25 total pages of text).

 

Basically, it imports DHCPv6 options in= to RS messages and asks the router

to send a =E2=80=9Cproxy DHCPv6-PD Soli= cit=E2=80=9D to the DHCPv6 server on behalf of the

mobile node. After the router gets back= the DHCPv6-PD Reply, it sends an

RA to the mobile node with the delegate= d prefix information.

 

This is something I suggested a long ti= me ago, but that was before we had

the OMNI option concept. Now with the O= MNI option, it can carry other

protocol information like DHCPv6 option= s just fine.

 

Fred

 

From: Ted Lemon [mailto:mellon@fugue.co= m]
Sent: Friday, December 04, 2020 3:15 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: STARK, BARBARA H <bs7652@att.com>; Michael Richardson <m= cr+ietf@sandelman.ca>; Ole Tr=C3=B8an <otroan@employees.org>; 6MAN &= lt;6man@ietf.org>; iotops@ietf.org
Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub net= works...

&= nbsp;

On Dec 4, 2020, at 6= :12 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:

DHCPv6-PD fans, please have a look at the latest OMN= I draft and see if it provides
the kind of prefix delegation services you would like to see for stub networ= ks:

 

If you are extending= DHCPv6-PD for OMNI, you should really do it as a separate document. OMNI is= rather large, so making references to it isn=E2=80=99t ideal.

 

The only thing we ne= ed that isn=E2=80=99t specified anywhere is for the infrastructure router to= add the prefix and destination to the routing infrastructure.

 

= --Apple-Mail-F92C9FD0-65BD-4933-8FFB-21808CD7EBF9-- From nobody Sat Dec 5 01:57:53 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A466F3A10D4; Sat, 5 Dec 2020 01:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 JOMS3qKK6Km4; Sat, 5 Dec 2020 01:57:50 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E754F3A10D2; Sat, 5 Dec 2020 01:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14138; q=dns/txt; s=iport; t=1607162270; x=1608371870; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=UsjGuPUZIx3MQTT+G81BxoWw43Xpx5x05uT7TDHciMo=; b=PLaDFju9yDHAZLwmbHyvNmfArOEwNjYorFbETjxPc7QdSNhd8zQUBP5o +jEawX0B+NdQAzXFtZdLIvrCA07JzqouFDB0oJniuU7x7xyLKfWcSaPWT +Z0q/L4uc7AFz58vRQmNDqBagryGdMBof288C3533Ew1EQB7udY1wl5sB M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ClAACzWMtflxbLJq1iAwoNAQEBAQEBAQEBAQMBAQEBE?= =?us-ascii?q?gEBAQECAgEBAQGCD4EjgXxXASASLoQ8iQSHfyUDh2qMLYgbBAcBAQEKAwEBI?= =?us-ascii?q?wwEAQGBVYF2AX4CghYmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBA?= =?us-ascii?q?YY2DIVyAQEDAQEjVgULGQojBAMCAkYRBhMZgw0BgmYgD6lsgjx2gTKEPgEUQ?= =?us-ascii?q?IVUCgaBOIFTjAmCAIE4DBCBV1Bsgl0BAgEXfSsPRYJhM4IsBIFzBVtFDwEnG?= =?us-ascii?q?xATVB0LCSkVBAcfAiYSATKPIBESCot0gW2aKIJ+BIMdgTeERIt2hioDH5Jxj?= =?us-ascii?q?zuee5EdgQyDbAIEBgUCFYFtIYFZMxoIGxVlAYI+PhIZDY47HYM6hRSFRUADM?= =?us-ascii?q?AIILQIGAQkBAQMJijSCRAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,395,1599523200"; d="asc'?scan'208,217";a="31662969" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Dec 2020 09:57:45 +0000 Received: from [10.61.247.173] ([10.61.247.173]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B59viio023153 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Dec 2020 09:57:45 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Eliot Lear In-Reply-To: <77363965-99A5-4790-B40B-011827C8D113@fugue.com> Date: Sat, 5 Dec 2020 10:57:44 +0100 Cc: "Ackermann, Michael" , iotops@ietf.org, Randy Bush , architecture-discuss@iab.org Message-Id: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.247.173, [10.61.247.173] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 09:57:53 -0000 --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B" --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [moving to iotops and arch-discuss, as we are now leaving the topic of = LC] Ted, I=E2=80=99m going to pick on you a bit here, but just to call out a = larger point, because=E2=80=A6 we are almost nowhere on this problem. > On 4 Dec 2020, at 23:47, Ted Lemon > wrote: >=20 > Why do people buy stuff that=E2=80=99s not upgradeable? Probably = because the manufacturer doesn=E2=80=99t give them a choice, and = there=E2=80=99s no way to force the choice. The recent discussions about = legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) = is definitely a step in the right direction. For medical devices and = medical infrastructure, this should have been required, but as far as I = know still is not. That premise is a bit too sweeping. Stuff doesn=E2=80=99t get upgraded = for a myriad of reasons. One is that stuff gets old. Every = manufacturer has this problem. Cisco hardware is built to last, and it = is not surprising to find equipment in the secondary market that is = 15-20 years old. If you look at a workhorse like a 7200 router that = they (I wasn=E2=80=99t at Cisco yet) introduced in 1996, stopped selling = in 2012, and only last year stopped issuing software patches for, you = can still find equipment on the secondary market. =E2=80=9CWorks like = new=E2=80=9D, $1,200 plus shipping[1]. In that span of time, just how = many iPhones and Android systems have come and gone?* What sort of = eWaste problem has been created? How long should DLink provide security = updates for that frisbee that connects you to the world? 5 years? 10 = years? 15 years? Singapore didn=E2=80=99t answer that question, as I = understand it. And that=E2=80=99s in the IT market. Now go look at the thermostat in = your house. How old is it? In most cases, it dates back to when a = house was built. That=E2=80=99s the sign of a good product. In some = cases, the manufacturer may have gone out of business. How long = should an auto manufacturer support a car? I will tell you that in = general it is less than the length of time we support a router, and in = some cases far less. There are manufacturing presses that date back to = the first use of electricity. You think we have problems now? Just = wait a few years. And then there is when and how to perform upgrades. Apple along with a = great many consumer providers has it easy when it comes to device = upgrades: they can force the requirement that upgrades occur over the = Internet, and that the device be rebooted. Now try that with a = transformer providing power to a hospital or a controller for an oil = derrick in Alaska, where the duty cycle of a device can easily be 40 = years, and the maintenance window is=E2=80=A6 oh wait. There isn=E2=80=99= t one. Clearly these devices need to support in service upgrades, but = even those have to be carefully thought out, tested, and planned. And = if something goes wrong, well... My point isn=E2=80=99t that these upgrades shouldn=E2=80=99t occur. But = we do need to think differently about the whole life cycle of a system. = I=E2=80=99m far from the first to talk about this, nor is this insight = particularly recent. Dan Geer wrote as far back as 2012 about creating = Internet kill switches[2,3]. Nor is this problem related only to = security. I=E2=80=99ve already mentioned the tension between security = and eWaste. Cloud computing offers tremendous efficiencies, both = economic and environmental, by shifting intelligence from dedicating = computing to shared. But think about what just happened this year: a = number of manufacturers who use the cloud failed. What happened to = their products? And of course Cloud computing by definition assumes = Internet access, which the OT world is only beginning to allow. After = Amazon=E2=80=99s and Microsoft=E2=80=99s outages over the last several = months, they may be a bit less interested. Boiling this down, it seems to me IOT lifecycle, support models, and = security models, including software ownership, open source, associated = complexities, is a worthy topic to be picked up and discussed in iotops, = given the life spans of some of these devices. In answer to your direct question: yes we should be deprecating broken = protocols faster than we have been. The LC in question should have = occurred at least five years ago, and it will more than justify the = challenge it will give the RPC when they go to create the Updates: = header ;-) Eliot * And don=E2=80=99t even get me started on Android and the vast = technical deficit it and manufacturers created. The absolutely naive = and self-serving argument that only the h/w manufacturers are = responsible for that mess demonstrates the limits of OSS. [1] https://www.ebay.com/p/54829831 [2] = https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf = [3] https://queue.acm.org/detail.cfm?id=3D2479677 = --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[moving to iotops and arch-discuss, as we are = now leaving the topic of LC]

Ted,

I=E2=80=99m going to pick on you a bit = here, but just to call out a larger point, because=E2=80=A6 we are = almost nowhere on this problem.

On 4 Dec 2020, at 23:47, Ted Lemon <mellon@fugue.com> = wrote:

Why do people buy stuff that=E2=80= =99s not upgradeable? Probably because the manufacturer doesn=E2=80=99t = give them a choice, and there=E2=80=99s no way to force the choice. The = recent discussions about legally requiring firmware-upgradeable IoT = devices (e.g. in Singapore) is definitely a step in the right direction. = For medical devices and medical infrastructure, this should have been = required, but as far as I know still is = not.


That premise is a bit too sweeping. = Stuff doesn=E2=80=99t get upgraded for a myriad of reasons.  One is = that stuff gets old.  Every manufacturer has = this problem.  Cisco hardware is built to last, and it is not = surprising to find equipment in the secondary market that is 15-20 years = old.  If you look at a workhorse like a 7200 router that they (I = wasn=E2=80=99t at Cisco yet) introduced in 1996, stopped selling in = 2012, and only last year stopped issuing software patches for, you can = still find equipment on the secondary market. =  =E2=80=9CWorks like new=E2=80=9D, $1,200 plus shipping[1].   = In that span of time, just how many iPhones and Android systems have = come and gone?*  What sort of eWaste problem has been created? =  How long should DLink provide security updates for that frisbee = that connects you to the world?  5 years? 10 years? 15 years? =  Singapore didn=E2=80=99t answer that question, as I understand = it.

And = that=E2=80=99s in the IT market.  Now go = look at the thermostat in your house.  How old is it?  In most = cases, it dates back to when a house was built.  That=E2=80=99s the = sign of a good product.  In some cases, the manufacturer may have = gone out of business.    How long should an auto manufacturer = support a car?  I will tell you that in general it is less than the length of time we support a router, = and in some cases far less.  There are = manufacturing presses that date back to the first use of electricity. =  You think we have problems now?  Just wait a few years. =  

And = then there is when and how to perform upgrades.  Apple along with a = great many consumer providers has it easy when it comes to device = upgrades: they can force the requirement that upgrades occur over the = Internet, and that the device be rebooted.  Now try that with a = transformer providing power to a hospital or a controller for an oil = derrick in Alaska, where the duty cycle of a device can easily be 40 = years, and the maintenance window is=E2=80=A6 oh wait.  There = isn=E2=80=99t one.  Clearly these devices need to support in = service upgrades, but even those have to be carefully thought out, = tested, and planned.  And if something goes wrong, = well...

My = point isn=E2=80=99t that these upgrades shouldn=E2=80=99t occur. =  But we do need to think differently about the whole life cycle of = a system.  I=E2=80=99m far from the first to talk about this, nor = is this insight particularly recent.  Dan Geer wrote as far back as = 2012 about creating Internet kill switches[2,3].  Nor is this = problem related only to security.  I=E2=80=99ve already mentioned = the tension between security and eWaste. Cloud computing offers = tremendous efficiencies, both economic and environmental, by shifting = intelligence from dedicating computing to shared.  But think about = what just happened this year: a number of manufacturers who use the = cloud failed.  What happened to their products?  And of course = Cloud computing by definition assumes Internet access, which the OT = world is only beginning to allow.  After Amazon=E2=80=99s and = Microsoft=E2=80=99s outages over the last several months, they may be a = bit less interested.

Boiling this down, it seems to me IOT = lifecycle, support models, and security models, including software = ownership, open source, associated complexities, is a worthy topic to be = picked up and discussed in iotops, given the life spans of some of these = devices.

In = answer to your direct question: yes we should be = deprecating broken protocols faster than we have been.  The LC in = question should have occurred at least five years ago, and it will more = than justify the challenge it will give the RPC when they go to create = the Updates: header ;-)

Eliot

* And don=E2=80=99t even get me started on Android and the vast technical deficit it and manufacturers created. =  The absolutely naive and self-serving argument that only the h/w = manufacturers are responsible for that mess demonstrates the limits of = OSS.

[1] https://www.ebay.com/p/54829831
[2] https://www.usenix.org/system/files/login/articles/geeronlineon= ly.pdf
[3] https://queue.acm.org/detail.cfm?id=3D2479677


= --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B-- --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/LWZgACgkQh7ZrRtnS ejOy9ggArag43y9RCgO2m3j9AlIn7CsO47Pjjn7GY+iZqOnElz4G0No8tH6XoOw3 l8YHcwkPdgyfePlgzwbCy8NHGuZEf3MX6WBWhQohYSqT38946YAgqkMLl6GMg4C+ C4uhMa+n42dbEC5hNOqtV+E/XEXq/TjeUhFUHCDpq2+q06nOdYHiXtyyaa7eR0et Yb2AS4eyzxdNGWuQ5gQ6+j4WIQzeN5m4bfoQ6a4WAPoGm+TGnD8IEk/Yth+i3LhJ Xku/IvlMK4ewhD94pQODN36M1v5sORRy90FgL5xArhM9/o3DhSNP1yYhVtoAAjE3 mCUv2hbEFtRMuJMDLhJTFXgwwbhMuQ== =Bopg -----END PGP SIGNATURE----- --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F-- From nobody Sat Dec 5 08:40:56 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4D3A07A0 for ; Sat, 5 Dec 2020 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 8h3N8cyxtEP4 for ; Sat, 5 Dec 2020 08:40:52 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 F1C653A0773 for ; Sat, 5 Dec 2020 08:40:51 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id i199so8587272qke.5 for ; Sat, 05 Dec 2020 08:40:51 -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=g9i368ZV4iITe3qKpfV5JiRCeWjzrTZwgrtLdSGd0+8=; b=JoqmooUjPUnC3sLd+91owso93SRfkuNsycs4NEfLrRyefv8YLcxCR8kXmxQJX9HS9Z dX7EjUyZpdPh63+a6Mh5JsN6cGPLq/s6KPtsMLr1vX7/ojid4qHgF+cfo/u1cDDz25l2 qoNR8XXBiSqvFYfhj56ffzSI5jTNJVa6hwDDFNWp8wkDQW84n5mxtd+WKktm3jFR3F7c 44L6vk5GPRr77VPnAWczW6DZI46naIoFAZqapLsEpYzLzC2/oMifWllKYx0/E+46wLHU 4XRz9K3LZXWkgUJTOR8bWnC7PuuVVBmlUcCDSFMMi6DM4Y+jyx240d4qVx1wQ07Vg+WL 1o4A== 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=g9i368ZV4iITe3qKpfV5JiRCeWjzrTZwgrtLdSGd0+8=; b=i+F7VTVf/lizJ6N8KsnAuxlPYHndvA6Mv6GDb+QyiBkx5jgKP5rm2uv5OioNqRH9Qf Ok5QKke7yy2M/+SDeyqymo9Fw2LZ/hIjUY2oVQvcHJ+Zmw5oOAVfkzoeoQBad7Dr3Bnd i3bd6Lk0SVVQmPAlW8hM9WeRTuQK45yObsTHdJGfMn9MfgdTCfcdCXjrChn1Klq0O7bj R8SgdcP0F8qvTShFa1Mq6DyihPQTjkJot59LP8q+F5j0b4H5tEzUanlkLK5kLrtUKcWn yHVsTnd14ISJgsAA++PCa4IeUqTFIWQOEsNSSXayvv1pExPsJ9tQLEVAfBdgkooZYOTG YBlg== X-Gm-Message-State: AOAM531LteORvQiSnHVH76rHyy+COu4FFRpGUzkmbULSRbwgPsc9C5mu NL/1OsmwcE9+GPHY2va3NFTBaQ== X-Google-Smtp-Source: ABdhPJxMJ33EaX1sPuvEV10JddnA13RZ/Y2h9AoOfpiopqSzirYNMOkugSCEnARIIYOKMpAe9ps9nA== X-Received: by 2002:a37:9b05:: with SMTP id d5mr15572120qke.49.1607186450857; Sat, 05 Dec 2020 08:40:50 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c10sm8085963qkm.71.2020.12.05.08.40.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 08:40:49 -0800 (PST) From: Ted Lemon Message-Id: <5379569B-FEC5-4AEB-BEB6-C959114ABCCB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sat, 5 Dec 2020 11:40:48 -0500 In-Reply-To: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> Cc: "Ackermann, Michael" , iotops@ietf.org, Randy Bush , architecture-discuss@iab.org To: Eliot Lear References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 16:40:55 -0000 --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think we are mostly in violent agreement, Eliot, except that I think = we (society, not the IETF necessarily) need an architecture for how to = deal with the problems you=E2=80=99ve described. If we continue to sweep = them under the carpet, we=E2=80=99re going to continue to see ransomware = taking over hospitals and resulting in patient deaths or other adverse = outcomes, loss of privacy in large enterprises, the continued ongoing = data breaches that we see. Addressing the problems you=E2=80=99ve = described won=E2=80=99t completely solve those problems, but it=E2=80=99s = a necessary part of solving them. I don=E2=80=99t think there=E2=80=99s a way to do this on a voluntary = basis=E2=80=94it requires regulation, or there will always be an = incentive not to do it, as you have so eloquently outlined. > On Dec 5, 2020, at 4:57 AM, Eliot Lear wrote: >=20 > [moving to iotops and arch-discuss, as we are now leaving the topic of = LC] >=20 > Ted, >=20 > I=E2=80=99m going to pick on you a bit here, but just to call out a = larger point, because=E2=80=A6 we are almost nowhere on this problem. >=20 >> On 4 Dec 2020, at 23:47, Ted Lemon > wrote: >>=20 >> Why do people buy stuff that=E2=80=99s not upgradeable? Probably = because the manufacturer doesn=E2=80=99t give them a choice, and = there=E2=80=99s no way to force the choice. The recent discussions about = legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) = is definitely a step in the right direction. For medical devices and = medical infrastructure, this should have been required, but as far as I = know still is not. >=20 >=20 > That premise is a bit too sweeping. Stuff doesn=E2=80=99t get upgraded = for a myriad of reasons. One is that stuff gets old. Every = manufacturer has this problem. Cisco hardware is built to last, and it = is not surprising to find equipment in the secondary market that is = 15-20 years old. If you look at a workhorse like a 7200 router that = they (I wasn=E2=80=99t at Cisco yet) introduced in 1996, stopped selling = in 2012, and only last year stopped issuing software patches for, you = can still find equipment on the secondary market. =E2=80=9CWorks like = new=E2=80=9D, $1,200 plus shipping[1]. In that span of time, just how = many iPhones and Android systems have come and gone?* What sort of = eWaste problem has been created? How long should DLink provide security = updates for that frisbee that connects you to the world? 5 years? 10 = years? 15 years? Singapore didn=E2=80=99t answer that question, as I = understand it. >=20 > And that=E2=80=99s in the IT market. Now go look at the thermostat in = your house. How old is it? In most cases, it dates back to when a = house was built. That=E2=80=99s the sign of a good product. In some = cases, the manufacturer may have gone out of business. How long = should an auto manufacturer support a car? I will tell you that in = general it is less than the length of time we support a router, and in = some cases far less. There are manufacturing presses that date back to = the first use of electricity. You think we have problems now? Just = wait a few years. =20 >=20 > And then there is when and how to perform upgrades. Apple along with = a great many consumer providers has it easy when it comes to device = upgrades: they can force the requirement that upgrades occur over the = Internet, and that the device be rebooted. Now try that with a = transformer providing power to a hospital or a controller for an oil = derrick in Alaska, where the duty cycle of a device can easily be 40 = years, and the maintenance window is=E2=80=A6 oh wait. There isn=E2=80=99= t one. Clearly these devices need to support in service upgrades, but = even those have to be carefully thought out, tested, and planned. And = if something goes wrong, well... >=20 > My point isn=E2=80=99t that these upgrades shouldn=E2=80=99t occur. = But we do need to think differently about the whole life cycle of a = system. I=E2=80=99m far from the first to talk about this, nor is this = insight particularly recent. Dan Geer wrote as far back as 2012 about = creating Internet kill switches[2,3]. Nor is this problem related only = to security. I=E2=80=99ve already mentioned the tension between = security and eWaste. Cloud computing offers tremendous efficiencies, = both economic and environmental, by shifting intelligence from = dedicating computing to shared. But think about what just happened this = year: a number of manufacturers who use the cloud failed. What happened = to their products? And of course Cloud computing by definition assumes = Internet access, which the OT world is only beginning to allow. After = Amazon=E2=80=99s and Microsoft=E2=80=99s outages over the last several = months, they may be a bit less interested. >=20 > Boiling this down, it seems to me IOT lifecycle, support models, and = security models, including software ownership, open source, associated = complexities, is a worthy topic to be picked up and discussed in iotops, = given the life spans of some of these devices. >=20 > In answer to your direct question: yes we should be deprecating broken = protocols faster than we have been. The LC in question should have = occurred at least five years ago, and it will more than justify the = challenge it will give the RPC when they go to create the Updates: = header ;-) >=20 > Eliot >=20 > * And don=E2=80=99t even get me started on Android and the vast = technical deficit it and manufacturers created. The absolutely naive = and self-serving argument that only the h/w manufacturers are = responsible for that mess demonstrates the limits of OSS. >=20 > [1] https://www.ebay.com/p/54829831 > [2] = https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf = > [3] https://queue.acm.org/detail.cfm?id=3D2479677 = >=20 >=20 --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think we are mostly in violent agreement, Eliot, except that I think we = (society, not the IETF necessarily) need an architecture for how to deal = with the problems you=E2=80=99ve described. If we continue to sweep them = under the carpet, we=E2=80=99re going to continue to see ransomware = taking over hospitals and resulting in patient deaths or other adverse = outcomes, loss of privacy in large enterprises, the continued ongoing = data breaches that we see. Addressing the problems you=E2=80=99ve = described won=E2=80=99t completely solve those problems, but it=E2=80=99s = a necessary part of solving them.

I don=E2=80=99t think there=E2=80=99s a way to do this on a = voluntary basis=E2=80=94it requires regulation, or there will always be = an incentive not to do it, as you have so eloquently outlined.

On Dec 5, 2020, at 4:57 AM, Eliot Lear <lear@cisco.com> = wrote:

[moving to iotops and arch-discuss, as we are = now leaving the topic of LC]

Ted,

I=E2=80=99m going to pick on you a bit = here, but just to call out a larger point, because=E2=80=A6 we are = almost nowhere on this problem.

On 4 Dec 2020, at 23:47, Ted Lemon <mellon@fugue.com> = wrote:

Why do people buy stuff that=E2=80= =99s not upgradeable? Probably because the manufacturer doesn=E2=80=99t = give them a choice, and there=E2=80=99s no way to force the choice. The = recent discussions about legally requiring firmware-upgradeable IoT = devices (e.g. in Singapore) is definitely a step in the right direction. = For medical devices and medical infrastructure, this should have been = required, but as far as I know still is = not.


That premise is a bit too sweeping. = Stuff doesn=E2=80=99t get upgraded for a myriad of reasons.  One is = that stuff gets old.  Every manufacturer has = this problem.  Cisco hardware is built to last, and it is not = surprising to find equipment in the secondary market that is 15-20 years = old.  If you look at a workhorse like a 7200 router that they (I = wasn=E2=80=99t at Cisco yet) introduced in 1996, stopped selling in = 2012, and only last year stopped issuing software patches for, you can = still find equipment on the secondary market. =  =E2=80=9CWorks like new=E2=80=9D, $1,200 plus shipping[1].   = In that span of time, just how many iPhones and Android systems have = come and gone?*  What sort of eWaste problem has been created? =  How long should DLink provide security updates for that frisbee = that connects you to the world?  5 years? 10 years? 15 years? =  Singapore didn=E2=80=99t answer that question, as I understand = it.

And = that=E2=80=99s in the IT market.  Now go = look at the thermostat in your house.  How old is it?  In most = cases, it dates back to when a house was built.  That=E2=80=99s the = sign of a good product.  In some cases, the manufacturer may have = gone out of business.    How long should an auto manufacturer = support a car?  I will tell you that in general it is less than the length of time we support a router, = and in some cases far less.  There are = manufacturing presses that date back to the first use of electricity. =  You think we have problems now?  Just wait a few years. =  

And = then there is when and how to perform upgrades.  Apple along with a = great many consumer providers has it easy when it comes to device = upgrades: they can force the requirement that upgrades occur over the = Internet, and that the device be rebooted.  Now try that with a = transformer providing power to a hospital or a controller for an oil = derrick in Alaska, where the duty cycle of a device can easily be 40 = years, and the maintenance window is=E2=80=A6 oh wait.  There = isn=E2=80=99t one.  Clearly these devices need to support in = service upgrades, but even those have to be carefully thought out, = tested, and planned.  And if something goes wrong, = well...

My = point isn=E2=80=99t that these upgrades shouldn=E2=80=99t occur. =  But we do need to think differently about the whole life cycle of = a system.  I=E2=80=99m far from the first to talk about this, nor = is this insight particularly recent.  Dan Geer wrote as far back as = 2012 about creating Internet kill switches[2,3].  Nor is this = problem related only to security.  I=E2=80=99ve already mentioned = the tension between security and eWaste. Cloud computing offers = tremendous efficiencies, both economic and environmental, by shifting = intelligence from dedicating computing to shared.  But think about = what just happened this year: a number of manufacturers who use the = cloud failed.  What happened to their products?  And of course = Cloud computing by definition assumes Internet access, which the OT = world is only beginning to allow.  After Amazon=E2=80=99s and = Microsoft=E2=80=99s outages over the last several months, they may be a = bit less interested.

Boiling this down, it seems to me IOT = lifecycle, support models, and security models, including software = ownership, open source, associated complexities, is a worthy topic to be = picked up and discussed in iotops, given the life spans of some of these = devices.

In = answer to your direct question: yes we should be = deprecating broken protocols faster than we have been.  The LC in = question should have occurred at least five years ago, and it will more = than justify the challenge it will give the RPC when they go to create = the Updates: header ;-)

Eliot

* And don=E2=80=99t even get me started on Android and the vast technical deficit it and manufacturers created. =  The absolutely naive and self-serving argument that only the h/w = manufacturers are responsible for that mess demonstrates the limits of = OSS.

[1] https://www.ebay.com/p/54829831
[2] https://www.usenix.org/system/files/login/articles/geeronlineon= ly.pdf
[3] https://queue.acm.org/detail.cfm?id=3D2479677



= --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D-- From nobody Sat Dec 5 10:10:13 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732FC3A0AA0; Sat, 5 Dec 2020 10:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 cxWi-IXpNK4i; Sat, 5 Dec 2020 10:10:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 AF8E73A0A9C; Sat, 5 Dec 2020 10:10:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klc0P-0005sV-QS; Sat, 05 Dec 2020 18:10:01 +0000 Date: Sat, 05 Dec 2020 10:10:01 -0800 Message-ID: From: Randy Bush To: Eliot Lear Cc: Ted Lemon , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:10:09 -0000 [ where are we going and why am i in this handbasket? ] < rant > when you have a plant which can turn out a jillion new thingies with a day of set-up, the costs of the infrastructure to securely maintain and upgrade them in the field for three, let alone 20, years is astronomical in comparison. now multiply that by a new and different thingie being manufactured next month. now multiply that by a few hundred manufacturers. perhaps the only way to understand in one's gut the scale of this problem is to spend a few weeks in shenzhen. to improve the math one would have to amortize the cost of maintenance over many many flavors and makers of thingies. so the acme thingie mfr, and the hackme thingie mfr, and the ... need to have a common code base and upgrade infrastructure. this is seen as stifling innovation in a highly innovative and competitive space. the time from first pitch to vc term sheet and funding has gone down to two weeks. and the resulting landfill rivals the problem of plastics in the oceans. android is the only example i can think of with a multi-manufacturer upgrade and maintenance infrastructure; and it is notoriously horrid. researchers publish papers on how bad it is. but credit to android for trying. long way to go. alternatively, one could be in a regulated environment, e.g. military, medical, etc., where multiplying the cost of the thingie by orders of magnitude is seen as worth the social benefit. but, even in these environments, do not underestimate the attack surface due to sloppy ops. we, for some value of we, are used building a reliable network from unreliable components. distributed protocols are the key. that is a different universe from a reliable and long-term maintainable thingie. and maybe we don't want to use our favorite vendors' boat anchors as examples. randy, who still has a curta and a k&e log log duplex decitrig From nobody Sat Dec 5 10:19:29 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E273A0AD4 for ; Sat, 5 Dec 2020 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 iUDuZ5Mev1nI for ; Sat, 5 Dec 2020 10:19:25 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 7E91D3A0AD0 for ; Sat, 5 Dec 2020 10:19:25 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id z188so8736694qke.9 for ; Sat, 05 Dec 2020 10: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=YzOMFY6cGb56d2/yZEgQQyMbqX3eU3+szMfAfAMVGOc=; b=JmveM3Vs64ZBqYA7oZpn7KZTpN2M7QDCriryROKEdSw82KCs3xdGRqnKxnEu4HhLgP JCL+9+MFVwuVU+giL7INp3cXPiTvx4ZWvlt9YoLsJRpHc22AaQLjb53rBYpm1FVxTTDM clrfEiTgAkoZqYlASKdok5N6a3Q4zZEvHhRBdptXm7VX6/zoj7IKX/D3z9RPk4TaxL7y MJaaatDc1tOobX68DpcNkMv6QeL+qe6ZpDDl62ReczcvslKHAMIh08fJKvd96MISKBnr +NQi6eci5Wn90+Cf/6TKbUA6H+Nrapw16TVdMOuFSXVvDfMv1zreR1Tcx5EhGLqQmkb/ bZ4w== 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=YzOMFY6cGb56d2/yZEgQQyMbqX3eU3+szMfAfAMVGOc=; b=C1GLEETwE/QoWwpLPYZ/Nt+xG6vwjCrlavTAzGI3OV5UBpuPWsbA5ViJU7OkzMNLbE kz0T97w9lyGjb+9+L/sZS12miqG1ZrW+10po11gfQoqeIGjZyXC4Ye9p4DBOyJLXjwXv edK4t69IXygJMyHSwTm9flWUOzr3MnO1BBXP6TQZezpO1n52bBJRRIVSEwc7ojoK/MUF /FS+tn36Lm1C6cwnhS2vrimGrrF4/FRJK3TbXEoeIA2vMp50o+pz7oZqAKwXnzG2F1Mn HWNLGg3wCk6zPEmoqyV49s8lzAXHOAtLuvUm1COTZ931R+OWZzqh0zp4PDeyhUTzu2HY VcCQ== X-Gm-Message-State: AOAM532tpFCekOx0xk8aa90QT/gSfOKdzowsRy2gSgafZJMjMgidXrsn Lc2c3/vhNp6YOt/HVVKk04dfNA== X-Google-Smtp-Source: ABdhPJw+30A1z5G4v6FC2342154wdeO9LAGCVWZg3J0q3CVcdk4c7J6rC9esyJFVe6Z0oD7qbUh7lg== X-Received: by 2002:ae9:df01:: with SMTP id t1mr3927998qkf.5.1607192364212; Sat, 05 Dec 2020 10:19:24 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x28sm7438016qtv.8.2020.12.05.10.19.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 10:19:23 -0800 (PST) From: Ted Lemon Message-Id: <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 13:19:20 -0500 In-Reply-To: Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:19:27 -0000 --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 5, 2020, at 1:10 PM, Randy Bush wrote: > to improve the math one would have to amortize the cost of maintenance > over many many flavors and makers of thingies. so the acme thingie = mfr, > and the hackme thingie mfr, and the ... need to have a common code = base > and upgrade infrastructure. this is seen as stifling innovation in a > highly innovative and competitive space. >=20 > the time from first pitch to vc term sheet and funding has gone down = to > two weeks. and the resulting landfill rivals the problem of plastics = in > the oceans. The landfill issue is certainly heartbreaking. But most of those = Shenzhen products you=E2=80=99re talking about are based on open source = already. I=E2=80=99m not convinced that this particular problem is = actually as intractable as you are suggesting. --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 5, 2020, at 1:10 PM, Randy Bush <randy@psg.com> wrote:
to improve the math one would have to amortize the cost of = maintenance
over many = many flavors and makers of thingies.  so the acme thingie = mfr,
and the = hackme thingie mfr, and the ... need to have a common code = base
and upgrade = infrastructure.  this is seen as stifling innovation in a
highly = innovative and competitive space.

the time from first pitch to vc term sheet and funding has = gone down to
two weeks. =  and the resulting landfill rivals the problem of plastics = in
the = oceans.

The = landfill issue is certainly heartbreaking. But most of those Shenzhen = products you=E2=80=99re talking about are based on open source already. = I=E2=80=99m not convinced that this particular problem is actually as = intractable as you are suggesting.

= --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6-- From nobody Sat Dec 5 10:27:45 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6060C3A0AF6; Sat, 5 Dec 2020 10:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 a4QYZaQAud23; Sat, 5 Dec 2020 10:27:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 9E6603A0A0E; Sat, 5 Dec 2020 10:27:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcHT-0005uP-2U; Sat, 05 Dec 2020 18:27:39 +0000 Date: Sat, 05 Dec 2020 10:27:38 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:27:43 -0000 > most of those Shenzhen products you=A2re talking about are based on open > source already and open source is notoriously secure, inspected, formally verified, and well updated. can you spell "m i r a i?" how many kernel upgrades have you had to do over the last month; and what percentage of ops did them? randy From nobody Sat Dec 5 10:32:35 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE4E3A0B16 for ; Sat, 5 Dec 2020 10:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_TEMPERROR=0.01, 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 alVIXSLrL892 for ; Sat, 5 Dec 2020 10:32:27 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 6FF043A0B18 for ; Sat, 5 Dec 2020 10:32:27 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id 7so6498075qtp.1 for ; Sat, 05 Dec 2020 10:32:26 -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=tIq14bohZFtwHfwNywzg9gaytwGrJXTDRNGbbKi9HHE=; b=vbGlZpOSI6xtP10+U0/z0rEDKQWHlVZkwc4a2plikqIGbtY+q/nri5Y6stj+A81/1u CRMv6NXLiesh+MZ8htTy6tkKDMNVXNz7QMsMlghbK+3q3Tzo/EnZS3+mHfcipXhLIlBX FZMmIZH1DLUSZAtxdcJKoVIRAbqFTWZG8oF5ABkKww71gpiQjYESyAK3/3F1g07+mhe5 kFoEhssaXA458aiEXI8GHN7rr1XLiT+NF3Q3htHDME7VHTJOzVsCjJdIGEIkWy8IiQrS hpNeDChJaxWnHja2BqAPD8PqqOKmEz6r/nhmYrxJIquD6f1hk6577kjxdcMkzjR7pWCe ewEQ== 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=tIq14bohZFtwHfwNywzg9gaytwGrJXTDRNGbbKi9HHE=; b=N1BgT53f/Ye4bVRTec/e6nK5rN6bZlCggjuHGquY6pen39qv6i/DaZDeOWJs7nw40x 9JIPQ/efRB/DEKyf4i7NRTllctpbMUCv+5gq16oweUr6R3goCp1EFDgneThZlMjBqthH uviDn6+5SRzHBZ2B5OfmO4gUCEqbXK2HJQBGvtwyoPxE6mPvyLIreMPtOep/UmT8iuL+ WW+OH5Iq3fSkZt/2ILcm5s3cMjmdooQfFHnrAQh17hYCzLJh9N5dWqjmsgEReFLoZHww N5oqHzfuQ5bzy9KB3RWfG5s2lOMJiwVAGBWVIn6q1ZIeQzrbJ03zzlenma8suPXzuvhv NCig== X-Gm-Message-State: AOAM532tAJLA/RrD7BUDiWHbIRfQH6BoBimkmEmf6g1Vd+5kBpURGGpD oVTsbThzMzhSthz3kZGetL5vuQ== X-Google-Smtp-Source: ABdhPJxpvwhJ8hVY1sjWQJ/IQ2CAkMS6KHtbxQbVXeNmAAVim1ZD0PAPaq63d1w0kjqQBRnhjZ3R8g== X-Received: by 2002:ac8:44c7:: with SMTP id b7mr2027515qto.351.1607193146085; Sat, 05 Dec 2020 10:32:26 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id j124sm9297217qkf.113.2020.12.05.10.32.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 10:32:25 -0800 (PST) From: Ted Lemon Message-Id: <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 13:32:23 -0500 In-Reply-To: Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:32:29 -0000 --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 5, 2020, at 1:27 PM, Randy Bush wrote: > and open source is notoriously secure, inspected, formally verified, = and > well updated. can you spell "m i r a i?" how many kernel upgrades = have > you had to do over the last month; and what percentage of ops did = them? I think you misunderstand. I=E2=80=99m not saying there=E2=80=99s not a = problem. I=E2=80=99m saying that solving it maybe isn=E2=80=99t quite as = hard as you=E2=80=99re suggesting. Most of these products, the = manufacturer has already moved on after a year. They have no interest in = maintaining the software, but they can dump it on github. They don=E2=80=99= t because they don=E2=80=99t have to, not because they strongly care not = to. If you bought a thousand units, it=E2=80=99s probably worth hiring = someone to update it to TLS 1.3. Getting Cisco to dump IOS on github is probably a bigger ask, but if the = enterprise that=E2=80=99s buying the equipment is required for = regulatory compliance to subscribe to updates, that creates a cash flow = that can then be used to pay to do them. If the regulatory environment = similarly requires that Cisco either do the updates, or allow someone to = do them, then that problem is solved too. Yes, this costs more than disposable technology, iff you don=E2=80=99t = count the externalized costs. --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 5, 2020, at 1:27 PM, Randy Bush <randy@psg.com> wrote:
and open source is notoriously secure, inspected, formally = verified, and
well updated. =  can you spell "m i r a i?"  how many kernel upgrades = have
you had to do = over the last month; and what percentage of ops did = them?

I = think you misunderstand. I=E2=80=99m not saying there=E2=80=99s not a = problem. I=E2=80=99m saying that solving it maybe isn=E2=80=99t quite as = hard as you=E2=80=99re suggesting. Most of these products, the = manufacturer has already moved on after a year. They have no interest in = maintaining the software, but they can dump it on github. They don=E2=80=99= t because they don=E2=80=99t have to, not because they strongly care not = to. If you bought a thousand units, it=E2=80=99s probably worth hiring = someone to update it to TLS 1.3.

Getting Cisco to dump IOS on github is = probably a bigger ask, but if the enterprise that=E2=80=99s buying the = equipment is required for regulatory compliance to subscribe to updates, = that creates a cash flow that can then be used to pay to do them. If the = regulatory environment similarly requires that Cisco either do the = updates, or allow someone to do them, then that problem is solved = too.

Yes, this = costs more than disposable technology, iff you don=E2=80=99t count the = externalized costs.

= --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36-- From nobody Sat Dec 5 10:46:10 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6903A003E; Sat, 5 Dec 2020 10:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 6AYhAiP6k2os; Sat, 5 Dec 2020 10:46:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (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 206E73A0039; Sat, 5 Dec 2020 10:46:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcZG-0005vy-JM; Sat, 05 Dec 2020 18:46:02 +0000 Date: Sat, 05 Dec 2020 10:46:01 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:46:08 -0000 > they can dump it on github well chosen verb now that github is owned by msoft, next year msoft ai will formally verify and correct all the dren on github. w00t! randy From nobody Sat Dec 5 10:48:36 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB0D3A02BD; Sat, 5 Dec 2020 10:48:30 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2TvswAqFOG0g; Sat, 5 Dec 2020 10:48:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (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 2D0D63A0147; Sat, 5 Dec 2020 10:48:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcba-0005w9-0t; Sat, 05 Dec 2020 18:48:26 +0000 Date: Sat, 05 Dec 2020 10:48:25 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:48:30 -0000 >> they can dump it on github > well chosen verb > now that github is owned by msoft, next year msoft ai will formally > verify and correct all the dren on github. w00t! and, of course, once msoft ai fixes the code, it will magically and securely distribute it to the 42 jillion deployed devices. via luftschweinza randy From nobody Sat Dec 5 10:54:53 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005403A048B for ; Sat, 5 Dec 2020 10:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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_NONE=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=rtfm-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 stGOSpXaOddS for ; Sat, 5 Dec 2020 10:54:47 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 F0EC63A04BC for ; Sat, 5 Dec 2020 10:54:46 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so10403030ljc.12 for ; Sat, 05 Dec 2020 10:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ckCzTpqd+VYzCUUeIlbswDDow+2mmMmMHt9zsBmcXK0=; b=iFFE3vxRz1q848iQQgVvHOzvMI6tAG7q6v99xeW2sy/zVv0Po0cnem0rAZcj8Ob/Hc rg4DG4GqvtpanwQxbANNmkRVecBEvXBmtfE8/S5S8HSUaMJQMIhTIySuRhr5zMMTD7TS xEaV09caI+oKa6ccka8Om7BuhboRF5XgjrVgaru3cDhbvOSJrHv54nJmFEmXZfLkHFLI 39djUgEIqVAK7tC8JHdNejYDOV+vqw4BgzmtS0eNE9BGnePkp82lHkItKpDyjhQFb4SV tqxsZVk4XIp0pfF+NNB3TBOVOwD6yeGxu9uHAdeUApRPIjsbpk8EVWLZ7Y9Z9QwAIlnP cedg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ckCzTpqd+VYzCUUeIlbswDDow+2mmMmMHt9zsBmcXK0=; b=bgu4DoLqFTY32ZCFpjxJUgs3/TlKHE4q41nqepvF/vClIRjOa0sHJD0NMrimvn8Rki ESY2PxQSIg55cRY+LgL+S66vwRrIgtAv4luQEDayhn9xlZig2POohoOAOD/yA3kU10g0 K/kWuP5SRaUrgKsFR6okQO01NNy3kE/+RO5BOtfBJzA7Trxr9H+JL8oR+TZIjKe0L3un 0VD1tgE6Jn0hwELS+mxWMcO620P4LI1ubGEAb4Y6m1VWOv2IR9oEJp5EH7m2u+7SLwxc msfNLWEsFleV+HLYJhKQBtGEJH2Od0WrtapKm8K+0xwKNL6E2vVe2QFJ3+/46gT2EyM1 YKug== X-Gm-Message-State: AOAM530ExALH1XgXXF/P+38yQqsri42o3l0fAzRowcusxT4ZLsB4vMqe 04Bld2s/BQgzNKpwXu7BoUCwasMOaTapNUjbkIbyLw== X-Google-Smtp-Source: ABdhPJzx8unsUIFdtuTes7doWo0aZmVy0W202eMfzRwrI08K3cd67qHwUvW95gOdqn61rUtKIYvDmLSr81S8QhnkTD8= X-Received: by 2002:a2e:9614:: with SMTP id v20mr5747693ljh.13.1607194484953; Sat, 05 Dec 2020 10:54:44 -0800 (PST) MIME-Version: 1.0 References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> In-Reply-To: From: Eric Rescorla Date: Sat, 5 Dec 2020 10:54:08 -0800 Message-ID: To: Randy Bush Cc: Ted Lemon , iotops@ietf.org, architecture-discuss@iab.org, "Ackermann, Michael" Content-Type: multipart/alternative; boundary="0000000000005c65fe05b5bc2066" Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:54:50 -0000 --0000000000005c65fe05b5bc2066 Content-Type: text/plain; charset="UTF-8" I know you're just being sarcastic, but Microsoft, in cooperation with INRIA and others has done a bunch of great work on code verification, including: - mitls - a verified TLS stack [https://www.mitls.org/] - HACL* - verified implementations of a number of important cryptographic algorithms [https://hacl-star.github.io/] HACL* is actually seeing quite a bit of use. To quote from their site "Code from HACL* has been incorporated into Firefox , the Windows kernel, the Linux kernel, the Tezos blockchain , the Microsoft MSQuic implementation of the QUIC protocol, and the Wireguard VPN ." -Ekr On Sat, Dec 5, 2020 at 10:46 AM Randy Bush wrote: > > they can dump it on github > > well chosen verb > > now that github is owned by msoft, next year msoft ai will formally > verify and correct all the dren on github. w00t! > > randy > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000005c65fe05b5bc2066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know you're just being sarcastic, but Microsoft= , in cooperation with INRIA and others has done a bunch of great work on co= de verification, including:

- mitls - a verified T= LS stack [https://www.mitls.org/]
- HACL* - verified implementations of a number of important cryptog= raphic algorithms [https://hacl-st= ar.github.io/]

HACL* is actually seeing quite = a bit of use. To quote from their site "Code from HACL* has been incor= porated into Firefox, the Windows kernel, the Linux kernel, the Tezos blockchain, the Microsoft MSQuic implementation of the QUIC protocol, and the Wireguard VPN."

-Ekr

<= /div>
O= n Sat, Dec 5, 2020 at 10:46 AM Randy Bush <randy@psg.com> wrote:
> they can dump it on github

well chosen verb

now that github is owned by msoft, next year msoft ai will formally
verify and correct all the dren on github.=C2=A0 w00t!

randy

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000005c65fe05b5bc2066-- From nobody Sat Dec 5 11:01:31 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7300D3A0763; Sat, 5 Dec 2020 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 AAPP_lF0Zjse; Sat, 5 Dec 2020 11:01:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 713B03A0762; Sat, 5 Dec 2020 11:01:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klco2-0005xe-W1; Sat, 05 Dec 2020 19:01:19 +0000 Date: Sat, 05 Dec 2020 11:01:18 -0800 Message-ID: From: Randy Bush To: Eric Rescorla Cc: Ted Lemon , iotops@ietf.org, architecture-discuss@iab.org, "Ackermann, Michael" In-Reply-To: References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:01:30 -0000 > I know you're just being sarcastic moi? > Microsoft, in cooperation with INRIA and others has done a bunch of > great work on code verification indeed. impressive work. and galois has a solid foot in a very interesting part of the space too; as do a bunch of folk. but i suspect that it will be at least until after the holidays that all this will seriously improve the quality of the code 'dumped' on github. randy From nobody Sat Dec 5 11:43:52 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D823A0C3F for ; Sat, 5 Dec 2020 11:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 Orq2SRShUlMe for ; Sat, 5 Dec 2020 11:43:49 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 312283A0C3A for ; Sat, 5 Dec 2020 11:43:48 -0800 (PST) Received: from xse290.mail2web.com ([66.113.197.36] helo=xse.mail2web.com) by mx14.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kldT4-0004IG-MY for iotops@ietf.org; Sat, 05 Dec 2020 20:43:46 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CpKkh24mRzP8w for ; Sat, 5 Dec 2020 11:43:40 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kldT2-0004Sn-5W for iotops@ietf.org; Sat, 05 Dec 2020 11:43:40 -0800 Received: (qmail 10109 invoked from network); 5 Dec 2020 19:43:39 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.42]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2020 19:43:39 -0000 To: Randy Bush , Eliot Lear Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> From: Christian Huitema Message-ID: <25c496c0-98d0-e15b-d16f-e55b40936e35@huitema.net> Date: Sat, 5 Dec 2020 11:43:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.36 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ecN11dQIc3aKzz9DU5dqGmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDkYdvTvpBhe1njBTuAhG5isRX qYbtEQV1z/L435ZRxFTpjz11yk20Cgn0BWRFsJvG+rYZvu7UEJiU3s27VgKHOyZW1GV7xIGR2Pah XFd2I+v/8xSkbkknR4QEX1UCPMqtT0faNNeCAjrPaSFl/DrSye11kcQHe/ZSvdh3LCkZvGvMSk2o JkN8TMlWdO1BEVs8egU17BcXEs4aRRyrlQ3fErsvJTQ0tEFlpAA4Ze4JQkfT264UplttrVtcgcYE U/G5DNwuI+Junt6IySZn5MNduS9NHF15uYotBm889EHvDqkDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZEwWcPoaRBqQ28Cyw5TTd3TtBj3yVo2brOZHdbWGqOVpLJAn9rasfyvJQS+Xb7Htbj2 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1SIQ5HPeglIPwXkT6IrnKzj+xRrjVmRxpGtS cvUmgj1LVxYv/o7KmveCo3wXG35ypV2jZAOanSBpz6Rja2u/0jLSgbYcaf8P+nUoF26MC/75H2l6 JDdpTQSuNHVDwQMDZ0+FqboeKny9Q71ZpU7eHyIogGxu+k3eVrwzPGdx+AkB7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:43:50 -0000 On 12/5/2020 10:10 AM, Randy Bush wrote: > when you have a plant which can turn out a jillion new thingies with a > day of set-up, the costs of the infrastructure to securely maintain and > upgrade them in the field for three, let alone 20, years is astronomical > in comparison. now multiply that by a new and different thingie being > manufactured next month. now multiply that by a few hundred > manufacturers. > > perhaps the only way to understand in one's gut the scale of this > problem is to spend a few weeks in shenzhen. That's indeed the big tension. People set up factories, hospitals and many other environments with a focus on their main mission, be it mass production of widget or the saving of lives. They don't want to stop doing what they are doing just because all the thermostats needs to be replaced. At the same time, we have ample evidence not replacing these obsolete little thermostats or other devices opens them to catastrophic failures, such as the casino that got hacked through an aquarium control device, the many hospitals that were hit by ransomware attacks, or the uranium enrichment plant that was crippled by a virus. So, what gives? The Mirai worm attacked routers, which supposedly were acting as firewalls for home networks. That uranium enrichment plant was supposedly air-gapped. It is pretty clear that solutions based just on isolating networks with firewalls do not work in practice. But then, it is also clear that the current IAB recommendation of "regular software updates" does not work either. People don't do that because they fear the update itself will damage their network, or maybe because the device is so old that the manufacturer is not producing updates anymore, or for what other reason that I have yet to understand. As Randy says, we are supposed to construct a reliable network from unreliable components. We are failing at that. What should we do? Should we recommend some form of preventive maintenance, in which devices are systematically replaced after some years, much like we currently systematically replace batteries or light bulbs before they fail? For devices that cannot be replaced, such as maybe MRI machines, should we suggest some kind of individual firewall that isolates them from the network? I don't know, and my ideas are probably wrong. But we need to have that discussion, and we need to have it with the people who actually manage plants, hospitals and other environments. -- Christian Huitema From nobody Sat Dec 5 13:11:16 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EBA3A0D65 for ; Sat, 5 Dec 2020 13:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=ambotec.org 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 4sZjvM4LvcjZ for ; Sat, 5 Dec 2020 13:11:09 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 A05B43A0D4C for ; Sat, 5 Dec 2020 13:11:08 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id d3so8227582wmb.4 for ; Sat, 05 Dec 2020 13:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambotec.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sfX2XP982QTx+HzDrdiwrUj13f2GMHF59YdyTv/z5uM=; b=K28zYpKBuKg2JhhUeVtkI+mOxsD7SyDum6DdxUw1rmeOyR812j75yDlCVLNGVQ2NtD 8p8ogrSPhZsQLNqsTjL/jZvojXnhfGQyraQUrI9rKvcfpAXp4fXxSEtABjEFu32Nwvvn lk/e8iZPNCtgqrgRQUAJdAnw/qo4Zl1OZWD8IHkqCTCVIB6o8ZD0EPHr2Nm0N8El1QGt gPfu7FUgGYuxxGh07lp42GOAlQXklNeM0Zi123qWby3e/VgDUSiq9UcuH+d5A7riRae4 wJXaY0F/XfIDrlmo2eEkWrld2brmoXRMszqi8X1o4IVgFwpwafMVRLCxEk0j5FhoDd0G S/Pw== 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=sfX2XP982QTx+HzDrdiwrUj13f2GMHF59YdyTv/z5uM=; b=iqPIx0SEVCJ+AWNS92Jxuz5Hi8Qy2e3i9Yu7z02Jcvtp7neNQmKv5NqIk41IR60HGE Hp17VbBiMNjsHx7LA163cG95Wp5p8Im2taJlgqIMB5nAxotYIFg3TX6vzEVCO++om2BX YPTJgaYJGOp0KHG1qAGWJiHDvGGMOAlsel2Nz+KXqOhKSwQiEdQ46oTuqFnH4tR/sbqn Tw0s1U4ZaPcKe+C86Sx8bS55WtXB25GHz8/5XyuEGBWYfVUH18b6XlxksEByRnf6d4u3 dO+7sG1Y8vB95YWjIQdnsqNjqBm3G9wjIW1WdTKMgmNr97604wgAjl8yOC4RyQO0CkBY 15qw== X-Gm-Message-State: AOAM533FmXzqq5y8L/VUTB03xcQqRw39FM0YuCWJfs+d8D4s90m9Z42Q iGEjxOgBTVZYGdlEfwIQYhbAfQ== X-Google-Smtp-Source: ABdhPJyNMVMTIYjszYFGeuPCt9urpiRE2S4xSSQ5oPyiJi+l28oAfcdyqbYC2QBi6EJHiqyZhN1WlA== X-Received: by 2002:a1c:6689:: with SMTP id a131mr10686694wmc.33.1607202666512; Sat, 05 Dec 2020 13:11:06 -0800 (PST) Received: from [192.168.1.4] (3.236.90.146.dyn.plus.net. [146.90.236.3]) by smtp.gmail.com with ESMTPSA id f14sm8802521wme.14.2020.12.05.13.11.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 13:11:05 -0800 (PST) From: Amyas Phillips Message-Id: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 21:11:04 +0000 In-Reply-To: Cc: Eliot Lear , architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 21:11:11 -0000 --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Dec 2020, at 18:10, Randy Bush wrote: >=20 > to improve the math one would have to amortize the cost of maintenance > over many many flavors and makers of thingies. so the acme thingie = mfr, > and the hackme thingie mfr, and the ... need to have a common code = base > and upgrade infrastructure. =20 Exactly right, it=E2=80=99s hard to imagine any other economically = viable way of maintaining devices which aren=E2=80=99t sold with a = service contract. Even for devices which are sold with a service = contract, this is still a cheaper and likely better way of delivering = the security maintenance part of that service.=20 There=E2=80=99s a few commercial products which do this. They = essentially offer modules with an OS and application environment which = they maintain for you, to a more or less hands-off degree: msoft Sphere, = Balena, Particle, Electric Imp, Ubuntu Core. They don=E2=80=99t maintain = your application but that may well be a relatively small part of the = attack surface, and possibly defended by features of the maintained = environment.=20 Microsoft Sphere in particular is interesting because the maintenance is = completely hands off and the costs are folded into the initial BOM cost = of the module, there=E2=80=99s no service fee. Amyas= --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:

to improve the math one would = have to amortize the cost of maintenance
over many many flavors and makers of thingies.  so the = acme thingie mfr,
and the hackme thingie mfr, and the ... need to have a common = code base
and upgrade = infrastructure.  


Exactly right, it=E2=80=99= s hard to imagine any other economically viable way of maintaining = devices which aren=E2=80=99t sold with a service contract. Even for = devices which are sold with a service contract, this is still a cheaper = and likely better way of delivering the security maintenance part of = that service. 

There=E2=80=99s = a few commercial products which do this. They essentially offer modules = with an OS and application environment which they maintain for you, to a = more or less hands-off degree: msoft Sphere, Balena, Particle, Electric = Imp, Ubuntu Core. They don=E2=80=99t maintain your application but that = may well be a relatively small part of the attack surface, and possibly = defended by features of the maintained environment. 

Microsoft Sphere in particular is interesting = because the maintenance is completely hands off and the costs are folded = into the initial BOM cost of the module, there=E2=80=99s no service = fee.

Amyas
= --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A-- From nobody Sun Dec 6 04:32:47 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD1A3A0D14 for ; Sun, 6 Dec 2020 04:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 A4RazlEx43Oa for ; Sun, 6 Dec 2020 04:32:40 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBAD3A0D17 for ; Sun, 6 Dec 2020 04:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2312; q=dns/txt; s=iport; t=1607257960; x=1608467560; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=TI/aMTFdV4qj8DMbP5tpgFR7In/THeT89w23sLhNGrI=; b=H7H3hdOn0kdoJmRCFHPE5Szi6WVVE/oLULGeXxGTy7o2Mtmln/zgb/Co TLnyrPjZXDp5FafJRXlRO+tA8t4H+5d/tqcle8/2cYCAWQDMdXXlnXh/S vUfzP469793zK8EM2KomJteIWv1C1QOzKTh0gtpO33CE9rIwM36pOG/Lv o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BmDADUzsxf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4N2ASASLoQ8iQSHfyUDnDIEBwEBAQoDAQEvBAEBg0sBAX0CghYmOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBHGFbYVyAQEBAwEjVgULCxgjBwICVwYTgyYBgmYgq?= =?us-ascii?q?nt2gTKFV4USEIE4gVOJI4JmggCBOAwQgiAHLj6HVTOCLASDJ3IwDShUApBEH?= =?us-ascii?q?It0nBWCfoMhgTeWZAMfknGPO7Ekg2wCBAYFAhWBbSOBVzMaCBsVZQGCPj4SG?= =?us-ascii?q?Q2OWI4TQAMwNwIGAQkBAQMJjSgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,397,1599523200"; d="asc'?scan'208";a="29245021" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2020 12:32:35 +0000 Received: from [10.61.245.231] ([10.61.245.231]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B6CWYUn027615 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Dec 2020 12:32:35 GMT From: Eliot Lear Message-Id: <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 6 Dec 2020 13:32:34 +0100 In-Reply-To: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> Cc: Randy Bush , architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" To: Amyas Phillips References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.245.231, [10.61.245.231] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 12:32:43 -0000 --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Dec 2020, at 22:11, Amyas Phillips wrote: >=20 > There=E2=80=99s a few commercial products which [=E2=80=A6] = essentially offer modules with an OS and application environment which = they maintain for you, to a more or less hands-off degree: msoft Sphere, = Balena, Particle, Electric Imp, Ubuntu Core. They don=E2=80=99t maintain = your application but that may well be a relatively small part of the = attack surface, and possibly defended by features of the maintained = environment. >=20 > Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM = cost of the module, there=E2=80=99s no service fee. It=E2=80=99s a start. The question is long those contracts stay in = place. The issue is not 1, 2, or 3 years from purchase, but generally = later. The more recent the product was shipped the more motivation to = fix it within the existing framework, as D-Link discovered. In looking 10 years out, the aggregate exposure is lower due to the = number of units, but that means that the maintenance costs, which are = independent of outstanding units, need to be borne by a smaller based, = or priced in at time of sale. That=E2=80=99s not a small number for any = but the largest companies. Eliot --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/Mz2IACgkQh7ZrRtnS ejNxHQf/UVfuTZEsh6yR//kx4CTrJ4WZJzg9PnRRuKi0Mco7Jw3oEL+ZSpHd6dUY qB/Ev82yNbs/ZGW+V3GeSY+0BrujefNVGrF1nUa2jzIRad+2Lotxj+j9OtefNzrz 37IG1EqXmcgylGIwOh+eaJ814Idla/uiKoHi6G6G9CpDYAdQB8VCOM/0hNWdGiCR 8rqvQSE3XsSbYnKrgjs8gHevI/OJJ3d4NND9JhYvv0zmKc6Lk4poh79oaral1+N0 GlaTFhrK6sFgSZZyOsd+vWy5hQDSqeu60UywYlyhvRVVHI2JxvbJu7InQLNbGAWO UJPGfTmW/CSbYCBKIagVjZ73Eku4xA== =uzGu -----END PGP SIGNATURE----- --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714-- From nobody Mon Dec 7 01:19:07 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE15A3A1256 for ; Mon, 7 Dec 2020 01:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7oXnhAn1PUFw for ; Mon, 7 Dec 2020 01:19:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6143A1257 for ; Mon, 7 Dec 2020 01:19:00 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 732E9549B09; Mon, 7 Dec 2020 10:18:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 69371440041; Mon, 7 Dec 2020 10:18:54 +0100 (CET) Date: Mon, 7 Dec 2020 10:18:54 +0100 From: Toerless Eckert To: Amyas Phillips Cc: Randy Bush , Ted Lemon , "Ackermann, Michael" , architecture-discuss@iab.org, Eliot Lear , iotops@ietf.org Message-ID: <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 09:19:04 -0000 Great pportunity for a rant: Its easy to understand how the mayority of participants in these discussions are from either a commercial supplier side, or from a commercial user side. In either case, a clearly time restricted use case scenario is easily be most important default. This btw. also applies to where my pay check comes from (i think). Nevertheless, i would highly recommend to no limit our design decisions to this scenarios. Personally, i for once would be happy as an individual to see any standards be blackmailed in the press and in public as an evil conspiracy for planned obsolescence that does not consider the ability for devices to operate as long as their hardware can without being constrained by 'security' software. Obviously, there are also significant commercial applications undetermined long life cycles are required. Just think of any deep space exploration NASA satellites go dark because of their non-crypto agility. Or the non-desire to upgrade nuclear missile control systems to new HW/SW because overall system security analysis shows how new HW/SW more likely than not will be MORE susceptible to attacks than simpler older SW/HW around for 50 years. Just two extreme examples. I am not 10% sure about generic approaches to solve this problem, but one approach could be the following: - A device communications is designed to be able to operate solely within a "walled garden" environment. Not as the ONLY option, but as one option. - Walled garden means that all communication channels of the device can be directed to go through other nodes of the "walled garden". - "Walled garden" should IMHO also mean that the higher layer semantic of all communications is well enough defined/documented, so that another device in the walled-garden can be set up to convert/proxy the communications. - Aka: If the crypto starts to become obsolete, then the obsolete crypto would be possible to constrain to the walled-carden (physical security) environment, and be proxied, and if the original remote communication parties do not exist anymore, but the data to be exchanged exists, then such a proxy could also proxy/convert the data into the 'legacy' format. The ability to understand all the information communicated well enough to be able to re-recreate the format is also necessary for any type of higher-layer security filtering, so this type of communications design is not only good for longevity, but also for security beyond transit confidentiality. Cheers Toerless On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > to improve the math one would have to amortize the cost of maintenance > > over many many flavors and makers of thingies. so the acme thingie mfr, > > and the hackme thingie mfr, and the ... need to have a common code base > > and upgrade infrastructure. > > > Exactly right, it???s hard to imagine any other economically viable way of maintaining devices which aren???t sold with a service contract. Even for devices which are sold with a service contract, this is still a cheaper and likely better way of delivering the security maintenance part of that service. > > There???s a few commercial products which do this. They essentially offer modules with an OS and application environment which they maintain for you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, Electric Imp, Ubuntu Core. They don???t maintain your application but that may well be a relatively small part of the attack surface, and possibly defended by features of the maintained environment. > > Microsoft Sphere in particular is interesting because the maintenance is completely hands off and the costs are folded into the initial BOM cost of the module, there???s no service fee. > > Amyas > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Mon Dec 7 05:53:58 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9213A13D5; Mon, 7 Dec 2020 05:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl 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 3PpaYd4Ewxod; Mon, 7 Dec 2020 05:53:44 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140113.outbound.protection.outlook.com [40.107.14.113]) (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 CC5423A13D2; Mon, 7 Dec 2020 05:53:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CnY0fN1uPiuHJ6Fd0CB5tt5z1Lmj3bBFZhfqDkIv4Wuu1uWqoC4c2UOzzbA4c+7mrtYJEu+je67AUZslOUoeS7ay1dHbsRJBY6SFgWLhE0+TtVULMzlXKbcFGj1HPEr2RVuUAk2v1K6YsxGvr82kO82sc0MUAsAGxbvNFqCt8dRBVGu1gVA40xnTb1GTz+Wp6PowOhiS8Kk/0RiXLV6DaxkiuuhTuNfD8v6IhuRv23UO92tfDdg4F5w0jSAdAu1SZSy9cm383NFuM59mSW+fUImjAV2jU5Bybqw4J61DB9tEuL9s1G2pP4dapte9FhwhzBOYu46F/BmY3vZHvE6rjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+u93UEs5iBRW3wp/gIvoOtRv08lyr46EK630bWfLmlQ=; b=eU5XT4vtQsRk5e/2dDiHdfJXUqho6K2GxN/C8Guql+hTBj760DDlZAqnioVss3hF5KTcnNxiqdUofyTZCu5Nq7u88pxRg95rMcVxHAlpFXa5jcr+VxFjVmNq6I1UAZHblgo7292y5rLSMNVpXaSjJF0O3JnzuAqX8B+FihpjHCDl8g85fvrA6PLbIsRRNApt12s58+S2KxevB6cI6yaizND3hQgrp/uZCEYsEFv8pGci4QXK1Kl1E7Se7AoqWXAdXow1wOchYy6xPozD9KVIb6ttMhu5a65+JGhQzrfkxBMrgNpBSj+lzVpXQ2U06upgoIHmCzSo0XFxsy6EyHR9RA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+u93UEs5iBRW3wp/gIvoOtRv08lyr46EK630bWfLmlQ=; b=D5mBcKrpW3iw+MPztCNat/nNmOGW1W0TbXTnfZrA8dPvYgInUwpom70SrfHoynS6hr0QAVi4nkdBEJEeMrun+Owu7OyznZzwsJloxFwvqyqcdhxtKmViBYJD8grBNRWXL3rpTpFqcyh4PJnJcQoN68gEYJ52CKNYrUSzUovdMlE= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0081.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:5f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Mon, 7 Dec 2020 13:53:37 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3611.031; Mon, 7 Dec 2020 13:53:37 +0000 From: Esko Dijk To: Michael Richardson , "anima@ietf.org" , "acme@ietf.org" , "iot-onboarding@ietf.org" , "iotops@ietf.org" , "lamps@ietf.org" CC: "Max Pritikin (pritikin)" Thread-Topic: [Anima] ACME integrations with BRSKI and the cmcRA EKU Thread-Index: AQHWynzIFTxls/YioEynislZJikrbanrcCTw Date: Mon, 7 Dec 2020 13:53:37 +0000 Message-ID: References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <600.1585687336@localhost> <5633.1585770340@localhost> <13227.1586052088@localhost> <14837.1586479192@localhost> <23785.1605650162@localhost> <26304.1607113986@localhost> In-Reply-To: <26304.1607113986@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:71d7:27c6:6e0d:88b5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c7650576-9d69-49ca-c95f-08d89ab77ef9 x-ms-traffictypediagnostic: AM4P190MB0081: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 38XdXxUf/Mi+J2C3S/A7wYCe4ftcdly8YqwscJLTxbO+KjaVJTwSPalMTdaTLuTmmBwTtDFFfoduDWeZM2V7PQ17Q4kRrMxgWS+urLBtjPin7CvA3H0S6iRWW3ro0FUg9DFdH0XRno+1r5fI6awkfPkEHACn1XMn7Ps7aXybFWqWeLSowmAV8z28h9zuWF29eTBsU9fi2mVr20pofFKMGahqJLaPIVe2+uBinLaeyflriJOM1d2px+/oCCQmRXe7h4p2aDYku1QZ11KVp/vTt3c0sgOeTqoK92h7wcFSTqFWf1wK/oUksrrEBuRt/SPjP5WUFfCiNh+4ipGQaoE5cA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(39830400003)(376002)(366004)(55016002)(53546011)(71200400001)(2906002)(66446008)(76116006)(66556008)(66476007)(64756008)(66946007)(9686003)(52536014)(316002)(8936002)(5660300002)(7696005)(6506007)(186003)(44832011)(86362001)(478600001)(4326008)(83380400001)(8676002)(33656002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?a1V4TDhFUjFWNDBveXcrMHhTMUNmaDNFTzlOVG16d3ZyNHBCaTFPdXNRUEpx?= =?utf-8?B?b0o0LzBScjN5dWdEUTJkWFgyYXVUT2k5Nm15Q0gvSVNUVS9tNy9MdndhbXBq?= =?utf-8?B?M1JTWWhhUjU1Q28wMzhLb1NpM3k5SzdVbnI3SlozRUkzc2NPejRtOGo3R3Aw?= =?utf-8?B?MnZ2TjE1dyt3TzJjNEdES2UwK0xidVJESVI0bTVGYWJxVUxFWnVmSkVYK1Va?= =?utf-8?B?Ykd5alBjdGxmbVU3WDJicE1EcjFaOE9YUWxIWWgxaUUyY09MemljVXFsMXY4?= =?utf-8?B?MnA0YjJQK0owUHRkbS9LVm9kZWd0a0NEbmFJOUdkSTRRNDJFSGhBRW1aMnYy?= =?utf-8?B?Zmh5amFPVDF2SXRSS0YwbHhla2F2OFpZN2I5NnV4dTg2clpBc3FSMkFrc0xn?= =?utf-8?B?YkZYdUUvU2lmaFpBZWFvai9lVytUY2hDRWRiOElTZHpCUGpBcExBN3d1MFVr?= =?utf-8?B?RWRkOUdHNDlqV1V3dEloWVVqUm5CZkdSdTVUTzB6SGRsdWZPTUtLL2VteFBN?= =?utf-8?B?cFB5VjFMMkhsWTlHYWlGWDQrRnFsOUhCVjRUdnF5NEttSVR6WVc4L08wNUIv?= =?utf-8?B?bFZ6Q0ZYb3MzMWFmVjJURUQ5N200STRhd0x2QW52NjlTSXF3ZFRmVExUbUZ0?= =?utf-8?B?dXo4UlI5Y1hySWJzUm83ZEtDTFZJMFYxSWtMRmppTDhDVmlUZ1NIeXZnMlhL?= =?utf-8?B?a240elE5bUJ1L2VzUDkyc3JIYjhSbTE3dzRsNXU3SjVrcXR4MHV0RkpFTEhS?= =?utf-8?B?SHFJcndJSzVDQWpiWllSL3c5L2ZuNkt5L0Z6VkU3WTRXQTMycmxkRXV0WnVG?= =?utf-8?B?blVMRmpBbG0xK0NKbkFONHN4UjN1ZE9EWWJwcWc0b2VqV1djTTlhMkVEL0VF?= =?utf-8?B?SkxoMGVKUUN0MXFid2JEendMcnBKNDUzaHoyQS9NSjVFUkxPK05yckdkOWtt?= =?utf-8?B?cFNuNEtNVGlFQjZ6MXExcE44Z1V6VGRGUjB3UXQvZXVNQlZSYVFYcGpvUFEy?= =?utf-8?B?NDJIdGd6c0FKYysreVFGallieEkybDUzRFhPRC9uanJFR0p0SzEyVWJWK1ps?= =?utf-8?B?akZiL0RyUXZIMUl0L0dqd1N1M2pidHAxSzl1NkM1dGFFRzdIc3E2RDdWWlpr?= =?utf-8?B?cXlNUmMvSWVsK0pOV0JhQUpPeSs1NXhGWEVBeDJsbk53anRnYm43Qk0wOUov?= =?utf-8?B?MStmUjhtZVIvSTFoc1FTSUV4SHZ1ZG9ROXVaYzY4QUxUUkJPTmt5elB6QU5t?= =?utf-8?B?UlEyZG14UkpmVlNVSzUvLzBWNENCRHlwSU5lQTFKM3ZBUkUzYmNxeXphTkp5?= =?utf-8?B?eDdUSmRSUElvRzZHYzZpS3FCRWdMdWdTbnZOOU1yRnIreUhuOHpzMkM0M29x?= =?utf-8?Q?uzWNgQXGxlxZI2i0BPPB0TQlofpfVYWk=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c7650576-9d69-49ca-c95f-08d89ab77ef9 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 13:53:37.1841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wjYE384SrSyo1+kdUUuUeFXWjo9VHgBkcwzxvws4blylr3lUnNtGnKoMsFd5b/Feq65pTgRZok9qCw5R2fjo1wmKf1P6w1ty9FRqUFY3xm8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0081 Archived-At: Subject: Re: [Iotops] [Anima] ACME integrations with BRSKI and the cmcRA EKU X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 13:53:47 -0000 VGhhbmtzIGZvciB0aGUgdXNlZnVsIGludHJvIE1pY2hhZWwuIA0KDQo+IEEgUmVnaXN0cmFyIHRo YXQgdXNlcyBSRkM4NTU1IHRvIHRhbGsgdG8gaXQncyBDQSBjb3VsZCBoYXZlIHRocmVlIGRpZmZl cmVudA0KPiBraW5kcyBvZiBhbmNob3JzOg0KDQpUaGUgUmVnaXN0cmFyIGFsc28gY291bGQgaGF2 ZSBkaWZmZXJlbnQgaWRlbnRpdGllcyB1c2VkIGF0IHRoZSBzYW1lIHRpbWU6DQoNCjEpIEFDTUUg Y2xpZW50IFRMUyBpZGVudGl0eSAgICh0b3dhcmRzIEFDTUUgc2VydmVyKQ0KMikgUmVnaXN0cmFy L0VTVC1zZXJ2ZXIgVExTIHNlcnZlciBpZGVudGl0eSAgKHRvd2FyZHMgUGxlZGdlcykNCjMpIFJl Z2lzdHJhci9FU1Qtc2VydmVyIHNpZ25pbmcgaWRlbnRpdHkgIChmb3Igc2lnbmluZyBWb3VjaGVy IFJlcXVlc3RzKQ0KNCkgUmVnaXN0cmFyIFRMUyBjbGllbnQgaWRlbnRpdHkgdG93YXJkcyBNQVNB IHNlcnZlcg0KDQpGb3IgIzEsIEFDTUUgY2xpZW50IGl0IGNvdWxkIHVzZSBhbnkgaWRlbnRpdHkg LyAnYWNjb3VudCcgdGhhdCB3YXMgYWJsZSB0byBwcm92ZSBjb250cm9sIG9mIHRoZSBETlMgZG9t YWluLCBzbyBpdCBjYW4gYmUgdW5yZWxhdGVkIHRvIG90aGVyIGlkZW50aXRpZXMuIA0KDQo+IDEp IGl0IGNvdWxkIHVzZSBhbiBSRkM4NTU1L0FDTUUgRUUgY2VydGlmaWNhdGUgdGhhdCBpdCBvYnRh aW5lZCBmb3IgaXRzZWxmLg0KPiAgICBJbiB0aGF0IGNhc2UsIHRoZSBjbWNSQSBiaXQgaXMgbW9z dCBsaWtlbHkgbm90IHNldC4NCj4gMikgaXQgY291bGQgaGF2ZSBhIHNlbGYtc2lnbmVkIEVFIGNl cnRpZmljYXRlLCB3aGVyZSB0aGUgY21jUkEgYml0IGNvdWxkIGluDQo+ICAgIGZhY3QgYmUgc2V0 LiB7V291bGQgaXQgaGF2ZSBhbnkgcmVhbCBtZWFuaW5nP30NCj4gMykgaXQgY291bGQgdXNlIGEg cmF3LXB1YmxpYy1rZXkuDQoNClRoZXNlIG9wdGlvbnMgY291bGQgYmUgY29uc2lkZXJlZCBmb3Ig dGhlIHNpZ25pbmcgaWRlbnRpdHkgIzM6DQoNCjEpIGl0IHdvdWxkbid0IHdvcmsgaWYgdGhlICdS QScgZmxhZyBpcyBub3Qgc2V0LiBUaGUgQlJTS0kgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlIGRlcGVu ZHMgb24gJ1JBJyBiZWluZyBzZXQgZm9yIFJlZ2lzdHJhcnMsIGFuZCBhbHNvIEFDUCBkb2VzLiBJ biBteSB2aWV3IGEgTUFTQSBNVVNUIGNoZWNrIGZvciAnUkEnLg0KMikgdGhpcyBjYW4gd29yaw0K MykgUmVnaXN0cmFyIHNpZ25zIHdpdGggYSBjZXJ0aWZpY2F0ZSBub3Qgd2l0aCBhIHJhdy1wdWJs aWMta2V5LiBBbmQgYSByYXctcHVibGljLWtleSBjYW5ub3QgaGF2ZSBhbiAnUkEnIGZsYWcgc2V0 LiBTbyB0aGF0IHdvdWxkbid0IHdvcmsNCg0KT3B0aW9uIDIpIGxvb2tzIGdvb2QgYXMgYW4gaWRl bnRpdHkgZm9yIHNpZ25pbmcgVm91Y2hlciBSZXF1ZXN0cy4gIEVpdGhlciBhIHNpbmdsZSBzZWxm c2lnbmVkIFJBK0NBIGNlcnQsIG9yIGEgY2hhaW4gb2YgdHdvOiBSQSAtPiBzZWxmLXNpZ25lZC1D QS4gVGhlIGxhdHRlciBpcyB1c2VmdWwgYXMgaXQgYWxsb3dzIGluIHRoZSBmdXR1cmUgbW9yZSBS ZWdpc3RyYXJzICh3aXRoIFJBIGZsYWcgc2V0KQ0KdG8gYmUgY3JlYXRlZCB3aXRoaW4gdGhlIHNh bWUgcHJpdmF0ZSBkb21haW4gKENBKS4gIE9mIGNvdXJzZSB0aGlzIGNlcnRpZmljYXRlIC8gY2hh aW4gbXVzdCB0aGVuIGJlIGNyZWF0ZWQgYnkgaGFuZCBpLmUuIGl0IGNhbm5vdCBiZSBhdXRvbWF0 ZWQgdXNpbmcgQUNNRS4gIERvIHlvdSBzZWUgdGhpcyBhcyBhIHByb2JsZW0/IFRvIG1lIGl0IHNl ZW1zIGFjY2VwdGFibGUuDQoNCkRldGFpbHMgb2YgdGhpcyBzb2x1dGlvbjogTUFTQSB3aWxsIGFj Y2VwdCB0aGUgYWJvdmUgc2lnbmluZyAoc2luY2UgJ1JBJyBpcyBzZXQgLSBjaGVjayBwYXNzZXMp IGFuZCB3aWxsIHBpbiBvbmUgb2YgdGhlc2UgY2VydHMuIFRoZSBQbGVkZ2Ugd2lsbCB0b28gYWNj ZXB0IGFzIHBlciBCUlNLSSA1LjYuMiBiZWNhdXNlIHRoZSBSZWdpc3RyYXIncyBjZXJ0IGlzIGVp dGhlciBlcXVhbCB0bywgb3IgY2hhaW5zIHRvLCB0aGUgcGlubmVkLWRvbWFpbi1jZXJ0Lg0KVGhl IFBsZWRnZSB3aWxsIGRvIGFmdGVyIEJSU0tJLXNwZWNpZmljIGJvb3RzdHJhcCBvcGVyYXRpb25z IHRoZSBHRVQgL2NhY2VydHMgKFNlY3Rpb24gNS45LjEpIGFuZCB0aGUgUmVnaXN0cmFyIHRoZW4g c2VydmVzIGJhY2sgMiBDQXM6IHsgc2VsZi1zaWduZWQgQ0EgLCAgQUNNRSBDQSB9IC4gIFRoZSBQ bGVkZ2Ugd2lsbCB0aGVuIGRvIEVTVCBlLmcuIC9zaW1wbGVlbnJvbGwgd2l0aCBSZWdpc3RyYXI7 IGFuZCBSZWdpc3RyYXIgDQptZWFud2hpbGUgaW50ZXJmYWNlcyBhcyBhIGNsaWVudCB3aXRoIHRo ZSBBQ01FIHNlcnZlciB0byBvYnRhaW4gIGEgbmV3IG9wZXJhdGlvbmFsIGRvbWFpbiBjZXJ0IGZv ciB0aGUgUGxlZGdlIHVuZGVyIHRoZSBETlMgZG9tYWluIG93bmVkIGJ5IHRoZSBSZWdpc3RyYXIu IFRoZSBQbGVkZ2UgY2FuIHZlcmlmeSB0aGlzIG5ldyBjZXJ0IGFnYWluc3QgaXRzIHRydXN0IHN0 b3JlIHRoYXQgbm93IGNvbnRhaW5zIHRoZSANCnR3byBDQXM6IHsgc2VsZi1zaWduZWQgQ0EgLCAg QUNNRSBDQSB9ICwgc28gaXQgd2lsbCB2YWxpZGF0ZS4gIE5vdGUgdGhhdCB0aGUgUmVnaXN0cmFy IGVucm9sbHMgdGhlIFBsZWRnZSBpbnRvIGEgZG9tYWluICh3aXRoIEFDTUUtaXNzdWVkIGNlcnQp IHRoYXQgdGhlIE1BU0Ega25vd3Mgbm90aGluZyBhYm91dCEgIEkgYXNzdW1lIHRoaXMgaXMgYWxs b3dlZCBieSBCUlNLSSBhcyBJIHJlYWQgdGhhdCB0aGUgUGxlZGdlIGlzDQpzdXBwb3NlZCB0byBp bnN0YWxsIHRoZSAvY2FjZXJ0cyByZXNwb25zZSBpbiBpdHMgdHJ1c3Qgc3RvcmUuIA0KDQpOb3cg aWYgYWJvdmUgc29sdXRpb24gb3B0aW9uIDIpIHdvcmtzIHdpdGggQUNNRSwgdGhlcmUgc2VlbXMg dG8gYmUgbm8gbmVlZCB0byByZXF1ZXN0IGNlcnRzIHdpdGggJ1JBJyBzZXQgZnJvbSB0aGUgQUNN RSBDQS4gIFRoZSAnUkEnIGNlcnRzIGFyZSB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgUmVnaXN0 cmFyJ3MgcHJpdmF0ZSBkb21haW4uIFRoZSBhdXRvLWNyZWF0ZWQgRUUgY2VydHMgYXJlIGNyZWF0 ZWQNCmJ5IHRoZSBBQ01FIENBIHVuZGVyIGNvbnRyb2wgb2YgUmVnaXN0cmFyLiAgDQoNCk9yIHdv dWxkIHRoZXJlIHN0aWxsIGJlIHNvbWUgbmVlZCB0byB1c2Ugb3B0aW9uIDEpIGFuZCB1cGRhdGUg dGhlIEFDTUUgUkZDIHRvIGVuYWJsZSBBQ01FIENBIGhhbmRpbmcgb3V0IGNlcnRzIHdpdGggY21j UkEgc2V0Pw0KDQo+IE9uZSB0aGluZyB0aGF0IG9jY3VycyB0byBtZSB0aGF0IGEgcGxlZGdlIHdo aWNoICpjYW4qIGZvcm0gYW4gQUNQLCBwcm9iYWJseQ0KPiBzaG91bGQgKm5vdCogaWYgdGhlIGNt Y1JBIGJpdCBpcyBub3Qgc2V0LiAgDQoNCkFzIHNhaWQgYWJvdmUgdGhlIEJSU0tJIHNlY3VyaXR5 IGFyY2hpdGVjdHVyZSBkZXBlbmRzIG9uICdSQScgYmVpbmcgc2V0IGZvciBSZWdpc3RyYXJzLCBh bmQgYWxzbyBBQ1AgZG9lcy4gU28gaXQgc2VlbXMgcmlza3kgdG8gYXNzdW1lIHNpdHVhdGlvbnMg aW4gd2hpY2ggaXQgaXMgbm90IHNldCBhbmQgTUFTQSBsZXRzIHRoZSBib290c3RyYXAgY29udGlu dWUuDQpTbyB0aGUgUGxlZGdlIGRvZXNuJ3QgbmVlZCB0byBldmFsdWF0ZSBpZiBjbWNSQSBpcyBw cmVzZW50IC0gYmVjYXVzZSB0aGUgYm9vdHN0cmFwIHdvdWxkbid0IHN1Y2NlZWQgaW4gdGhlIGZp cnN0IHBsYWNlIGlmIGNtY1JBIGlzIGFic2VudCwgcmlnaHQ/IE9yIGRvIEkgbWlzcyBzb21ldGhp bmcuDQoNCkJlc3QgcmVnYXJkcw0KRXNrbw0KDQpJb1Rjb25zdWx0YW5jeS5ubCAgfCAgRW1haWwv VGVhbXM6IGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubCANCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEFuaW1hIDxhbmltYS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgTWljaGFlbCBSaWNoYXJkc29uDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDQsIDIwMjAgMjE6 MzMNClRvOiBhbmltYUBpZXRmLm9yZzsgYWNtZUBpZXRmLm9yZzsgaW90LW9uYm9hcmRpbmdAaWV0 Zi5vcmc7IGlvdG9wc0BpZXRmLm9yZzsgbGFtcHNAaWV0Zi5vcmcNCkNjOiBNYXggUHJpdGlraW4g KHByaXRpa2luKSA8cHJpdGlraW5AY2lzY28uY29tPg0KU3ViamVjdDogW0FuaW1hXSBBQ01FIGlu dGVncmF0aW9ucyB3aXRoIEJSU0tJIGFuZCB0aGUgY21jUkEgRUtVDQoNCg== From nobody Mon Dec 7 06:43:42 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1C3A13F7 for ; Mon, 7 Dec 2020 06:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu 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 j2LQTzLsVTFd for ; Mon, 7 Dec 2020 06:43:37 -0800 (PST) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (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 284E13A13F4 for ; Mon, 7 Dec 2020 06:43:37 -0800 (PST) Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B7EgEjY031449 for ; Mon, 7 Dec 2020 09:43:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=pFBdmRO466xkBuJ+GH/w1k2euHTfQg6iBJxXk4OP6mM=; b=Se8zsGfN/aRZprCob8vxSwXUjaor9NHWpCx9Bp4d3pjMtgK2+E+g+Uya31UG4cagg639 Nax4NuwoFaWThWqu/FD0hjnJGQ8NAUG7WwOf6GsMFUT/unKTzFW5jS5glV+KT5skdAZa qZy9N5dGvibkIvEc4ECGpDP7yt54HlIFb2ZFwXQ4Bh6dUvoPIAgxZsyWVEo9LiJNVAV3 7pJAC7KlOcPAHT8Xk5vkiAoLpiF+kQmkE5g2p8r85GwLyoJZ30v0mEzy+5PCB1GJQFQD FP8GkfZHM6d5SqnnpAFXAij7yLuZRs2+69DSH3QtzSbD7FWrBuE587wzfG6l/NudtE3d zw== Received: from sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0a-00364e01.pphosted.com with ESMTP id 3587901qc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 Dec 2020 09:43:36 -0500 Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B7EhZce014051 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 7 Dec 2020 09:43:35 -0500 Received: by mail-qv1-f70.google.com with SMTP id t16so7375936qvk.13 for ; Mon, 07 Dec 2020 06:43:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFBdmRO466xkBuJ+GH/w1k2euHTfQg6iBJxXk4OP6mM=; b=jQZWtiWQDm7T4pa2MVZ8Bji+U9w408PZurvjlL9TTLZ2foBG67q9FAA8dEIdZKRQ8f gE+FAD73VUdT7c2twAh2ZwifD1g5So/+cqRcc/pL5FC8sn4OzGDjQQClJIMTOPkoBTlF t+syui4/8+nJZ345oZPS1DVVfFeNa5jpui70FgqGuFhG9ToG17ePEA5hn2uprZ5bds5t ZHfEuwZuskVxtK2y++TzHPEAOS99X/pmOuK8VBC23qWBVWRN1fUv9Zh1tgTBpKBYr0Jt LqWwpvkcOJizRG3ZDhVPu9MDVjd5z/rczKSXxFurDm5mFr8or6NZdm3OsePEhr2/0u2V qvdQ== X-Gm-Message-State: AOAM5327dGLhQSbBCyEcJEyDyl8HAU+P2EtpjOSB2zbfxKcMqnSWf4/C 7ykpC7QFb1szABrpe9x3yt6jTEnh+X7ZaFV5W3xBu7Fi51bw1T8SnQmjW7FJ+kcCdUkhiGglfz1 2r5pUweVtADtk1YX3kp9PYc0QReczhCE= X-Received: by 2002:a05:620a:2296:: with SMTP id o22mr24565517qkh.261.1607352214688; Mon, 07 Dec 2020 06:43:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyf3e4kna/2FCZBL2LdX89NmMbdYMf3oq9ZCT4QljJM5+bmJ7Bh9Y6SghEpmAVqJMtbJ8Nc633TZKfmxgtoAso= X-Received: by 2002:a05:620a:2296:: with SMTP id o22mr24565471qkh.261.1607352214180; Mon, 07 Dec 2020 06:43:34 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> From: Henning Schulzrinne Date: Mon, 7 Dec 2020 09:43:07 -0500 Message-ID: To: Toerless Eckert Cc: Amyas Phillips , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Randy Bush , "Ackermann, Michael" Content-Type: multipart/alternative; boundary="000000000000c16a0705b5e0d99f" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_11:2020-12-04, 2020-12-07 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 bulkscore=10 mlxlogscore=999 clxscore=1011 impostorscore=10 spamscore=0 priorityscore=1501 lowpriorityscore=10 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012070093 Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 14:43:40 -0000 --000000000000c16a0705b5e0d99f Content-Type: text/plain; charset="UTF-8" It used to be that vendors announced end-of-life for products years after introduction. For example, there was no way for a purchaser of Windows NT to know, at purchase time, how long Microsoft was intending to support the operating system. Now, better vendors seem to have started to make some commitments, e.g., "this Android phone will receive new versions of the OS for three releases and security updates until 2025". All the major Linux distributions now have some kind of an LTS version, with long-term stability and security/bug upgrades planned. There have been proposals (in the UK?) of making vendors of IoT equipment state their support commitment, so that a purchaser can choose "cheap" or "lasts a lifetime". Unfortunately, industry advocacy is often for minimal regulation - there's an opportunity here for ISOC and others to make a difference. One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina) broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my printer working. Dell, the distributor of the printers (made by Fuji-Xerox, apparently) simply states that "due to circumstances beyond their control", they won't be providing any Catalina/Big Sur printer drivers. Given that most commercial systems are now assembled out of open-source components, with customization or glue on top, you'd want some kind of automated component checker. "17 of your components have not committed to long-term support. Are you prepared to fix them yourselves?" I don't know if this is feasible in all cases, but I suspect we often know that certain technologies are getting long in the tooth. They are not quite obsolete (historic) yet, but there's no active development or community and they probably shouldn't be components that can't be replaced in the field. No need (or resources) to do this for every RFC, but identifying critical pieces of technology and providing a support roadmap would be helpful, I think. On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > Great pportunity for a rant: > > Its easy to understand how the mayority of participants in these > discussions are > from either a commercial supplier side, or from a commercial user side. In > either > case, a clearly time restricted use case scenario is easily be most > important default. > This btw. also applies to where my pay check comes from (i think). > > Nevertheless, i would highly recommend to no limit our design decisions to > this > scenarios. > > Personally, i for once would be happy as an individual to see any > standards be > blackmailed in the press and in public as an evil conspiracy for planned > obsolescence > that does not consider the ability for devices to operate as long as their > hardware can > without being constrained by 'security' software. > > Obviously, there are also significant commercial applications undetermined > long > life cycles are required. Just think of any deep space exploration NASA > satellites > go dark because of their non-crypto agility. Or the non-desire to upgrade > nuclear > missile control systems to new HW/SW because overall system security > analysis > shows how new HW/SW more likely than not will be MORE susceptible to > attacks than > simpler older SW/HW around for 50 years. Just two extreme examples. > > I am not 10% sure about generic approaches to solve this problem, but one > approach > could be the following: > > - A device communications is designed to be able to operate solely within a > "walled garden" environment. Not as the ONLY option, but as one option. > > - Walled garden means that all communication channels of the device can be > directed > to go through other nodes of the "walled garden". > > - "Walled garden" should IMHO also mean that the higher layer semantic of > all communications is well enough defined/documented, so that another > device > in the walled-garden can be set up to convert/proxy the communications. > > - Aka: If the crypto starts to become obsolete, then the obsolete crypto > would > be possible to constrain to the walled-carden (physical security) > environment, > and be proxied, and if the original remote communication parties do not > exist > anymore, but the data to be exchanged exists, then such a proxy could > also > proxy/convert the data into the 'legacy' format. > > The ability to understand all the information communicated well enough to > be able > to re-recreate the format is also necessary for any type of higher-layer > security > filtering, so this type of communications design is not only good for > longevity, > but also for security beyond transit confidentiality. > > Cheers > Toerless > > On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > > > to improve the math one would have to amortize the cost of maintenance > > > over many many flavors and makers of thingies. so the acme thingie > mfr, > > > and the hackme thingie mfr, and the ... need to have a common code base > > > and upgrade infrastructure. > > > > > > Exactly right, it???s hard to imagine any other economically viable way > of maintaining devices which aren???t sold with a service contract. Even > for devices which are sold with a service contract, this is still a cheaper > and likely better way of delivering the security maintenance part of that > service. > > > > There???s a few commercial products which do this. They essentially > offer modules with an OS and application environment which they maintain > for you, to a more or less hands-off degree: msoft Sphere, Balena, > Particle, Electric Imp, Ubuntu Core. They don???t maintain your application > but that may well be a relatively small part of the attack surface, and > possibly defended by features of the maintained environment. > > > > Microsoft Sphere in particular is interesting because the maintenance is > completely hands off and the costs are folded into the initial BOM cost of > the module, there???s no service fee. > > > > Amyas > > > -- > > Iotops mailing list > > Iotops@ietf.org > > https://www.ietf.org/mailman/listinfo/iotops > > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000c16a0705b5e0d99f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It used to be that vendors announced end-of-life for = products years after introduction. For example, there was no way for a purc= haser of Windows NT to know, at purchase time, how long Microsoft was inten= ding to support the operating system. Now, better vendors seem to have star= ted to make some commitments, e.g., "this Android phone will receive n= ew versions of the OS for three releases and security updates until 2025&qu= ot;. All the major Linux distributions now have some kind of an LTS version= , with long-term stability and security/bug upgrades planned. There have be= en proposals (in the UK?) of making vendors of IoT equipment state their su= pport commitment, so that a purchaser can choose "cheap" or "= ;lasts a lifetime". Unfortunately, industry advocacy is often for mini= mal regulation - there's an opportunity here for ISOC and others to mak= e a difference.

One reason for not upgrading: OS d= ependencies. Apple Big Sur (and Catalina) broke a lot of printer drivers, s= o I had a choice: Upgrade my OS or keep my printer working. Dell, the distr= ibutor of the printers (made by Fuji-Xerox, apparently) simply states that = "due to circumstances beyond their control", they won't be pr= oviding any Catalina/Big Sur printer drivers.

Give= n that most commercial systems are now assembled out of open-source compone= nts, with customization or glue on top, you'd want some kind of automat= ed component checker. "17 of your components have not committed to lon= g-term support. Are you prepared to fix them yourselves?"
I don't know if this is feasible in all cases, but I suspe= ct we often know that certain technologies are getting long in the tooth. T= hey are not quite obsolete (historic) yet, but there's no active develo= pment or community and they probably shouldn't be components that can&#= 39;t be replaced in the field. No need (or resources) to do this for every = RFC, but identifying critical pieces of technology and providing a support = roadmap would be helpful, I think.

On Mon, Dec 7, 2020 at 4:19 AM Toerless E= ckert <tte@cs.fau.de> wrote:
=
Great pportunity fo= r a rant:

Its easy to understand how the mayority of participants in these discussion= s are
from either a commercial supplier side, or from a commercial user side. In = either
case, a clearly time restricted use case scenario is easily be most importa= nt default.
This btw. also applies to where my pay check comes from (i think).

Nevertheless, i would highly recommend to no limit our design decisions to = this
scenarios.

Personally, i for once would be happy as an individual to see any standards= be
blackmailed in the press and in public as an evil conspiracy for planned ob= solescence
that does not consider the ability for devices to operate as long as their = hardware can
without being constrained by 'security' software.

Obviously, there are also significant commercial applications undetermined = long
life cycles are required. Just think of any deep space exploration NASA sat= ellites
go dark because of their non-crypto agility. Or the non-desire to upgrade n= uclear
missile control systems to new HW/SW because overall system security analys= is
shows how new HW/SW more likely than not will be MORE susceptible to attack= s than
simpler older SW/HW around for 50 years. Just two extreme examples.

I am not 10% sure about generic approaches to solve this problem, but one a= pproach
could be the following:

- A device communications is designed to be able to operate solely within a=
=C2=A0 "walled garden" environment. Not as the ONLY option, but a= s one option.

- Walled garden means that all communication channels of the device can be = directed
=C2=A0 to go through other nodes of the "walled garden".

- "Walled garden" should IMHO also mean that the higher layer sem= antic of
=C2=A0 all communications is well enough defined/documented, so that anothe= r device
=C2=A0 in the walled-garden can be set up to convert/proxy the communicatio= ns.

- Aka: If the crypto starts to become obsolete, then the obsolete crypto wo= uld
=C2=A0 be possible to constrain to the walled-carden (physical security) en= vironment,
=C2=A0 and be proxied, and if the original remote communication parties do = not exist
=C2=A0 anymore, but the data to be exchanged exists, then such a proxy coul= d also
=C2=A0 proxy/convert the data into the 'legacy' format.

The ability to understand all the information communicated well enough to b= e able
to re-recreate the format is also necessary for any type of higher-layer se= curity
filtering, so this type of communications design is not only good for longe= vity,
but also for security beyond transit confidentiality.

Cheers
=C2=A0 =C2=A0 Toerless

On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote:
>
> > On 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:
> >
> > to improve the math one would have to amortize the cost of mainte= nance
> > over many many flavors and makers of thingies.=C2=A0 so the acme = thingie mfr,
> > and the hackme thingie mfr, and the ... need to have a common cod= e base
> > and upgrade infrastructure.=C2=A0
>
>
> Exactly right, it???s hard to imagine any other economically viable wa= y of maintaining devices which aren???t sold with a service contract. Even = for devices which are sold with a service contract, this is still a cheaper= and likely better way of delivering the security maintenance part of that = service.
>
> There???s a few commercial products which do this. They essentially of= fer modules with an OS and application environment which they maintain for = you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, El= ectric Imp, Ubuntu Core. They don???t maintain your application but that ma= y well be a relatively small part of the attack surface, and possibly defen= ded by features of the maintained environment.
>
> Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM cost = of the module, there???s no service fee.
>
> Amyas

> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000c16a0705b5e0d99f-- From nobody Mon Dec 7 08:44:02 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301703A12E7 for ; Mon, 7 Dec 2020 08:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=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 yTq31S0VliTa for ; Mon, 7 Dec 2020 08:43:51 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 EDC5A3A146B for ; Mon, 7 Dec 2020 08:43:50 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id cm17so14447590edb.4 for ; Mon, 07 Dec 2020 08:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xp6fVrKPalQphE4abU7DWfbY+FeqHSd6/tNq/UNw1ic=; b=g6N3tepOJ9IdSR8DR6L312bcz/CqyKa1EggQnQekJ1UXAUlPQ4t29vqmTMZCRuMPO8 pF/pX6HmmT39hzI3JH3bpHf5hIbRdkUfXLbnxWfxPiF1r4W5xL3a1vppUd+ZS0DIUJx9 Bx66aP6qg0pumkhPK6c8NMzpAob9KZNUSih/ChZd0G5xXossWT0WgFsVZA+2X3BSF5Ih fiu4Su0AhMRrzFaujuIpLOgf+wu+Xtez2L+swO4kDFHnUqKz+dx56Lc5Cb8tokTfM8L4 WRwomYohCGZgZJWGLFljfawwmuzo3PKbfkE0MTdjhKz0mu/Kk79lT6HnhRGtwBGbRgra McUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xp6fVrKPalQphE4abU7DWfbY+FeqHSd6/tNq/UNw1ic=; b=J0IzVhodueBV9aBSVpHhGFwZvHDNnbPW28IlaH9sMeB5iUaCqaol9RFXYWe0PTRSHA 6jAiLUi7kw9MFv0FTXrS9DEM20mft0H7qpBD8Y7V/B+VkqUhhT9Z1C4yYUDFUFzlJCqM iF9zG6bO8UfCbWjRJJZXNj1ijltvqIF46Ijo2jopLLL8x5uIP6ttfrh+HAmCBf9XS6PG 7h+8jesk9zZgR1vNEebhMKHX/bJ5la0YcaVBsXVUTEglkdij8A4Se4kna25/Ooco6j8A LV7MZwQAc0ls5yCDv6Z6AY+NHrUZMsYU9RZ1ZjDX1IAgv4/cYxMU043jIZzExjCHcoFd IkZg== X-Gm-Message-State: AOAM531QthVXQlZTtUZeCs2mUE3iD/YYTwzEs5CvuPzUbLrE7JK3nXLL uuV1eEnhwvCfs1BDc6mYwtuusKg+TLLcH53jtEU= X-Google-Smtp-Source: ABdhPJxNH+X+pxy8ofJcryFo59eO+xmVZP26gyODPf/4oX+PAoOmCrM2kFM95qXRiwxIqKe2Zr3LzK/MqXUK31w8HhI= X-Received: by 2002:aa7:c3cf:: with SMTP id l15mr10960081edr.282.1607359429107; Mon, 07 Dec 2020 08:43:49 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: =?UTF-8?B?U8OhdnlvIFZpbsOtY2l1cw==?= Date: Mon, 7 Dec 2020 13:43:37 -0300 Message-ID: To: Henning Schulzrinne Cc: Toerless Eckert , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Amyas Phillips , Randy Bush , "Ackermann, Michael" Content-Type: multipart/alternative; boundary="000000000000cc646605b5e2873c" Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:43:56 -0000 --000000000000cc646605b5e2873c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another point we need to pay attention to is the situation of the SMEs running in the local market of in-development-countries. These companies are in a vulnerable position and can, after just launching a device, close due to bankruptcy, shortening the device update life cycle. People who just bought the device will not just discard the expensive device, even knowing about the risks -- when the most probable is they never know about them. I really believe in the efficacy of an open source-based approach, but there is a long way to develop a consistent framework (including community, regulation, best practices, and other relevant stuff) to do it. Still in this context, regulatory approaches need much attention because they can be restrictive to those companies, and contribute to more bankruptcies. Another approach that can be taken is by creating a kind of contractual best practices (maybe informational RFCs?) for advising different sectors on what kind of terms they need to care about when building or buying solutions. But this brings the challenge of how to make this information reach the intended targets that are out of the IETF scope. Em seg., 7 de dez. de 2020 =C3=A0s 11:43, Henning Schulzrinne < hgs@cs.columbia.edu> escreveu: > It used to be that vendors announced end-of-life for products years after > introduction. For example, there was no way for a purchaser of Windows NT > to know, at purchase time, how long Microsoft was intending to support th= e > operating system. Now, better vendors seem to have started to make some > commitments, e.g., "this Android phone will receive new versions of the O= S > for three releases and security updates until 2025". All the major Linux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposals (i= n > the UK?) of making vendors of IoT equipment state their support commitmen= t, > so that a purchaser can choose "cheap" or "lasts a lifetime". > Unfortunately, industry advocacy is often for minimal regulation - there'= s > an opportunity here for ISOC and others to make a difference. > > One reason for not upgrading: OS dependencies. Apple Big Sur (and > Catalina) broke a lot of printer drivers, so I had a choice: Upgrade my O= S > or keep my printer working. Dell, the distributor of the printers (made b= y > Fuji-Xerox, apparently) simply states that "due to circumstances beyond > their control", they won't be providing any Catalina/Big Sur printer > drivers. > > Given that most commercial systems are now assembled out of open-source > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committed to > long-term support. Are you prepared to fix them yourselves?" > > I don't know if this is feasible in all cases, but I suspect we often kno= w > that certain technologies are getting long in the tooth. They are not qui= te > obsolete (historic) yet, but there's no active development or community a= nd > they probably shouldn't be components that can't be replaced in the field= . > No need (or resources) to do this for every RFC, but identifying critical > pieces of technology and providing a support roadmap would be helpful, I > think. > > On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > >> Great pportunity for a rant: >> >> Its easy to understand how the mayority of participants in these >> discussions are >> from either a commercial supplier side, or from a commercial user side. >> In either >> case, a clearly time restricted use case scenario is easily be most >> important default. >> This btw. also applies to where my pay check comes from (i think). >> >> Nevertheless, i would highly recommend to no limit our design decisions >> to this >> scenarios. >> >> Personally, i for once would be happy as an individual to see any >> standards be >> blackmailed in the press and in public as an evil conspiracy for planned >> obsolescence >> that does not consider the ability for devices to operate as long as >> their hardware can >> without being constrained by 'security' software. >> >> Obviously, there are also significant commercial applications >> undetermined long >> life cycles are required. Just think of any deep space exploration NASA >> satellites >> go dark because of their non-crypto agility. Or the non-desire to upgrad= e >> nuclear >> missile control systems to new HW/SW because overall system security >> analysis >> shows how new HW/SW more likely than not will be MORE susceptible to >> attacks than >> simpler older SW/HW around for 50 years. Just two extreme examples. >> >> I am not 10% sure about generic approaches to solve this problem, but on= e >> approach >> could be the following: >> >> - A device communications is designed to be able to operate solely withi= n >> a >> "walled garden" environment. Not as the ONLY option, but as one option= . >> >> - Walled garden means that all communication channels of the device can >> be directed >> to go through other nodes of the "walled garden". >> >> - "Walled garden" should IMHO also mean that the higher layer semantic o= f >> all communications is well enough defined/documented, so that another >> device >> in the walled-garden can be set up to convert/proxy the communications= . >> >> - Aka: If the crypto starts to become obsolete, then the obsolete crypto >> would >> be possible to constrain to the walled-carden (physical security) >> environment, >> and be proxied, and if the original remote communication parties do no= t >> exist >> anymore, but the data to be exchanged exists, then such a proxy could >> also >> proxy/convert the data into the 'legacy' format. >> >> The ability to understand all the information communicated well enough t= o >> be able >> to re-recreate the format is also necessary for any type of higher-layer >> security >> filtering, so this type of communications design is not only good for >> longevity, >> but also for security beyond transit confidentiality. >> >> Cheers >> Toerless >> >> On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: >> > >> > > On 5 Dec 2020, at 18:10, Randy Bush wrote: >> > > >> > > to improve the math one would have to amortize the cost of maintenan= ce >> > > over many many flavors and makers of thingies. so the acme thingie >> mfr, >> > > and the hackme thingie mfr, and the ... need to have a common code >> base >> > > and upgrade infrastructure. >> > >> > >> > Exactly right, it???s hard to imagine any other economically viable wa= y >> of maintaining devices which aren???t sold with a service contract. Even >> for devices which are sold with a service contract, this is still a chea= per >> and likely better way of delivering the security maintenance part of tha= t >> service. >> > >> > There???s a few commercial products which do this. They essentially >> offer modules with an OS and application environment which they maintain >> for you, to a more or less hands-off degree: msoft Sphere, Balena, >> Particle, Electric Imp, Ubuntu Core. They don???t maintain your applicat= ion >> but that may well be a relatively small part of the attack surface, and >> possibly defended by features of the maintained environment. >> > >> > Microsoft Sphere in particular is interesting because the maintenance >> is completely hands off and the costs are folded into the initial BOM co= st >> of the module, there???s no service fee. >> > >> > Amyas >> >> > -- >> > Iotops mailing list >> > Iotops@ietf.org >> > https://www.ietf.org/mailman/listinfo/iotops >> >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --000000000000cc646605b5e2873c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another point we need to pay attention to is the situation= of the SMEs running in the local market of in-development-countries.
Th= ese companies are in a vulnerable position and can, after just launching a = device, close due to bankruptcy, shortening the device update life cycle.People who just bought the device will not just discard the expensive dev= ice, even knowing about the risks -- when the most probable is they never k= now about them.

I really believe in the efficacy of an open source-b= ased approach, but there is a long way to develop a consistent framework (i= ncluding community, regulation, best practices, and other relevant stuff) t= o do it.
Still in this context, regulatory approaches need much attentio= n because they can be restrictive to those companies, and contribute to mor= e bankruptcies.

Another approach that can be taken is by creating a = kind of contractual best practices (maybe informational RFCs?) for advising= different sectors on what kind of terms they need to care about when build= ing or buying solutions. But this brings the challenge of how to make this = information reach the intended targets that are out of the IETF scope.
<= div>

Em seg., 7 de dez. de 2020 =C3=A0s 11:43, Henning Schulzrinne <= ;hgs@cs.columbia.edu> escreve= u:
It used to be that vendors announced end-of-life for products year= s after introduction. For example, there was no way for a purchaser of Wind= ows NT to know, at purchase time, how long Microsoft was intending to suppo= rt the operating system. Now, better vendors seem to have started to make s= ome commitments, e.g., "this Android phone will receive new versions o= f the OS for three releases and security updates until 2025". All the = major Linux distributions now have some kind of an LTS version, with long-t= erm stability and security/bug upgrades planned. There have been proposals = (in the UK?) of making vendors of IoT equipment state their support commitm= ent, so that a purchaser can choose "cheap" or "lasts a life= time". Unfortunately, industry advocacy is often for minimal regulatio= n - there's an opportunity here for ISOC and others to make a differenc= e.

One reason for not upgrading: OS dependencies. = Apple Big Sur (and Catalina) broke a lot of printer drivers, so I had a cho= ice: Upgrade my OS or keep my printer working. Dell, the distributor of the= printers (made by Fuji-Xerox, apparently) simply states that "due to = circumstances beyond their control", they won't be providing any C= atalina/Big Sur printer drivers.

Given that most c= ommercial systems are now assembled out of open-source components, with cus= tomization or glue on top, you'd want some kind of automated component = checker. "17 of your components have not committed to long-term suppor= t. Are you prepared to fix them yourselves?"

= I don't know if this is feasible in all cases, but I suspect we often k= now that certain technologies are getting long in the tooth. They are not q= uite obsolete (historic) yet, but there's no active development or comm= unity and they probably shouldn't be components that can't be repla= ced in the field. No need (or resources) to do this for every RFC, but iden= tifying critical pieces of technology and providing a support roadmap would= be helpful, I think.

On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert <tte@cs.fau.de> wrote= :
Great pportuni= ty for a rant:

Its easy to understand how the mayority of participants in these discussion= s are
from either a commercial supplier side, or from a commercial user side. In = either
case, a clearly time restricted use case scenario is easily be most importa= nt default.
This btw. also applies to where my pay check comes from (i think).

Nevertheless, i would highly recommend to no limit our design decisions to = this
scenarios.

Personally, i for once would be happy as an individual to see any standards= be
blackmailed in the press and in public as an evil conspiracy for planned ob= solescence
that does not consider the ability for devices to operate as long as their = hardware can
without being constrained by 'security' software.

Obviously, there are also significant commercial applications undetermined = long
life cycles are required. Just think of any deep space exploration NASA sat= ellites
go dark because of their non-crypto agility. Or the non-desire to upgrade n= uclear
missile control systems to new HW/SW because overall system security analys= is
shows how new HW/SW more likely than not will be MORE susceptible to attack= s than
simpler older SW/HW around for 50 years. Just two extreme examples.

I am not 10% sure about generic approaches to solve this problem, but one a= pproach
could be the following:

- A device communications is designed to be able to operate solely within a=
=C2=A0 "walled garden" environment. Not as the ONLY option, but a= s one option.

- Walled garden means that all communication channels of the device can be = directed
=C2=A0 to go through other nodes of the "walled garden".

- "Walled garden" should IMHO also mean that the higher layer sem= antic of
=C2=A0 all communications is well enough defined/documented, so that anothe= r device
=C2=A0 in the walled-garden can be set up to convert/proxy the communicatio= ns.

- Aka: If the crypto starts to become obsolete, then the obsolete crypto wo= uld
=C2=A0 be possible to constrain to the walled-carden (physical security) en= vironment,
=C2=A0 and be proxied, and if the original remote communication parties do = not exist
=C2=A0 anymore, but the data to be exchanged exists, then such a proxy coul= d also
=C2=A0 proxy/convert the data into the 'legacy' format.

The ability to understand all the information communicated well enough to b= e able
to re-recreate the format is also necessary for any type of higher-layer se= curity
filtering, so this type of communications design is not only good for longe= vity,
but also for security beyond transit confidentiality.

Cheers
=C2=A0 =C2=A0 Toerless

On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote:
>
> > On 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:
> >
> > to improve the math one would have to amortize the cost of mainte= nance
> > over many many flavors and makers of thingies.=C2=A0 so the acme = thingie mfr,
> > and the hackme thingie mfr, and the ... need to have a common cod= e base
> > and upgrade infrastructure.=C2=A0
>
>
> Exactly right, it???s hard to imagine any other economically viable wa= y of maintaining devices which aren???t sold with a service contract. Even = for devices which are sold with a service contract, this is still a cheaper= and likely better way of delivering the security maintenance part of that = service.
>
> There???s a few commercial products which do this. They essentially of= fer modules with an OS and application environment which they maintain for = you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, El= ectric Imp, Ubuntu Core. They don???t maintain your application but that ma= y well be a relatively small part of the attack surface, and possibly defen= ded by features of the maintained environment.
>
> Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM cost = of the module, there???s no service fee.
>
> Amyas

> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--
Iotops mailing list
Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops
--000000000000cc646605b5e2873c-- From nobody Mon Dec 7 08:49:18 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3F03A0FC2; Mon, 7 Dec 2020 08:49:15 -0800 (PST) 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 9Cr9p_DHfdTY; Mon, 7 Dec 2020 08:49:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 4F5383A12E7; Mon, 7 Dec 2020 08:49:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kmJgz-0002YG-Nu; Mon, 07 Dec 2020 16:48:53 +0000 Date: Mon, 07 Dec 2020 08:48:52 -0800 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?=22S=E1vyo_Vin=EDcius=22?= Cc: Henning Schulzrinne , Toerless Eckert , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Amyas Phillips , "Ackermann, Michael" In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:49:16 -0000 > I really believe in the efficacy of an open source-based approach, but > there is a long way to develop a consistent framework (including community, > regulation, best practices, and other relevant stuff) to do it. https://xkcd.com/2347/ From nobody Mon Dec 7 08:57:09 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9103A146B for ; Mon, 7 Dec 2020 08:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 IU_1Kn7eAOU7 for ; Mon, 7 Dec 2020 08:57:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB7B3A12E7 for ; Mon, 7 Dec 2020 08:57:00 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A5BA2549B45; Mon, 7 Dec 2020 17:56:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9F974440041; Mon, 7 Dec 2020 17:56:54 +0100 (CET) Date: Mon, 7 Dec 2020 17:56:54 +0100 From: Toerless Eckert To: Henning Schulzrinne Cc: Amyas Phillips , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Randy Bush , "Ackermann, Michael" Message-ID: <20201207165654.GF44833@faui48f.informatik.uni-erlangen.de> References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:57:04 -0000 When i buy a glass or marmelade, the packaging indicates all the ingredients and epecially also all aditives. So i can kinda be an educated consumer. I i am always thinking that i would like similar labelling for equivalent, especially about the (external) dependencies to continue operating the device. Yes, there are all type of devices, and you mention one extreme, which are general purpose devices (mobile phones). Even when i have an embedded device with android, the dependencies to keep it running will typically be much more constrained but difficult to understand for most users. Maybe an organization like IETF could first start to document the problem of such external dependencies. Taxonomy etc. pp. Starting with the most obvious problem of certificate management. Then dependencies against external protocol peers, possible cloud-services, crypto-agility... E.g.: If you had to decide between two different options for one type of device and you where worried about longevity: whats all the stuff you would need to know about it, and which pieces would make a difference. IMHO, this is all way too much in its infancy to think about regulation i think. Once three is a better and broader agreement as to what the best practices are for apsects in support of longevity... then one could think about supportive measures to encourage vendors. Cheers Toerless On Mon, Dec 07, 2020 at 09:43:07AM -0500, Henning Schulzrinne wrote: > It used to be that vendors announced end-of-life for products years after > introduction. For example, there was no way for a purchaser of Windows NT > to know, at purchase time, how long Microsoft was intending to support the > operating system. Now, better vendors seem to have started to make some > commitments, e.g., "this Android phone will receive new versions of the OS > for three releases and security updates until 2025". All the major Linux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposals (in > the UK?) of making vendors of IoT equipment state their support commitment, > so that a purchaser can choose "cheap" or "lasts a lifetime". > Unfortunately, industry advocacy is often for minimal regulation - there's > an opportunity here for ISOC and others to make a difference. > > One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina) > broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my > printer working. Dell, the distributor of the printers (made by Fuji-Xerox, > apparently) simply states that "due to circumstances beyond their control", > they won't be providing any Catalina/Big Sur printer drivers. > > Given that most commercial systems are now assembled out of open-source > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committed to > long-term support. Are you prepared to fix them yourselves?" > > I don't know if this is feasible in all cases, but I suspect we often know > that certain technologies are getting long in the tooth. They are not quite > obsolete (historic) yet, but there's no active development or community and > they probably shouldn't be components that can't be replaced in the field. > No need (or resources) to do this for every RFC, but identifying critical > pieces of technology and providing a support roadmap would be helpful, I > think. > > On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > > > Great pportunity for a rant: > > > > Its easy to understand how the mayority of participants in these > > discussions are > > from either a commercial supplier side, or from a commercial user side. In > > either > > case, a clearly time restricted use case scenario is easily be most > > important default. > > This btw. also applies to where my pay check comes from (i think). > > > > Nevertheless, i would highly recommend to no limit our design decisions to > > this > > scenarios. > > > > Personally, i for once would be happy as an individual to see any > > standards be > > blackmailed in the press and in public as an evil conspiracy for planned > > obsolescence > > that does not consider the ability for devices to operate as long as their > > hardware can > > without being constrained by 'security' software. > > > > Obviously, there are also significant commercial applications undetermined > > long > > life cycles are required. Just think of any deep space exploration NASA > > satellites > > go dark because of their non-crypto agility. Or the non-desire to upgrade > > nuclear > > missile control systems to new HW/SW because overall system security > > analysis > > shows how new HW/SW more likely than not will be MORE susceptible to > > attacks than > > simpler older SW/HW around for 50 years. Just two extreme examples. > > > > I am not 10% sure about generic approaches to solve this problem, but one > > approach > > could be the following: > > > > - A device communications is designed to be able to operate solely within a > > "walled garden" environment. Not as the ONLY option, but as one option. > > > > - Walled garden means that all communication channels of the device can be > > directed > > to go through other nodes of the "walled garden". > > > > - "Walled garden" should IMHO also mean that the higher layer semantic of > > all communications is well enough defined/documented, so that another > > device > > in the walled-garden can be set up to convert/proxy the communications. > > > > - Aka: If the crypto starts to become obsolete, then the obsolete crypto > > would > > be possible to constrain to the walled-carden (physical security) > > environment, > > and be proxied, and if the original remote communication parties do not > > exist > > anymore, but the data to be exchanged exists, then such a proxy could > > also > > proxy/convert the data into the 'legacy' format. > > > > The ability to understand all the information communicated well enough to > > be able > > to re-recreate the format is also necessary for any type of higher-layer > > security > > filtering, so this type of communications design is not only good for > > longevity, > > but also for security beyond transit confidentiality. > > > > Cheers > > Toerless > > > > On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > > > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > > > > > to improve the math one would have to amortize the cost of maintenance > > > > over many many flavors and makers of thingies. so the acme thingie > > mfr, > > > > and the hackme thingie mfr, and the ... need to have a common code base > > > > and upgrade infrastructure. > > > > > > > > > Exactly right, it???s hard to imagine any other economically viable way > > of maintaining devices which aren???t sold with a service contract. Even > > for devices which are sold with a service contract, this is still a cheaper > > and likely better way of delivering the security maintenance part of that > > service. > > > > > > There???s a few commercial products which do this. They essentially > > offer modules with an OS and application environment which they maintain > > for you, to a more or less hands-off degree: msoft Sphere, Balena, > > Particle, Electric Imp, Ubuntu Core. They don???t maintain your application > > but that may well be a relatively small part of the attack surface, and > > possibly defended by features of the maintained environment. > > > > > > Microsoft Sphere in particular is interesting because the maintenance is > > completely hands off and the costs are folded into the initial BOM cost of > > the module, there???s no service fee. > > > > > > Amyas > > > > > -- > > > Iotops mailing list > > > Iotops@ietf.org > > > https://www.ietf.org/mailman/listinfo/iotops > > > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- --- tte@cs.fau.de From nobody Mon Dec 7 08:59:12 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5C93A0C9A; Thu, 3 Dec 2020 13:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 0W8tpZpjjODp; Thu, 3 Dec 2020 13:05:07 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0703A0C97; Thu, 3 Dec 2020 13:05:05 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kkvmg-0000E3C; Thu, 3 Dec 2020 22:05:02 +0100 Message-Id: To: ipv6@ietf.org Cc: Michael Richardson , iotops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <3988.1607021519@localhost> In-reply-to: Your message of "Thu, 03 Dec 2020 13:51:59 -0500 ." <3988.1607021519@localhost> Date: Thu, 03 Dec 2020 22:04:59 +0100 Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2020 08:59:11 -0800 Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 21:05:09 -0000 >While there is a CableLabs spec that argues for stacked DHCPv6-PD (and it >was >presented in Homenet a few years back), to date, I'm aware of no deployed >home routers that operate a DHCPv6-PD server on their southbound interface. Some home routers do in fact provide DHCPv6-PD southbound. A colleague of mime got one with cable internet. I think the main limitation of that box was that it would only delegate one /64. From nobody Mon Dec 7 08:59:16 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89053A0930; Fri, 4 Dec 2020 02:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 97uSfrgn0JVH; Fri, 4 Dec 2020 02:51:56 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F723A091C; Fri, 4 Dec 2020 02:51:53 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kl8gf-0000EWC; Fri, 4 Dec 2020 11:51:41 +0100 Message-Id: To: ipv6@ietf.org Cc: Toerless Eckert , iotops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <695953.1606952552@dooku> <20201203174901.GW44833@faui48f.informatik.uni-erlangen.de> <36EA3F9D-A79D-4BC0-B894-54B7D3054476@fugue.com> <20201204064930.GY44833@faui48f.informatik.uni-erlangen.de> <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> In-reply-to: Your message of "Fri, 4 Dec 2020 09:57:38 +0100 ." <20201204085738.GZ44833@faui48f.informatik.uni-erlangen.de> Date: Fri, 04 Dec 2020 11:51:39 +0100 Archived-At: X-Mailman-Approved-At: Mon, 07 Dec 2020 08:59:11 -0800 Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 10:51:59 -0000 >To me the most simple model is around the following constraints/requirements: > > stub-router ----link --- infra-router > >a) stub-router and infra-router are potentially different admin, aka: > we do not want to use signaling between them such as a typical > link-state-routing protocol where you can not create good trust-domain > boundries within the topology. Dijkstra protos are a bit better, but > i think no one has tried to come up with good definitions for "internal" > trust boundaries. > >b) infra-router hands out prefix(es) to stub-router. It shouldn't have > anything to say about how stub-router uses them. So stub-router could > subtend sub-prefixes as it sees fit. Infra router does NOT accept > prefixes back from stub-router. Indeed. We need to have a model where there can be a 'core network' that either runs HNCP/Babel in the case of homes, small business or OSPF (or equiv) and static configuration in the case of entrerprise. Attached to those core routers are small trees that do not run a routing protocol, but use a hierarchical mechanism to obtain prefixes. A core router should provide the root of each tree with as many /64s as is needed to number the tree. We currently have a mechanisms for the hierarchical part, which is DHCPv6 PD. It is far from ideal, but we can try to specify how it should be deployed. Of course, this assumes that the core network has enough address space to number all of the trees. From nobody Mon Dec 7 10:23:12 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0413A1649; Mon, 7 Dec 2020 10:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvixzi3o3wja; Mon, 7 Dec 2020 10:23:01 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 CA2053A1402; Mon, 7 Dec 2020 10:23:00 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id h6so8090572vsr.6; Mon, 07 Dec 2020 10:23:00 -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:cc; bh=j1pp6IGffPEr12SzP+/GRmkgseP5ECtY0t4Alb91ETo=; b=BOXno+xuIAlIOXj7whlmlZSydZYtqKJs5lVkT1M+Gb+8vPz4JYVOeww31OnShLKQVM 5lIbjshv9f1nEp09NeCofnfc7tfWxXXVvp1j+elOg630e8X19s4pUsROXHUm/0M5MyEY sRiCxpZvptI0WesC2OO51aBARDcz1YdKY5sVpbfggwL3+PMLWrpfS8uxRgQ1Di3+GLdk Lz4GpeEnMuzABn1tCOEtqj4wds1+wwdnaO5rztxHeXOMvm1GTenrWJPJIW97Ki3KaUBY 5GjvyMCthX1GyjiMe+Dqz+xtYiCjsW0Ubr0N8Q/WBFPYhCXqi60LT03VWKsIkv/kOUwO dEqA== 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:cc; bh=j1pp6IGffPEr12SzP+/GRmkgseP5ECtY0t4Alb91ETo=; b=uMzkO6hcRyq0nYGKNmka3apMvj4JxdJtdCUkInk+O3RPxyb9IccAFX3XAQtxl9k2vC mHRyx7x/7kJV1YCD8YlZv0zVczKPmrMObinWXIujgnOf7vyzTvjWjWU94Mi2XUnRIszv +P7Fuha0Hm5N+wHLIk+qoOO8+BDsIyfTmfHjnZ2JrCFsFEqHeag6P+C1QIX//aMqmy4j jSSeDxJnwVkTPc2ngdKmNku1YBc7IHlyziEKVOXZjjrv6t2vNNgOK/TxMExN7+9lkOeR 3MEzX8rcvbc8hUbZXUJxClWKcdgKKm5Mof6ADtzjPSO3eQs9vpYHzyVcqz0EYWWnN3DL p/BQ== X-Gm-Message-State: AOAM5306ahsC0JDjszzQhfWLCRSGcJ7Jz/fSP68k+SlkAbGgTLo9dKsN B3wDtlI5bo2FuwqctbNn5Otk3PFUNZPdX6jpRUOpzv264Oo= X-Google-Smtp-Source: ABdhPJwK7HyDC5ftaGmWII6nvHW9TicCjlUHdFqhqTDPPtcABrbsGf0Xh1qWlp1eNrlErc7U1CVtFJAbE96iVbm0b/A= X-Received: by 2002:a05:6102:3ce:: with SMTP id n14mr3674912vsq.56.1607365379582; Mon, 07 Dec 2020 10:22:59 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Mon, 7 Dec 2020 13:22:48 -0500 Message-ID: To: SPASM , anima@ietf.org, iotops@ietf.org Cc: Ace Wg Content-Type: multipart/alternative; boundary="000000000000796ddd05b5e3eac4" Archived-At: Subject: [Iotops] ACE new charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 18:23:03 -0000 --000000000000796ddd05b5e3eac4 Content-Type: text/plain; charset="UTF-8" Hi, The ACE WG though you might be interested in knowing that the current ACE charter considers, among other things, working on CMPv2 over CoAP. The current charter can be found here [1]. If you think the work should be done in another WG, please let us know before Friday December 11, so we can move the charter forward. Yours, Daniel [1] https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing -- Daniel Migault Ericsson --000000000000796ddd05b5e3eac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

The ACE WG though you might b= e interested in knowing that the current ACE charter considers, among other= =C2=A0things, working on CMPv2 over CoAP. The current charter can be found = here [1].=C2=A0
If you think the work should=C2=A0be done in anot= her WG, please let us know before Friday December 11, so we can move the ch= arter forward.=C2=A0

Yours,=C2=A0
Daniel=C2=A0<= /div>

=
--000000000000796ddd05b5e3eac4-- From nobody Mon Dec 7 11:38:25 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE53A07AE; Mon, 7 Dec 2020 11:38:22 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 Zx27MwcUYdfL; Mon, 7 Dec 2020 11:38:19 -0800 (PST) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 893D93A0766; Mon, 7 Dec 2020 11:38:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B7JcGpm001259; Mon, 7 Dec 2020 14:38:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607369898; bh=FNKtuR0CeMAL2pkOcKQp32jl6Eh+QKwMcul3jN9+IM8=; h=From:To:CC:Subject:Date:From; b=t0rJ8+77vsHKsublBH65IFTSgPupuHt3bZJJp89+TSVNmELbhG3FK8bUhmF4qYMVA s9Qa2uoaN8Hblq1YxoPFZI66U5DXetvByjAX0S1xVEne5wGSC53iJZwqqn5gegxJSV wvTc/Y9OqiCq/brRJpnuJY4iiJC/OtsK4OB6tUKvsF+FRFTEoOJtZwFfd1DXJECjvl znXkCDtuZA58at44wpicY/jnm7RrXajkeYIOwJNpY1xOpwlrilGkxFEnXRgpZTo1vy SwNd1+Gd18UvPhmUSU8nAubECYfowKiqRlV8l6qprtRzNSZ0frdxlor4E8Wyz+pSZX pleL6aXmIhGhA== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B7JcEvK001238 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 14:38:14 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 7 Dec 2020 11:38:13 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 7 Dec 2020 11:38:13 -0800 From: "Templin (US), Fred L" To: Ted Lemon CC: "STARK, BARBARA H" , Michael Richardson , =?utf-8?B?T2xlIFRyw7hhbg==?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AdbMz9OConAqMYjZtUCg6orRClX9ig== Date: Mon, 7 Dec 2020 19:38:13 +0000 Message-ID: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: C903505243D0C0D45BE205C7E0A8500541F541E74DA9712BB3812426EF6FEF262000:8 Content-Type: multipart/alternative; boundary="_000_2f1c1e67b96844ce934add51ef2c5f4dboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 19:38:22 -0000 --_000_2f1c1e67b96844ce934add51ef2c5f4dboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkLCBwbGVhc2UgaGF2ZSBhbm90aGVyIGxvb2s6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4tNm1hbi1vbW5pLWludGVyZmFjZS8NCg0KSXQgbm93IHBs YWNlcyBhIGZ1bGx5LWZvcm1lZCBESENQdjYgbWVzc2FnZSBpbnNpZGUgb2YgYW4gT01OSSBvcHRp b24gaW4NClJTL1JBIG1lc3NhZ2VzIHNvIHRoZSBzdHViIG5ldHdvcmsgbm9kZSBjYW4gZG8gREhD UHY2LVBEIGF0IHRoZSBzYW1lDQp0aW1lIGl0IGRvZXMgUlMvUkEgKHRoaXMgaXMgc29tZXRoaW5n IEkgaGF2ZSB0YWxrZWQgYWJvdXQgYmVmb3JlKS4gSG93ZXZlciwNCnJpZ2h0IG5vdyBpdCBvbmx5 IGFsbG93cyBmb3IgYSBzbWFsbC1tZXNzYWdlIERIQ1B2NiBleGNoYW5nZSBmcm9tIHdpdGhpbg0K ZWFjaCBSUy9SQSwgd2hpY2ggc2hvdWxkIHByb3ZpZGUgYW1wbGUgc3BhY2UgZm9yIG1vc3Qgc3R1 YiBuZXR3b3JrDQpESENQdjYtUEQgdXNlcnMuIERvZXMgaXQgbG9vayBsaWtlIGVub3VnaCwgb3Ig c2hvdWxkIHdlIHN1cHBvcnQgYmlnZ2VyPw0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IFRlZCBM ZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDA0 LCAyMDIwIDU6MjcgUE0NClRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4NCkNjOiBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbT47IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgT2xlIFRyw7hhbiA8b3Ryb2Fu QGVtcGxveWVlcy5vcmc+OyA2TUFOIDw2bWFuQGlldGYub3JnPjsgaW90b3BzQGlldGYub3JnDQpT dWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbSW90b3BzXSBBdXRvbWF0aWNhbGx5IGNvbm5lY3Rpbmcg dG8gc3R1YiBuZXR3b3Jrcy4uLg0KDQoNClRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNp ZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVu dHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250 ZW50IGlzIHNhZmUuDQoNCg0KDQoNCkkgY2Fu4oCZdCBzZWUgdGhhdCBiZWluZyB1c2VmdWwgZm9y IHN0dWIgbmV0d29ya3MuIFRoZSB3aG9sZSBwb2ludCBvZiDigJxzdHVi4oCdIGlzIHRvIGF2b2lk IGNvbXBsaWNhdGVkIHJvdXRpbmcsIHNpbmNlIGl04oCZcyBub3QgdXNlZnVsIGZvciBhIHR5cGlj YWwgc3R1YiBuZXR3b3JrLg0KDQoNCk9uIERlYyA0LCAyMDIwLCBhdCAxOTo0NiwgVGVtcGxpbiAo VVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1w bGluQGJvZWluZy5jb20+PiB3cm90ZToNCu+7vw0KVGVkLCB0aGUgb25seSBhc3BlY3RzIG9mIE9N TkkgeW91IHdvdWxkIG5lZWQgdG8gc2VlIHRvIGdyYXNwIHRoZSBjb25jZXB0cw0KYXJlIGEgcXVp Y2sgc2NhbiBvZiBTZWN0aW9ucyA5LjEuOSBhbmQgMTIuMyAoYXBwcm94LiAxLjI1IHRvdGFsIHBh Z2VzIG9mIHRleHQpLg0KDQpCYXNpY2FsbHksIGl0IGltcG9ydHMgREhDUHY2IG9wdGlvbnMgaW50 byBSUyBtZXNzYWdlcyBhbmQgYXNrcyB0aGUgcm91dGVyDQp0byBzZW5kIGEg4oCccHJveHkgREhD UHY2LVBEIFNvbGljaXTigJ0gdG8gdGhlIERIQ1B2NiBzZXJ2ZXIgb24gYmVoYWxmIG9mIHRoZQ0K bW9iaWxlIG5vZGUuIEFmdGVyIHRoZSByb3V0ZXIgZ2V0cyBiYWNrIHRoZSBESENQdjYtUEQgUmVw bHksIGl0IHNlbmRzIGFuDQpSQSB0byB0aGUgbW9iaWxlIG5vZGUgd2l0aCB0aGUgZGVsZWdhdGVk IHByZWZpeCBpbmZvcm1hdGlvbi4NCg0KVGhpcyBpcyBzb21ldGhpbmcgSSBzdWdnZXN0ZWQgYSBs b25nIHRpbWUgYWdvLCBidXQgdGhhdCB3YXMgYmVmb3JlIHdlIGhhZA0KdGhlIE9NTkkgb3B0aW9u IGNvbmNlcHQuIE5vdyB3aXRoIHRoZSBPTU5JIG9wdGlvbiwgaXQgY2FuIGNhcnJ5IG90aGVyDQpw cm90b2NvbCBpbmZvcm1hdGlvbiBsaWtlIERIQ1B2NiBvcHRpb25zIGp1c3QgZmluZS4NCg0KRnJl ZA0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KU2VudDogRnJp ZGF5LCBEZWNlbWJlciAwNCwgMjAyMCAzOjE1IFBNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+Pg0KQ2M6IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2NTJA YXR0LmNvbT4+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWls dG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPj47IE9sZSBUcsO4YW4gPG90cm9hbkBlbXBsb3llZXMu b3JnPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZz4+OyA2TUFOIDw2bWFuQGlldGYub3JnPG1h aWx0bzo2bWFuQGlldGYub3JnPj47IGlvdG9wc0BpZXRmLm9yZzxtYWlsdG86aW90b3BzQGlldGYu b3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW0lvdG9wc10gQXV0b21hdGljYWxseSBjb25u ZWN0aW5nIHRvIHN0dWIgbmV0d29ya3MuLi4NCg0KT24gRGVjIDQsIDIwMjAsIGF0IDY6MTIgUE0s IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpESENQdjYtUEQgZmFucywgcGxlYXNl IGhhdmUgYSBsb29rIGF0IHRoZSBsYXRlc3QgT01OSSBkcmFmdCBhbmQgc2VlIGlmIGl0IHByb3Zp ZGVzDQp0aGUga2luZCBvZiBwcmVmaXggZGVsZWdhdGlvbiBzZXJ2aWNlcyB5b3Ugd291bGQgbGlr ZSB0byBzZWUgZm9yIHN0dWIgbmV0d29ya3M6DQoNCklmIHlvdSBhcmUgZXh0ZW5kaW5nIERIQ1B2 Ni1QRCBmb3IgT01OSSwgeW91IHNob3VsZCByZWFsbHkgZG8gaXQgYXMgYSBzZXBhcmF0ZSBkb2N1 bWVudC4gT01OSSBpcyByYXRoZXIgbGFyZ2UsIHNvIG1ha2luZyByZWZlcmVuY2VzIHRvIGl0IGlz buKAmXQgaWRlYWwuDQoNClRoZSBvbmx5IHRoaW5nIHdlIG5lZWQgdGhhdCBpc27igJl0IHNwZWNp ZmllZCBhbnl3aGVyZSBpcyBmb3IgdGhlIGluZnJhc3RydWN0dXJlIHJvdXRlciB0byBhZGQgdGhl IHByZWZpeCBhbmQgZGVzdGluYXRpb24gdG8gdGhlIHJvdXRpbmcgaW5mcmFzdHJ1Y3R1cmUuDQoN Cg== --_000_2f1c1e67b96844ce934add51ef2c5f4dboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAw IDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGVkLCBwbGVhc2UgaGF2ZSBh bm90aGVyIGxvb2s6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLTZt YW4tb21uaS1pbnRlcmZhY2UvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10ZW1wbGluLTZtYW4tb21uaS1pbnRlcmZhY2UvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgbm93IHBsYWNlcyBhIGZ1bGx5LWZvcm1lZCBESENQdjYg bWVzc2FnZSBpbnNpZGUgb2YgYW4gT01OSSBvcHRpb24gaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UlMv UkEgbWVzc2FnZXMgc28gdGhlIHN0dWIgbmV0d29yayBub2RlIGNhbiBkbyBESENQdjYtUEQgYXQg dGhlIHNhbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGltZSBpdCBkb2VzIFJTL1JBICh0aGlzIGlzIHNv bWV0aGluZyBJIGhhdmUgdGFsa2VkIGFib3V0IGJlZm9yZSkuIEhvd2V2ZXIsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPnJpZ2h0IG5vdyBpdCBvbmx5IGFsbG93cyBmb3IgYSBzbWFsbC1tZXNzYWdlIERIQ1B2 NiBleGNoYW5nZSBmcm9tIHdpdGhpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5lYWNoIFJTL1JBLCB3aGlj aCBzaG91bGQgcHJvdmlkZSBhbXBsZSBzcGFjZSBmb3IgbW9zdCBzdHViIG5ldHdvcms8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+REhDUHY2LVBEIHVzZXJzLiBEb2VzIGl0IGxvb2sgbGlrZSBlbm91Z2gsIG9y IHNob3VsZCB3ZSBzdXBwb3J0IGJpZ2dlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBEZWNlbWJlciAwNCwgMjAyMCA1OjI3IFBNPGJyPg0KPGI+VG86 PC9iPiBUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFNUQVJLLCBCQVJCQVJBIEggJmx0O2JzNzY1MkBhdHQuY29tJmd0 OzsgTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0Ozsg T2xlIFRyw7hhbiAmbHQ7b3Ryb2FuQGVtcGxveWVlcy5vcmcmZ3Q7OyA2TUFOICZsdDs2bWFuQGll dGYub3JnJmd0OzsgaW90b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5B TF0gUmU6IFtJb3RvcHNdIEF1dG9tYXRpY2FsbHkgY29ubmVjdGluZyB0byBzdHViIG5ldHdvcmtz Li4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJs ZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxs cGFkZGluZz0iMCIgYWxpZ249ImxlZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAl O21hcmdpbi1sZWZ0Oi43NXB0O21hcmdpbi1yaWdodDouNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9ImJhY2tncm91bmQ6IzkxMEExOTtwYWRkaW5nOjUuMjVwdCAxLjVwdCA1LjI1cHQg MS41cHQiPjwvdGQ+DQo8dGQgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dy b3VuZDojRkRGMkY0O3BhZGRpbmc6NS4yNXB0IDMuNzVwdCA1LjI1cHQgMTEuMjVwdDt3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1lbGVtZW50 OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDph cm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1h bmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyMTIxMjEiPlRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNp ZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVu dHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250 ZW50IGlzIHNhZmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4N CjwvdGJvZHk+DQo8L3RhYmxlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwv dGFibGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkkgY2Fu4oCZdCBzZWUgdGhhdCBiZWluZyB1c2VmdWwgZm9yIHN0dWIgbmV0d29y a3MuIFRoZSB3aG9sZSBwb2ludCBvZiDigJxzdHVi4oCdIGlzIHRvIGF2b2lkIGNvbXBsaWNhdGVk IHJvdXRpbmcsIHNpbmNlIGl04oCZcyBub3QgdXNlZnVsIGZvciBhIHR5cGljYWwgc3R1YiBuZXR3 b3JrLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIERlYyA0 LCAyMDIwLCBhdCAxOTo0NiwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0 bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77u/PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRlZCwgdGhlIG9ubHkgYXNwZWN0cyBv ZiBPTU5JIHlvdSB3b3VsZCBuZWVkIHRvIHNlZSB0byBncmFzcCB0aGUgY29uY2VwdHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+YXJlIGEgcXVpY2sgc2NhbiBvZiBTZWN0aW9ucyA5LjEuOSBhbmQgMTIuMyAo YXBwcm94LiAxLjI1IHRvdGFsIHBhZ2VzIG9mIHRleHQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+QmFzaWNhbGx5LCBpdCBpbXBvcnRzIERIQ1B2NiBvcHRpb25z IGludG8gUlMgbWVzc2FnZXMgYW5kIGFza3MgdGhlIHJvdXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50 byBzZW5kIGEg4oCccHJveHkgREhDUHY2LVBEIFNvbGljaXTigJ0gdG8gdGhlIERIQ1B2NiBzZXJ2 ZXIgb24gYmVoYWxmIG9mIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5tb2JpbGUgbm9kZS4gQWZ0ZXIg dGhlIHJvdXRlciBnZXRzIGJhY2sgdGhlIERIQ1B2Ni1QRCBSZXBseSwgaXQgc2VuZHMgYW48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UkEgdG8gdGhlIG1vYmlsZSBub2RlIHdpdGggdGhlIGRlbGVnYXRlZCBw cmVmaXggaW5mb3JtYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGlzIGlzIHNvbWV0aGluZyBJIHN1Z2dlc3RlZCBhIGxvbmcgdGltZSBhZ28sIGJ1dCB0 aGF0IHdhcyBiZWZvcmUgd2UgaGFkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSBPTU5JIG9wdGlvbiBj b25jZXB0LiBOb3cgd2l0aCB0aGUgT01OSSBvcHRpb24sIGl0IGNhbiBjYXJyeSBvdGhlcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5wcm90b2NvbCBpbmZvcm1hdGlvbiBsaWtlIERIQ1B2NiBvcHRpb25zIGp1 c3QgZmluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlZCBMZW1vbiBbPGEg aHJlZj0ibWFpbHRvOm1lbGxvbkBmdWd1ZS5jb20iPm1haWx0bzptZWxsb25AZnVndWUuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDA0LCAyMDIwIDM6MTUgUE08 YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86 YnM3NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQuY29tPC9hPiZndDs7IE1pY2hhZWwgUmljaGFyZHNv biAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7 aWV0ZkBzYW5kZWxtYW4uY2E8L2E+Jmd0OzsgT2xlIFRyw7hhbiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om90cm9hbkBlbXBsb3llZXMub3JnIj5vdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4mZ3Q7OyA2TUFO ICZsdDs8YSBocmVmPSJtYWlsdG86Nm1hbkBpZXRmLm9yZyI+Nm1hbkBpZXRmLm9yZzwvYT4mZ3Q7 Ow0KPGEgaHJlZj0ibWFpbHRvOmlvdG9wc0BpZXRmLm9yZyI+aW90b3BzQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdIFJlOiBbSW90b3BzXSBBdXRvbWF0aWNhbGx5 IGNvbm5lY3RpbmcgdG8gc3R1YiBuZXR3b3Jrcy4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gRGVjIDQs IDIwMjAsIGF0IDY6MTIgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwv YT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5ESENQdjYtUEQgZmFucywgcGxlYXNl IGhhdmUgYSBsb29rIGF0IHRoZSBsYXRlc3QgT01OSSBkcmFmdCBhbmQgc2VlIGlmIGl0IHByb3Zp ZGVzPGJyPg0KdGhlIGtpbmQgb2YgcHJlZml4IGRlbGVnYXRpb24gc2VydmljZXMgeW91IHdvdWxk IGxpa2UgdG8gc2VlIGZvciBzdHViIG5ldHdvcmtzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5J ZiB5b3UgYXJlIGV4dGVuZGluZyBESENQdjYtUEQgZm9yIE9NTkksIHlvdSBzaG91bGQgcmVhbGx5 IGRvIGl0IGFzIGEgc2VwYXJhdGUgZG9jdW1lbnQuIE9NTkkgaXMgcmF0aGVyIGxhcmdlLCBzbyBt YWtpbmcgcmVmZXJlbmNlcyB0byBpdCBpc27igJl0IGlkZWFsLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhl IG9ubHkgdGhpbmcgd2UgbmVlZCB0aGF0IGlzbuKAmXQgc3BlY2lmaWVkIGFueXdoZXJlIGlzIGZv ciB0aGUgaW5mcmFzdHJ1Y3R1cmUgcm91dGVyIHRvIGFkZCB0aGUgcHJlZml4IGFuZCBkZXN0aW5h dGlvbiB0byB0aGUgcm91dGluZyBpbmZyYXN0cnVjdHVyZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2f1c1e67b96844ce934add51ef2c5f4dboeingcom_-- From nobody Mon Dec 7 12:12:03 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34F33A08C5 for ; Mon, 7 Dec 2020 12:11:57 -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=ham 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 vHDu4sIgubFb for ; Mon, 7 Dec 2020 12:11:56 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 A67DA3A0936 for ; Mon, 7 Dec 2020 12:11:33 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id z9so10369231qtn.4 for ; Mon, 07 Dec 2020 12:11:33 -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=IULooaV4rHa4vFbVUsv1r+7rfva6WatEa1WVtNWbo0c=; b=eyHpnwMyB/I1jvq/v75seUiqOF468WzUsA1VV8aEY4aIP6kLeiGKRsWZjpD5tlXlDu tRJVvRUY9zJFaGjXnV9WRXwC4/cgIZ1jWlKiM7/DQF8R6WhKi+ZqgkN0X4GrMTtn3hoY eMogj8KbGd2DNgCWiXBiuPxOd39eUZEBLKSziz13+/6InrxhMBpxX7P0wAN7s0Hxpwjb TXted7XUwUuXaHxg+4Aab6OU0hMWhufycXcph5qzsiO7vUJTZnsnV2Bi1f3c63WWV2oU DhpTtMpOWphoJPX+N11iH9rAIvEEMLTnLPB/5/m00X0zimJ2/4H7FmLTj0fSu0+MsHyV +VTw== 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=IULooaV4rHa4vFbVUsv1r+7rfva6WatEa1WVtNWbo0c=; b=sJVHcAXZyefyX0eummg42B4bEzHBngofUQxZ8J2tcUv0HoFINZPlWJ0RqgKFP1FeMJ 7LY2T2VNk11sAtoFLCNVzQxv1i1tf77sDnPMkqoU5aT1lOhS3aqjxf8PBHnBhd5Q5Z1W 0QcMkelKSoEey1WtaY7YNxx9b6Q77D0ZETG2Agv0OoZPpsueuUCPZtpn7uEZ3qA/vFru TvZPGui5Piet9kX5iiuCz6dsSUuyqfJwpvsFQ+2j+9/t0wY3eLtmKOxYPJ+JJt7/CtPd 4aQoDPIdusW83t1Pp3l5jnXxp5d9CZsrIhMMdpdO+oZU8q/4g/hWKeouvsocjpBdDjyC LlLQ== X-Gm-Message-State: AOAM532NnVgBx/6dXB/3ffLgXq7ygm/Gn2uOPmWgk43zKScud5anXA2t fmjiJrlN9JfpZK9F9NAeEqDtdQ== X-Google-Smtp-Source: ABdhPJwlzQEWPQ+h/LiF8Qdr97Mc161W+B7pAvVWGkOWIHALgIcCHzJ/bHm61GZfJXC4GYQPdJCUmQ== X-Received: by 2002:ac8:6bc2:: with SMTP id b2mr10102234qtt.286.1607371892579; Mon, 07 Dec 2020 12:11:32 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z30sm12850575qtc.15.2020.12.07.12.11.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 12:11:32 -0800 (PST) From: Ted Lemon Message-Id: <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_98B892A0-3871-4988-88B1-8A70B2C01F39" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 7 Dec 2020 15:11:29 -0500 In-Reply-To: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> Cc: "STARK, BARBARA H" , Michael Richardson , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" To: "Templin (US), Fred L" References: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:11:58 -0000 --Apple-Mail=_98B892A0-3871-4988-88B1-8A70B2C01F39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 7, 2020, at 2:38 PM, Templin (US), Fred L = wrote: > It now places a fully-formed DHCPv6 message inside of an OMNI option = in > RS/RA messages so the stub network node can do DHCPv6-PD at the same > time it does RS/RA (this is something I have talked about before). = However, > right now it only allows for a small-message DHCPv6 exchange from = within > each RS/RA, which should provide ample space for most stub network > DHCPv6-PD users. Does it look like enough, or should we support = bigger? I=E2=80=99m sorry, Fred, but I=E2=80=99m just not seeing the point of = this. Why not just do DHCPv6 PD? --Apple-Mail=_98B892A0-3871-4988-88B1-8A70B2C01F39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 7, 2020, at 2:38 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
It now places a = fully-formed DHCPv6 message inside of an OMNI option in
RS/RA messages so the = stub network node can do DHCPv6-PD at the same
time it does RS/RA = (this is something I have talked about before). However,
right now it only = allows for a small-message DHCPv6 exchange from within
each RS/RA, which = should provide ample space for most stub network
DHCPv6-PD users. Does = it look like enough, or should we support = bigger?

I=E2=80=99m sorry, Fred, but I=E2=80=99m just not seeing the = point of this. Why not just do DHCPv6 PD?

= --Apple-Mail=_98B892A0-3871-4988-88B1-8A70B2C01F39-- From nobody Mon Dec 7 12:22:13 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5063A0989; Mon, 7 Dec 2020 12:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 2C9hU9fG-lP2; Mon, 7 Dec 2020 12:22:05 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 3CF703A0964; Mon, 7 Dec 2020 12:22:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B7KM3hn032499; Mon, 7 Dec 2020 15:22:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607372524; bh=FPyzxw6WxsjH4mrFiQHwXD9CLKXmsdKsPdOYAGShLKU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=YTxV2fP8G+/rh5UTtbiCr6ss/oTg7x6STdysVpWtYL8CC5AkSBmQ6t+wSIGrMz+Fo AUvj1D1dWMb7iXShtYNqcgCIBtrGcdqlS9f9pCYunYbW/pvfUnD63Ebxs3OlNtPPBk tCmp9fuoJzOo/n3pGtk2j/t1MTX00di+bpPUWFxXX6VH1Mvu+cTqT8pfdgFx6BJlUq AlfCsvb6HiJ6NIZ5ZrIkXsL6hWgkzOX9+/vXbdNUQwzVwBkL/ch0ZoYpGougd2oIcW pufToVN2y3x3D+LoING8KcyHlg0vvfMlFLgFyInqjfaOL43MgAjX4X+QtNLReyfkOe JXrXno4Gq4xeg== Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B7KLnLx032253 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 15:21:49 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 7 Dec 2020 12:21:48 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 7 Dec 2020 12:21:48 -0800 From: "Templin (US), Fred L" To: Ted Lemon CC: "STARK, BARBARA H" , Michael Richardson , =?utf-8?B?T2xlIFRyw7hhbg==?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" Thread-Topic: [EXTERNAL] Re: [Iotops] Automatically connecting to stub networks... Thread-Index: AdbMz9OConAqMYjZtUCg6orRClX9igASGCKAABCw3JA= Date: Mon, 7 Dec 2020 20:21:48 +0000 Message-ID: <5c230c43ab9540e1b16a3985e964e93f@boeing.com> References: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com> In-Reply-To: <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: C3B821F0FA432408F1241B1B954CC2B340F86296665AD64D6A321D18A9C3D1752000:8 Content-Type: multipart/alternative; boundary="_000_5c230c43ab9540e1b16a3985e964e93fboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Iotops] [EXTERNAL] Re: Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:22:08 -0000 --_000_5c230c43ab9540e1b16a3985e964e93fboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PknigJltIHNvcnJ5LCBGcmVkLCBidXQgSeKAmW0ganVzdCBub3Qgc2VlaW5nIHRoZSBwb2ludCBv ZiB0aGlzLiBXaHkgbm90IGp1c3QgZG8gREhDUHY2IFBEPw0KDQpUZWQsIHRoZXJlIGlzIGEgbmVl ZCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBlc3BlY2lhbGx5IG9uIGxvdyBlbmQN CndpcmVsZXNzIGxpbmtzIGxpa2UgdGhvc2UgdXNlZCBmb3IgYXZpYXRpb24uIFNvLCBpZiBhIHRl cnNlIERIQ1B2NiBQRCBleGNoYW5nZQ0KY2FuIGJlIHBpZ2d5YmFja2VkIG9uLWJvYXJkIHRoZSBS Uy9SQSBleGNoYW5nZSB0aGF0IGFscmVhZHkgbmVlZHMgdG8gYmUNCnRoZXJlIGluIGFueSBjYXNl IHRoZW4gdGhlcmUgaXMgYSB0YW5naWJsZSBzYXZpbmdzIG9uIG1lc3NhZ2VzIG92ZXIgdGhlIGFp ci4NClRoaXMgaXMgZ29vZCBmb3IgbW9yZSB0aGFuIGp1c3QgYXZpYXRpb24sIHRvbywgYW5kIGFw cGxpY2FibGUgZm9yIG1vYmlsZSB1c2UNCmNhc2VzIHN1Y2ggYXMgaW50ZWxsaWdlbnQgdHJhbnNw b3J0YXRpb24gc3lzdGVtcyBhbmQgdXJiYW4gYWlyIG1vYmlsaXR5OyBtYXliZQ0KZXZlbiBmb3Ig cGVkZXN0cmlhbnMgdG9vLg0KDQpGcmVkDQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxv bkBmdWd1ZS5jb21dDQpTZW50OiBNb25kYXksIERlY2VtYmVyIDA3LCAyMDIwIDEyOjExIFBNDQpU bzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzog U1RBUkssIEJBUkJBUkEgSCA8YnM3NjUyQGF0dC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1j citpZXRmQHNhbmRlbG1hbi5jYT47IE9sZSBUcsO4YW4gPG90cm9hbkBlbXBsb3llZXMub3JnPjsg Nk1BTiA8Nm1hbkBpZXRmLm9yZz47IGlvdG9wc0BpZXRmLm9yZw0KU3ViamVjdDogW0VYVEVSTkFM XSBSZTogW0lvdG9wc10gQXV0b21hdGljYWxseSBjb25uZWN0aW5nIHRvIHN0dWIgbmV0d29ya3Mu Li4NCg0KDQpUaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4gUGxl YXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVj b2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhhdCB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoN Cg0KDQpPbiBEZWMgNywgMjAyMCwgYXQgMjozOCBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ PiB3cm90ZToNCkl0IG5vdyBwbGFjZXMgYSBmdWxseS1mb3JtZWQgREhDUHY2IG1lc3NhZ2UgaW5z aWRlIG9mIGFuIE9NTkkgb3B0aW9uIGluDQpSUy9SQSBtZXNzYWdlcyBzbyB0aGUgc3R1YiBuZXR3 b3JrIG5vZGUgY2FuIGRvIERIQ1B2Ni1QRCBhdCB0aGUgc2FtZQ0KdGltZSBpdCBkb2VzIFJTL1JB ICh0aGlzIGlzIHNvbWV0aGluZyBJIGhhdmUgdGFsa2VkIGFib3V0IGJlZm9yZSkuIEhvd2V2ZXIs DQpyaWdodCBub3cgaXQgb25seSBhbGxvd3MgZm9yIGEgc21hbGwtbWVzc2FnZSBESENQdjYgZXhj aGFuZ2UgZnJvbSB3aXRoaW4NCmVhY2ggUlMvUkEsIHdoaWNoIHNob3VsZCBwcm92aWRlIGFtcGxl IHNwYWNlIGZvciBtb3N0IHN0dWIgbmV0d29yaw0KREhDUHY2LVBEIHVzZXJzLiBEb2VzIGl0IGxv b2sgbGlrZSBlbm91Z2gsIG9yIHNob3VsZCB3ZSBzdXBwb3J0IGJpZ2dlcj8NCg0KSeKAmW0gc29y cnksIEZyZWQsIGJ1dCBJ4oCZbSBqdXN0IG5vdCBzZWVpbmcgdGhlIHBvaW50IG9mIHRoaXMuIFdo eSBub3QganVzdCBkbyBESENQdjYgUEQ/DQoNCg== --_000_5c230c43ab9540e1b16a3985e964e93fboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZl cmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NDk3MzgzNjE2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjg1Njk4NjYyIDY3Njk4Njk5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NTc2Ow0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7SeKAmW0gc29ycnksIEZyZWQsIGJ1dCBJ4oCZbSBqdXN0 IG5vdCBzZWVpbmcgdGhlIHBvaW50IG9mIHRoaXMuIFdoeSBub3QganVzdCBkbyBESENQdjYgUEQ/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UZWQsIHRoZXJlIGlz IGEgbmVlZCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBlc3BlY2lhbGx5IG9uIGxv dyBlbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2lyZWxlc3MgbGlua3MgbGlrZSB0aG9zZSB1c2VkIGZv ciBhdmlhdGlvbi4gU28sIGlmIGEgdGVyc2UgREhDUHY2IFBEIGV4Y2hhbmdlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmNhbiBiZSBwaWdneWJhY2tlZCBvbi1ib2FyZCB0aGUgUlMvUkEgZXhjaGFuZ2UgdGhh dCBhbHJlYWR5IG5lZWRzIHRvIGJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZXJlIGluIGFueSBjYXNl IHRoZW4gdGhlcmUgaXMgYSB0YW5naWJsZSBzYXZpbmdzIG9uIG1lc3NhZ2VzIG92ZXIgdGhlIGFp ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBnb29kIGZvciBtb3JlIHRoYW4ganVzdCBhdmlh dGlvbiwgdG9vLCBhbmQgYXBwbGljYWJsZSBmb3IgbW9iaWxlIHVzZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5jYXNlcyBzdWNoIGFzIGludGVsbGlnZW50IHRyYW5zcG9ydGF0aW9uIHN5c3RlbXMgYW5kIHVy YmFuIGFpciBtb2JpbGl0eTsgbWF5YmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXZlbiBmb3IgcGVkZXN0 cmlhbnMgdG9vLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIExlbW9uIFtt YWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2Vt YmVyIDA3LCAyMDIwIDEyOjExIFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluIChVUyksIEZyZWQg TCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFNUQVJL LCBCQVJCQVJBIEggJmx0O2JzNzY1MkBhdHQuY29tJmd0OzsgTWljaGFlbCBSaWNoYXJkc29uICZs dDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0OzsgT2xlIFRyw7hhbiAmbHQ7b3Ryb2FuQGVt cGxveWVlcy5vcmcmZ3Q7OyA2TUFOICZsdDs2bWFuQGlldGYub3JnJmd0OzsgaW90b3BzQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gUmU6IFtJb3RvcHNdIEF1dG9tYXRp Y2FsbHkgY29ubmVjdGluZyB0byBzdHViIG5ldHdvcmtzLi4uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQi IHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO21hcmdpbi1sZWZ0Oi43NXB0O21hcmdp bi1yaWdodDouNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6Izkx MEExOTtwYWRkaW5nOjUuMjVwdCAxLjVwdCA1LjI1cHQgMS41cHQiPjwvdGQ+DQo8dGQgd2lkdGg9 IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dyb3VuZDojRkRGMkY0O3BhZGRpbmc6NS4y NXB0IDMuNzVwdCA1LjI1cHQgMTEuMjVwdDt3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTIxMjEi PlRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8g bm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+T24gRGVjIDcsIDIwMjAsIGF0IDI6 MzggUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbSI+RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IG5vdyBwbGFjZXMg YSBmdWxseS1mb3JtZWQgREhDUHY2IG1lc3NhZ2UgaW5zaWRlIG9mIGFuIE9NTkkgb3B0aW9uIGlu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJTL1JBIG1lc3NhZ2VzIHNvIHRoZSBz dHViIG5ldHdvcmsgbm9kZSBjYW4gZG8gREhDUHY2LVBEIGF0IHRoZSBzYW1lPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRpbWUgaXQgZG9lcyBSUy9SQSAodGhpcyBpcyBzb21ldGhp bmcgSSBoYXZlIHRhbGtlZCBhYm91dCBiZWZvcmUpLiBIb3dldmVyLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5yaWdodCBub3cgaXQgb25seSBhbGxvd3MgZm9yIGEgc21hbGwtbWVz c2FnZSBESENQdjYgZXhjaGFuZ2UgZnJvbSB3aXRoaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+ZWFjaCBSUy9SQSwgd2hpY2ggc2hvdWxkIHByb3ZpZGUgYW1wbGUgc3BhY2UgZm9y IG1vc3Qgc3R1YiBuZXR3b3JrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRIQ1B2 Ni1QRCB1c2Vycy4gRG9lcyBpdCBsb29rIGxpa2UgZW5vdWdoLCBvciBzaG91bGQgd2Ugc3VwcG9y dCBiaWdnZXI/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SeKAmW0gc29ycnksIEZy ZWQsIGJ1dCBJ4oCZbSBqdXN0IG5vdCBzZWVpbmcgdGhlIHBvaW50IG9mIHRoaXMuIFdoeSBub3Qg anVzdCBkbyBESENQdjYgUEQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_5c230c43ab9540e1b16a3985e964e93fboeingcom_-- From nobody Mon Dec 7 12:28:02 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288EE3A0AF8 for ; Mon, 7 Dec 2020 12:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 wvE0KKW8lwAl for ; Mon, 7 Dec 2020 12:27:57 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 642A33A0B05 for ; Mon, 7 Dec 2020 12:27:57 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id dm12so7192223qvb.3 for ; Mon, 07 Dec 2020 12:27:57 -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=/K0INh5F+Ce5/RewsBlQpWztEzz7rnC7rwb760onPeg=; b=PX0biWKKK04VxSV0yz/3o5J4Vs4foKSudJRmkQgb0qBSOwoIh08qKiXk4z4Z1/jOP9 fb4TmIFlIg4NRy11Otxh+Zd/AZwtT/upeM0tgPt1DBh3rdyYQIcPrOcDGgNqGSfoV0/q kC6bwRzKdB4LJu8MXhDPYEJ/RikFSjQ7fSqLQFkueofejWyIKWAH4qRt1MlIK1koMt7T FQCcu6wyp1LtMaBloxe23cowYJEIAOIK3V1D3oZ0HmwJlSUQEYrV2pzPHeOA68L2yutX ig8xJlIMf0QhVByHtPfuvlW8Bh4ePHbq9nn013h2Eb0Pv3aSF3p52/r/3YfvLlA+9E5c gtWA== 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=/K0INh5F+Ce5/RewsBlQpWztEzz7rnC7rwb760onPeg=; b=goikYiAZsl+LDbqjGgsQ436Mctv79uwD7fWSVz6eiQ5qkUdrAY+IGeBnogAZpJHohw Quwgen7ldwgn5RlQYPe3Co/HUPpyAjwf3BmXbV3DTF1zN/irkeHxKC284QDt0AoBYWmJ LvM3Lk7qWzIq2MV3SFhdSPuYcsXBA63MNnC2Lcph6WGtvOud7TVy1gwJStZ7YOJbeQeZ sq+5gugPZxuh9tb8bgXTnvv9HWr76e//g+DjeECmOZD3cSmlTmQD6XymDCg4+FFhplcG V/pINt33iMjcNwCACcwXduo5YEiOlzlv0qTXH3w+a4n4XX64S+WwIFZo2If1X0vY2xmy PI/Q== X-Gm-Message-State: AOAM5311LbKHhidUUs277mG8IPNa4E6U+BHKKk3oz5nlS7xETebBGMnp hiebgyzgimg5sDml9ZvKgs2l0g== X-Google-Smtp-Source: ABdhPJymPa97p8glcPyz86OyQMype41O22h53dtd7EyMjN8IYxf7Yi2NFxl2epaD7yJ/66Q2rN91wg== X-Received: by 2002:ad4:5886:: with SMTP id dz6mr23412294qvb.10.1607372876350; Mon, 07 Dec 2020 12:27:56 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id g18sm12310546qtv.79.2020.12.07.12.27.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 12:27:55 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_01763A34-F5AA-4983-B897-8B1AEC8B1A89" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 7 Dec 2020 15:27:53 -0500 In-Reply-To: <5c230c43ab9540e1b16a3985e964e93f@boeing.com> Cc: "STARK, BARBARA H" , Michael Richardson , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" To: "Templin (US), Fred L" References: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com> <5c230c43ab9540e1b16a3985e964e93f@boeing.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] [EXTERNAL] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:27:59 -0000 --Apple-Mail=_01763A34-F5AA-4983-B897-8B1AEC8B1A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 7, 2020, at 3:21 PM, Templin (US), Fred L = wrote: > Ted, there is a need to reduce the number of messages especially on = low end > wireless links like those used for aviation. So, if a terse DHCPv6 PD = exchange > can be piggybacked on-board the RS/RA exchange that already needs to = be > there in any case then there is a tangible savings on messages over = the air. > This is good for more than just aviation, too, and applicable for = mobile use > cases such as intelligent transportation systems and urban air = mobility; maybe > even for pedestrians too. I still can=E2=80=99t think of a case where this applies to stub = networks. E.g., if you decide to support stub networks on an airplane, = you=E2=80=99re going to need a prefix to allocate stub network prefixes = from. That=E2=80=99s one transaction over the satellite link to get that = prefix, plus some maintenance. If your satellite link is so slow that = this is a problem, it=E2=80=99s not going to be usable, so we don=E2=80=99= t need to address that use case.=20 If you are thinking that the airplane=E2=80=99s public WiFi network is = itself a stub network, I think that would be out of scope for stub = networks=E2=80=94the whole point of stub networks is to be able to = automatically connect without an operator=E2=80=99s intervention, which = doesn=E2=80=99t match your use case. Additionally, I would consider a = home network connection to also be out of scope for stub networks, and = that=E2=80=99s somewhat analogous to the airplane use case. If you mean the airplane=E2=80=99s automation network, the same = objection applies. So I really don=E2=80=99t see where there=E2=80=99s overlap here. --Apple-Mail=_01763A34-F5AA-4983-B897-8B1AEC8B1A89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 7, 2020, at 3:21 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
Ted, there is a need to = reduce the number of messages especially on low end
wireless links like = those used for aviation. So, if a terse DHCPv6 PD exchange
can be piggybacked = on-board the RS/RA exchange that already needs to be
there in any case then = there is a tangible savings on messages over the air.
This is good for more = than just aviation, too, and applicable for mobile use
cases such as = intelligent transportation systems and urban air mobility; maybe
even for pedestrians = too.

I= still can=E2=80=99t think of a case where this applies to stub = networks. E.g., if you decide to support stub networks on an airplane, = you=E2=80=99re going to need a prefix to allocate stub network prefixes = from. That=E2=80=99s one transaction over the satellite link to get that = prefix, plus some maintenance. If your satellite link is so slow that = this is a problem, it=E2=80=99s not going to be usable, so we don=E2=80=99= t need to address that use case. 

If you are thinking that the = airplane=E2=80=99s public WiFi network is itself a stub network, I think = that would be out of scope for stub networks=E2=80=94the whole point of = stub networks is to be able to automatically connect without an = operator=E2=80=99s intervention, which doesn=E2=80=99t match your use = case. Additionally, I would consider a home network connection to also = be out of scope for stub networks, and that=E2=80=99s somewhat analogous = to the airplane use case.

If you mean the airplane=E2=80=99s automation network, the = same objection applies.

So I really don=E2=80=99t see where there=E2=80=99s overlap = here.

= --Apple-Mail=_01763A34-F5AA-4983-B897-8B1AEC8B1A89-- From nobody Mon Dec 7 12:37:46 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8AC3A09AD; Mon, 7 Dec 2020 12:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 T9um6fkKmJBA; Mon, 7 Dec 2020 12:37:42 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 6218E3A097C; Mon, 7 Dec 2020 12:37:42 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id s2so7447895oij.2; Mon, 07 Dec 2020 12:37:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ulKz28pND8Xovy/cTxHgEI1gl/TJVnN82chIUTbJ5U=; b=T6pc4Wg9gpkuSeQ4pbfMoHkt51Du3XxDM3oa1dI1dXG7ZQgYbUjE1nxkGb1Z4uZiCO 925PHrGJK+pSvbze0EhwcQtF8n9LAbp8x+jY4+F5w1htLhRtjxc+b8PlqiG+ryXMXcoy mNUD0OyWwJz41pwnoY8H3mAWde/oKgEtIeotMqr4vcLYT4FUa31RxklCbTa3fveZP81I sbs2AXyp7BDcoa/7MeqrCNrAodisFq12iObJKawRH6v21ffCEagmgRkupF+PquWtxchF kIhev362hs09Xx9mAgePKFcXVI3lrB8dJNJY8OffgVYABvh5Ws823gwMDBC2hMjiTpbI 84mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/ulKz28pND8Xovy/cTxHgEI1gl/TJVnN82chIUTbJ5U=; b=CnxQmSaWUVDkp2QfWt+onEgqa5DWtiNYJKS6WoY6yPf2wtK/ZAaQt81oSGE7cFp90c OlJKHY2HZl7Oa8td39K2kccTk19WF66MgYOLF35uY/56/GCQ2Bf2MhMPe0tW/s72KdoY uflAt5E69qHajqadw/MkZ9Hno4dLZvzoQwrpeahEDO8IlM13sM6JqK4Si7Oe9QU0ixlv zSdO6XjSmISeAbI6oqvV5UW8pU4o+XWLh5Txk0PvYDuNUMPrSSOUzjL/IjFvpUQTytSd zeNSeiLfhWRKDdodrSQSDKoRsv63mf6giYSxHp3Qm5oq13Ur2FfPQWEq3dr0ppLMhv52 zy2w== X-Gm-Message-State: AOAM5323+4sbjvs6P+93E+B7y5UDhRDm5YSTK+2L38TpMTU1pnmSIAwT ZLknVphKphYxi7x4C/tboodSeB58h0uBzk0qhao= X-Google-Smtp-Source: ABdhPJyjPaKhd0PsR0i8jx3J1DcVmtvk5bRah/QCvpg2ZCTUgNoOQKZmPwHgtn5akj6vB5ugOJyHkhVwiCTrRZ0gMuA= X-Received: by 2002:aca:72cf:: with SMTP id p198mr486831oic.60.1607373461653; Mon, 07 Dec 2020 12:37:41 -0800 (PST) MIME-Version: 1.0 References: <2f1c1e67b96844ce934add51ef2c5f4d@boeing.com> <265D8AB0-82CF-47AE-BE47-B1207D40A3C5@fugue.com> <5c230c43ab9540e1b16a3985e964e93f@boeing.com> In-Reply-To: <5c230c43ab9540e1b16a3985e964e93f@boeing.com> From: Mark Smith Date: Tue, 8 Dec 2020 07:37:28 +1100 Message-ID: To: "Templin (US), Fred L" Cc: Ted Lemon , Michael Richardson , 6MAN <6man@ietf.org>, "iotops@ietf.org" Content-Type: multipart/alternative; boundary="000000000000340c0005b5e5cc54" Archived-At: Subject: Re: [Iotops] [EXTERNAL] Re: Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:37:44 -0000 --000000000000340c0005b5e5cc54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 8 Dec 2020, 07:22 Templin (US), Fred L, wrote: > >I=E2=80=99m sorry, Fred, but I=E2=80=99m just not seeing the point of th= is. Why not just > do DHCPv6 PD? > > > > Ted, there is a need to reduce the number of messages especially on low e= nd > > wireless links like those used for aviation. So, if a terse DHCPv6 PD > exchange > > > I would wonder if IPv6 is fundamentally the wrong tool for the job if you care about going from 6 packets to 2. Packets are cheap and are always getting cheaper. By doing a lot of customising, you aren't really making things cheaper, you're just shifting the cost you're trying to avoid. Those 4 DHCPv6 PD packets you're saving could be paid for by the costs incurred of reinventing, implementing, deploying and then training people about the functional equivalents. What bandwidth are these links? > > > > > can be piggybacked on-board the RS/RA exchange that already needs to be > > there in any case then there is a tangible savings on messages over the > air. > > This is good for more than just aviation, too, and applicable for mobile > use > > cases such as intelligent transportation systems and urban air mobility; > maybe > > even for pedestrians too. > > > > Fred > > > > *From:* Ted Lemon [mailto:mellon@fugue.com] > *Sent:* Monday, December 07, 2020 12:11 PM > *To:* Templin (US), Fred L > *Cc:* STARK, BARBARA H ; Michael Richardson < > mcr+ietf@sandelman.ca>; Ole Tr=C3=B8an ; 6MAN < > 6man@ietf.org>; iotops@ietf.org > *Subject:* [EXTERNAL] Re: [Iotops] Automatically connecting to stub > networks... > > > > This message was sent from outside of Boeing. Please do not click links o= r > open attachments unless you recognize the sender and know that the conten= t > is safe. > > > > > On Dec 7, 2020, at 2:38 PM, Templin (US), Fred L < > Fred.L.Templin@boeing.com> wrote: > > It now places a fully-formed DHCPv6 message inside of an OMNI option in > > RS/RA messages so the stub network node can do DHCPv6-PD at the same > > time it does RS/RA (this is something I have talked about before). Howeve= r, > > right now it only allows for a small-message DHCPv6 exchange from within > > each RS/RA, which should provide ample space for most stub network > > DHCPv6-PD users. Does it look like enough, or should we support bigger? > > > > I=E2=80=99m sorry, Fred, but I=E2=80=99m just not seeing the point of thi= s. Why not just > do DHCPv6 PD? > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000340c0005b5e5cc54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, 8 Dec 2020, 07:22 Templin (US), Fred L, <Fred.L.Templin@boeing.com> wrote:

>I=E2=80=99m sor= ry, Fred, but I=E2=80=99m just not seeing the point of this. Why not just d= o DHCPv6 PD?

=C2=A0

Ted, there is a need to reduce the nu= mber of messages especially on low end

wireless links like those used for av= iation. So, if a terse DHCPv6 PD exchange



I would wonder if IPv6 is fundamentally the wrong tool for the job if = you care about going from 6 packets to 2.

=
Packets are cheap and are always getting cheaper.

By doing a lot of customising, = you aren't really making things cheaper, you're just shifting the c= ost you're trying to avoid.

Those 4 DHCPv6 PD packets you're saving could be paid for by = the costs incurred of reinventing, implementing, deploying and then trainin= g people about the functional equivalents.

What bandwidth are these links?
<= div class=3D"gmail_quote">


=




can be piggybacked on-board the RS/RA= exchange that already needs to be

there in any case then there is a tan= gible savings on messages over the air.

This is good for more than just aviat= ion, too, and applicable for mobile use

cases such as intelligent transportat= ion systems and urban air mobility; maybe

even for pedestrians too.

=C2=A0

Fred

=C2=A0

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Monday, December 07, 2020 12:11 PM
To: Templin (US), Fred L <Fred.L.Tem= plin@boeing.com>
Cc: STARK, BARBARA H <bs7652@att.com>; M= ichael Richardson <mcr+ietf@sandelman.ca&= gt;; Ole Tr=C3=B8an <otroan@employees.org>= ;; 6MAN <6man@ietf.org>; ioto= ps@ietf.org
Subject: [EXTERNAL] Re: [Iotops] Automatically connecting to stub ne= tworks...

=C2=A0

This message was sent from outside of Boeing. Please do not = click links or open attachments unless you recognize the sender and know th= at the content is safe.

 

=C2=A0

On Dec 7, 2020, at = 2:38 PM, Templin (US), Fred L <Fred.L.Templ= in@boeing.com> wrote:

It now places a fully-formed DHCPv6 m= essage inside of an OMNI option in

RS/RA messages so the stub network no= de can do DHCPv6-PD at the same

time it does RS/RA (this is something= I have talked about before). However,

right now it only allows for a small-= message DHCPv6 exchange from within

each RS/RA, which should provide ampl= e space for most stub network

DHCPv6-PD users. Does it look like en= ough, or should we support bigger?

=C2=A0

I=E2=80=99m sorry, = Fred, but I=E2=80=99m just not seeing the point of this. Why not just do DH= CPv6 PD?

=C2=A0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--000000000000340c0005b5e5cc54-- From nobody Mon Dec 7 12:49:54 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A702A3A09CC; Mon, 7 Dec 2020 12:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 8EbdHMgLKiXz; Mon, 7 Dec 2020 12:49:44 -0800 (PST) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 536EB3A09C9; Mon, 7 Dec 2020 12:49:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0B7Knf9F026501; Mon, 7 Dec 2020 15:49:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1607374182; bh=064JBbd/nu5udA+YnM/d6lgBEnhTy12885fOOQwU+i4=; h=From:To:CC:Subject:Date:From; b=MFeIcYqmfAK5PqtoT/4iJ1SUh5rQugIyg1Igx6/luyA7kE8VAvxALddQpKHfI35Ku pf9IW8m6nXDxgJc9VkxljedPlpeJlZ4Bt1qRr/ZGSXr6q/1gWvofPjDPny3AD6DxkH W0dJZCyRRdArf3lLkx1d1dAFA4LUmo0nLxC1q2j0x3SXyu8woiATipGPpd8+F9VIt8 +VsBXtAwuw/alb9+AFhWgQdZwjS8Txfw9agNIpBkOHzH+RQ0FpW1jen6wrmJq6DHct 9sQwbewUx50oDqxt/x/R9KGGLHfZeCvtzwP3ntq9L7gewHj+YeLFiNIQIxb1S4HjwG hHnELlJp45y4Q== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0B7KnTBu026366 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 7 Dec 2020 15:49:29 -0500 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 7 Dec 2020 12:49:28 -0800 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 7 Dec 2020 12:49:28 -0800 From: "Templin (US), Fred L" To: Ted Lemon CC: "STARK, BARBARA H" , Michael Richardson , =?utf-8?B?T2xlIFRyw7hhbg==?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" Thread-Topic: [Iotops] Automatically connecting to stub networks... Thread-Index: AdbM2RVU6TN99+sHT4u+0UMKR97w+w== Date: Mon, 7 Dec 2020 20:49:28 +0000 Message-ID: <6816090d7f43480490396c569cf6e24b@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: CB2FFDBCB7B9F30E661487E7E866D049CD66CF346600EACCEA89C5C965D474D22000:8 Content-Type: multipart/alternative; boundary="_000_6816090d7f43480490396c569cf6e24bboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:49:47 -0000 --_000_6816090d7f43480490396c569cf6e24bboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBNb25k YXksIERlY2VtYmVyIDA3LCAyMDIwIDEyOjI4IFBNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwg PEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogU1RBUkssIEJBUkJBUkEgSCA8YnM3NjUy QGF0dC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IE9s ZSBUcsO4YW4gPG90cm9hbkBlbXBsb3llZXMub3JnPjsgNk1BTiA8Nm1hbkBpZXRmLm9yZz47IGlv dG9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJb3RvcHNdIEF1dG9tYXRpY2FsbHkgY29ubmVj dGluZyB0byBzdHViIG5ldHdvcmtzLi4uDQoNClRlZCwgaXQgc3VycHJpc2VzIG1lIHRoYXQgSSBk b27igJl0IHNlZW0gdG8gYmUgcmVhY2hpbmcgeW91IG9uIHRoaXMsIHNvIG1heWJlIHdlIGFyZQ0K dGFsa2luZyBhYm91dCBkaWZmZXJlbnQgdGhpbmdzPyBNeSBtb2RlbCBmb3IgYSBtb2JpbGUgbm9k ZSBpcyBhIG1vYmlsZSByb3V0ZXIgd2l0aA0KYSBkb3duc3RyZWFtLWF0dGFjaGVkIG5ldHdvcmsg d2hlcmUgb25lIG1pZ2h0IGZpbmQgYW4gYXR0YWNoZWQg4oCcSW50ZXJuZXQgb2YNClRoaW5nc+KA nSDigJMgYSBzaW1wbGVzdCBleGFtcGxlIHdvdWxkIGJlIGEgc21hbGwgcm91dGVyIHdpdGggYSDi gJxub3J0aGJvdW5k4oCdIHdpcmVsZXNzDQppbnRlcmZhY2UgYW5kIGEg4oCcc291dGhib3VuZOKA nSBFdGhlcm5ldCBpbnRlcmZhY2UgYXR0YWNoZWQgdG8gYSBzd2l0Y2ggdG8gd2hpY2ggYQ0Kc21h bGwgbnVtYmVyIG9mIGhvc3RzIGFyZSBjb25uZWN0ZWQuIFRoZSBtb2JpbGUgcm91dGVyIG5lZWRz IHRvIGdldCBhIOKAnE1vYmlsZQ0KTmV0d29yayBQcmVmaXggKE1OUCnigJ0gZnJvbSB0aGUgbmV0 d29yayB2aWEgaXRzIOKAnG5vcnRoYm91bmTigJ0gaW50ZXJmYWNlLCBzbyBpdCBzZW5kcw0KYW4g UlMgd2l0aCBhIHBpZ2d5YmFja2VkIERIQ1B2NiBTb2xpY2l0IG9uIGJvYXJkLiBUaGUgQWNjZXNz IFJvdXRlciBpbiB0aGUNCm5ldHdvcmsgZ2V0cyB0aGUgUlMsIGV4dHJhY3RzIHRoZSBESENQdjYt UEQgU29saWNpdCBhbmQgc2VuZHMgaXQgdG8gdGhlIERIQ1B2Ng0KU2VydmVyLCBnZXRzIGJhY2sg dGhlIERIQ1B2Ni1QRCBSZXBseSwgdGhlbiBjcmFmdHMgYW4gUkEgd2l0aCB0aGUgREhDUHY2IFJl cGx5DQpvbiBib2FyZCBhbmQgc2VuZHMgaXQgYmFjayB0byB0aGUgbW9iaWxlIHJvdXRlci4gVGhl IG1vYmlsZSByb3V0ZXIgdGhlbiB0dXJucyBhcm91bmQNCmFuZCBhZHZlcnRpc2VzIHRoZSBkZWxl Z2F0ZWQgcHJlZml4IG92ZXIgdGhlIOKAnHNvdXRoYm91bmTigJ0gaW50ZXJmYWNlLCBhbmQgdGhl IGF0dGFjaGVkDQpJb1QgZGV2aWNlcyBhcmUgaGFwcHkuIElzIHRoaXMgbm90IHRoZSBraW5kIG9m IHNjZW5hcmlvIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB3aGVuIHlvdQ0KdGFsayBhYm91dCBzdHVi IG5ldHdvcmtzPw0KDQpGcmVkDQoNCg0KT24gRGVjIDcsIDIwMjAsIGF0IDM6MjEgUE0sIFRlbXBs aW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpUZWQsIHRoZXJlIGlzIGEgbmVlZCB0byByZWR1 Y2UgdGhlIG51bWJlciBvZiBtZXNzYWdlcyBlc3BlY2lhbGx5IG9uIGxvdyBlbmQNCndpcmVsZXNz IGxpbmtzIGxpa2UgdGhvc2UgdXNlZCBmb3IgYXZpYXRpb24uIFNvLCBpZiBhIHRlcnNlIERIQ1B2 NiBQRCBleGNoYW5nZQ0KY2FuIGJlIHBpZ2d5YmFja2VkIG9uLWJvYXJkIHRoZSBSUy9SQSBleGNo YW5nZSB0aGF0IGFscmVhZHkgbmVlZHMgdG8gYmUNCnRoZXJlIGluIGFueSBjYXNlIHRoZW4gdGhl cmUgaXMgYSB0YW5naWJsZSBzYXZpbmdzIG9uIG1lc3NhZ2VzIG92ZXIgdGhlIGFpci4NClRoaXMg aXMgZ29vZCBmb3IgbW9yZSB0aGFuIGp1c3QgYXZpYXRpb24sIHRvbywgYW5kIGFwcGxpY2FibGUg Zm9yIG1vYmlsZSB1c2UNCmNhc2VzIHN1Y2ggYXMgaW50ZWxsaWdlbnQgdHJhbnNwb3J0YXRpb24g c3lzdGVtcyBhbmQgdXJiYW4gYWlyIG1vYmlsaXR5OyBtYXliZQ0KZXZlbiBmb3IgcGVkZXN0cmlh bnMgdG9vLg0KDQpJIHN0aWxsIGNhbuKAmXQgdGhpbmsgb2YgYSBjYXNlIHdoZXJlIHRoaXMgYXBw bGllcyB0byBzdHViIG5ldHdvcmtzLiBFLmcuLCBpZiB5b3UgZGVjaWRlIHRvIHN1cHBvcnQgc3R1 YiBuZXR3b3JrcyBvbiBhbiBhaXJwbGFuZSwgeW914oCZcmUgZ29pbmcgdG8gbmVlZCBhIHByZWZp eCB0byBhbGxvY2F0ZSBzdHViIG5ldHdvcmsgcHJlZml4ZXMgZnJvbS4gVGhhdOKAmXMgb25lIHRy YW5zYWN0aW9uIG92ZXIgdGhlIHNhdGVsbGl0ZSBsaW5rIHRvIGdldCB0aGF0IHByZWZpeCwgcGx1 cyBzb21lIG1haW50ZW5hbmNlLiBJZiB5b3VyIHNhdGVsbGl0ZSBsaW5rIGlzIHNvIHNsb3cgdGhh dCB0aGlzIGlzIGEgcHJvYmxlbSwgaXTigJlzIG5vdCBnb2luZyB0byBiZSB1c2FibGUsIHNvIHdl IGRvbuKAmXQgbmVlZCB0byBhZGRyZXNzIHRoYXQgdXNlIGNhc2UuDQoNCklmIHlvdSBhcmUgdGhp bmtpbmcgdGhhdCB0aGUgYWlycGxhbmXigJlzIHB1YmxpYyBXaUZpIG5ldHdvcmsgaXMgaXRzZWxm IGEgc3R1YiBuZXR3b3JrLCBJIHRoaW5rIHRoYXQgd291bGQgYmUgb3V0IG9mIHNjb3BlIGZvciBz dHViIG5ldHdvcmtz4oCUdGhlIHdob2xlIHBvaW50IG9mIHN0dWIgbmV0d29ya3MgaXMgdG8gYmUg YWJsZSB0byBhdXRvbWF0aWNhbGx5IGNvbm5lY3Qgd2l0aG91dCBhbiBvcGVyYXRvcuKAmXMgaW50 ZXJ2ZW50aW9uLCB3aGljaCBkb2VzbuKAmXQgbWF0Y2ggeW91ciB1c2UgY2FzZS4gQWRkaXRpb25h bGx5LCBJIHdvdWxkIGNvbnNpZGVyIGEgaG9tZSBuZXR3b3JrIGNvbm5lY3Rpb24gdG8gYWxzbyBi ZSBvdXQgb2Ygc2NvcGUgZm9yIHN0dWIgbmV0d29ya3MsIGFuZCB0aGF04oCZcyBzb21ld2hhdCBh bmFsb2dvdXMgdG8gdGhlIGFpcnBsYW5lIHVzZSBjYXNlLg0KDQpJZiB5b3UgbWVhbiB0aGUgYWly cGxhbmXigJlzIGF1dG9tYXRpb24gbmV0d29yaywgdGhlIHNhbWUgb2JqZWN0aW9uIGFwcGxpZXMu DQoNClNvIEkgcmVhbGx5IGRvbuKAmXQgc2VlIHdoZXJlIHRoZXJl4oCZcyBvdmVybGFwIGhlcmUu DQoNCg== --_000_6816090d7f43480490396c569cf6e24bboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IE1vbmRheSwgRGVjZW1iZXIgMDcsIDIwMjAgMTI6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBs aW4gKFVTKSwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gU1RBUkssIEJBUkJBUkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7OyBNaWNoYWVs IFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBPbGUgVHLDuGFu ICZsdDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs7IDZNQU4gJmx0OzZtYW5AaWV0Zi5vcmcmZ3Q7 OyBpb3RvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJb3RvcHNdIEF1dG9t YXRpY2FsbHkgY29ubmVjdGluZyB0byBzdHViIG5ldHdvcmtzLi4uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOiMxRjQ5N0QiPlRlZCwgaXQgc3VycHJpc2VzIG1lIHRoYXQgSSBkb27igJl0IHNlZW0gdG8g YmUgcmVhY2hpbmcgeW91IG9uIHRoaXMsIHNvIG1heWJlIHdlIGFyZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2NvbG9yOiMxRjQ5N0QiPnRhbGtpbmcgYWJvdXQgZGlmZmVyZW50IHRoaW5ncz8gTXkgbW9kZWwg Zm9yIGEgbW9iaWxlIG5vZGUgaXMgYSBtb2JpbGUgcm91dGVyIHdpdGg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjojMUY0OTdEIj5hIGRvd25zdHJlYW0tYXR0YWNoZWQgbmV0d29yayB3aGVyZSBvbmUg bWlnaHQgZmluZCBhbiBhdHRhY2hlZCDigJxJbnRlcm5ldCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOiMxRjQ5N0QiPlRoaW5nc+KAnSDigJMgYSBzaW1wbGVzdCBleGFtcGxlIHdvdWxkIGJlIGEg c21hbGwgcm91dGVyIHdpdGggYSDigJxub3J0aGJvdW5k4oCdIHdpcmVsZXNzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6IzFGNDk3RCI+aW50ZXJmYWNlIGFuZCBhIOKAnHNvdXRoYm91bmTigJ0gRXRo ZXJuZXQgaW50ZXJmYWNlIGF0dGFjaGVkIHRvIGEgc3dpdGNoIHRvIHdoaWNoIGE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtjb2xvcjojMUY0OTdEIj5zbWFsbCBudW1iZXIgb2YgaG9zdHMgYXJlIGNvbm5lY3Rl ZC4gVGhlIG1vYmlsZSByb3V0ZXIgbmVlZHMgdG8gZ2V0IGEg4oCcTW9iaWxlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6IzFGNDk3RCI+TmV0d29yayBQcmVmaXggKE1OUCnigJ0gZnJvbSB0aGUgbmV0 d29yayB2aWEgaXRzIOKAnG5vcnRoYm91bmTigJ0gaW50ZXJmYWNlLCBzbyBpdCBzZW5kczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPmFuIFJTIHdpdGggYSBwaWdneWJhY2tlZCBESENQ djYgU29saWNpdCBvbiBib2FyZC4gVGhlIEFjY2VzcyBSb3V0ZXIgaW4gdGhlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6IzFGNDk3RCI+bmV0d29yayBnZXRzIHRoZSBSUywgZXh0cmFjdHMgdGhlIERI Q1B2Ni1QRCBTb2xpY2l0IGFuZCBzZW5kcyBpdCB0byB0aGUgREhDUHY2PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzFGNDk3RCI+U2VydmVyLCBnZXRzIGJhY2sgdGhlIERIQ1B2Ni1QRCBSZXBseSwg dGhlbiBjcmFmdHMgYW4gUkEgd2l0aCB0aGUgREhDUHY2IFJlcGx5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6IzFGNDk3RCI+b24gYm9hcmQgYW5kIHNlbmRzIGl0IGJhY2sgdG8gdGhlIG1vYmlsZSBy b3V0ZXIuIFRoZSBtb2JpbGUgcm91dGVyIHRoZW4gdHVybnMgYXJvdW5kPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6IzFGNDk3RCI+YW5kIGFkdmVydGlzZXMgdGhlIGRlbGVnYXRlZCBwcmVmaXggb3Zl ciB0aGUg4oCcc291dGhib3VuZOKAnSBpbnRlcmZhY2UsIGFuZCB0aGUgYXR0YWNoZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj5Jb1QgZGV2aWNlcyBhcmUgaGFwcHkuIElzIHRoaXMg bm90IHRoZSBraW5kIG9mIHNjZW5hcmlvIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiB3aGVuIHlvdTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOiMxRjQ5N0QiPnRhbGsgYWJvdXQgc3R1YiBuZXR3b3Jrcz88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtj b2xvcjojMUY0OTdEIj5GcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pk9uIERlYyA3LCAyMDIwLCBhdCAzOjIxIFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7PGEg aHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UZWQsIHRoZXJlIGlzIGEgbmVlZCB0byByZWR1Y2UgdGhlIG51bWJlciBvZiBtZXNz YWdlcyBlc3BlY2lhbGx5IG9uIGxvdyBlbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+d2lyZWxlc3MgbGlua3MgbGlrZSB0aG9zZSB1c2VkIGZvciBhdmlhdGlvbi4gU28sIGlmIGEg dGVyc2UgREhDUHY2IFBEIGV4Y2hhbmdlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmNhbiBiZSBwaWdneWJhY2tlZCBvbi1ib2FyZCB0aGUgUlMvUkEgZXhjaGFuZ2UgdGhhdCBhbHJl YWR5IG5lZWRzIHRvIGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZXJlIGlu IGFueSBjYXNlIHRoZW4gdGhlcmUgaXMgYSB0YW5naWJsZSBzYXZpbmdzIG9uIG1lc3NhZ2VzIG92 ZXIgdGhlIGFpci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBnb29k IGZvciBtb3JlIHRoYW4ganVzdCBhdmlhdGlvbiwgdG9vLCBhbmQgYXBwbGljYWJsZSBmb3IgbW9i aWxlIHVzZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jYXNlcyBzdWNoIGFzIGlu dGVsbGlnZW50IHRyYW5zcG9ydGF0aW9uIHN5c3RlbXMgYW5kIHVyYmFuIGFpciBtb2JpbGl0eTsg bWF5YmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXZlbiBmb3IgcGVkZXN0cmlh bnMgdG9vLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkkgc3RpbGwgY2Fu4oCZdCB0 aGluayBvZiBhIGNhc2Ugd2hlcmUgdGhpcyBhcHBsaWVzIHRvIHN0dWIgbmV0d29ya3MuIEUuZy4s IGlmIHlvdSBkZWNpZGUgdG8gc3VwcG9ydCBzdHViIG5ldHdvcmtzIG9uIGFuIGFpcnBsYW5lLCB5 b3XigJlyZSBnb2luZyB0byBuZWVkIGEgcHJlZml4IHRvIGFsbG9jYXRlIHN0dWIgbmV0d29yayBw cmVmaXhlcyBmcm9tLiBUaGF04oCZcw0KIG9uZSB0cmFuc2FjdGlvbiBvdmVyIHRoZSBzYXRlbGxp dGUgbGluayB0byBnZXQgdGhhdCBwcmVmaXgsIHBsdXMgc29tZSBtYWludGVuYW5jZS4gSWYgeW91 ciBzYXRlbGxpdGUgbGluayBpcyBzbyBzbG93IHRoYXQgdGhpcyBpcyBhIHByb2JsZW0sIGl04oCZ cyBub3QgZ29pbmcgdG8gYmUgdXNhYmxlLCBzbyB3ZSBkb27igJl0IG5lZWQgdG8gYWRkcmVzcyB0 aGF0IHVzZSBjYXNlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SWYgeW91IGFyZSB0aGlua2luZyB0 aGF0IHRoZSBhaXJwbGFuZeKAmXMgcHVibGljIFdpRmkgbmV0d29yayBpcyBpdHNlbGYgYSBzdHVi IG5ldHdvcmssIEkgdGhpbmsgdGhhdCB3b3VsZCBiZSBvdXQgb2Ygc2NvcGUgZm9yIHN0dWIgbmV0 d29ya3PigJR0aGUgd2hvbGUgcG9pbnQgb2Ygc3R1YiBuZXR3b3JrcyBpcyB0byBiZSBhYmxlIHRv IGF1dG9tYXRpY2FsbHkgY29ubmVjdA0KIHdpdGhvdXQgYW4gb3BlcmF0b3LigJlzIGludGVydmVu dGlvbiwgd2hpY2ggZG9lc27igJl0IG1hdGNoIHlvdXIgdXNlIGNhc2UuIEFkZGl0aW9uYWxseSwg SSB3b3VsZCBjb25zaWRlciBhIGhvbWUgbmV0d29yayBjb25uZWN0aW9uIHRvIGFsc28gYmUgb3V0 IG9mIHNjb3BlIGZvciBzdHViIG5ldHdvcmtzLCBhbmQgdGhhdOKAmXMgc29tZXdoYXQgYW5hbG9n b3VzIHRvIHRoZSBhaXJwbGFuZSB1c2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklmIHlvdSBtZWFu IHRoZSBhaXJwbGFuZeKAmXMgYXV0b21hdGlvbiBuZXR3b3JrLCB0aGUgc2FtZSBvYmplY3Rpb24g YXBwbGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNvIEkgcmVhbGx5IGRvbuKAmXQgc2VlIHdoZXJlIHRo ZXJl4oCZcyBvdmVybGFwIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_6816090d7f43480490396c569cf6e24bboeingcom_-- From nobody Mon Dec 7 13:00:25 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511463A0A49 for ; Mon, 7 Dec 2020 13:00:23 -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=ham 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 wwN-o8jjFf_F for ; Mon, 7 Dec 2020 13:00:21 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 A0E723A0A42 for ; Mon, 7 Dec 2020 13:00:21 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id n142so3902439qkn.2 for ; Mon, 07 Dec 2020 13:00:21 -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=2V/TDGQa88fmomjRs1AZyrqJ76SclEz3uwN+H6aZqwg=; b=FIqeXcktFJ8Q1A2Dluvu4yujB/5LaNluEZXojRf0CwV7+86sOP3PfRKxQWsQ6P4PVa Hd6JY94OkvwFEjmB2bNCUhZwhWgF7sj0K6+JSOoPpJBCmuT+WT8aopH1xIDHeZ3AZlq9 0DavGSZ7gt92SAdz5OciZf4N4fB7cmib+tk8xCsdWuedp+FGuD0z7vx3U+Tt3HpQTvJz /Vjdtt09F523wjSkrSLIuqjSRIgqoKZHREI3poIrAmEuU+bWRp51HNrpAsC72+WWDvbr PDUZggfWU7Af+03ZWGXspZRGcBiUWHIDqPLgtWpPDN7w8xnOC1kJ5MRrXT1WwDfpYeH3 VviA== 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=2V/TDGQa88fmomjRs1AZyrqJ76SclEz3uwN+H6aZqwg=; b=QPpO1KyAJVXcF0+Ne0VLWt326hLZz7pYrn01o8OYUtKLlpAlA0VrNqMPS5aa6zYDS1 Z9Pnkp0JkD5m+5J+/pbsykwLvF0rNubDMI+Rl5pD8iZmIOf+yziSOn+xsAKYACZ6qFaq Qgxy93mqjRqu80FuPMbBaljDxgMgzfF3Z5q6yNMIcHmwkMcDFlCxXrU/s1pl3QchfC+a q50MBjiybb7oi+a1CzvwA4A+Eg+npt2K3S5xlOAcEXZ2QrHYbgLyDLhuRutK1MHF3HEp XiKPdeixfYqZVJlL4YePTASL1GuFgKM1k258Q1/bvIlAD01vDUyn61+9ZfGHzh+qYhYa tJmA== X-Gm-Message-State: AOAM533s//TLL7jhD8+QIne2P77N6jmHVD6p4LHC8IhmU2C7OJwMVjDD towzs0pd8r9H8/mXE4DD0kHkPQ== X-Google-Smtp-Source: ABdhPJx8MJ6cRgA2g6QRuoXeRzjs8E8hjR6IbQ5ykLOJ96pZKvma23DnaHEhMGu5Dx27nCYVWhsCYw== X-Received: by 2002:a37:a06:: with SMTP id 6mr10530125qkk.376.1607374820460; Mon, 07 Dec 2020 13:00:20 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 9sm907456qke.123.2020.12.07.13.00.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 13:00:19 -0800 (PST) From: Ted Lemon Message-Id: <29095871-34BA-41F7-B292-3A993482618F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E636FE0-02AB-4F72-B716-296F7FF1A4AF" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 7 Dec 2020 16:00:16 -0500 In-Reply-To: <6816090d7f43480490396c569cf6e24b@boeing.com> Cc: "STARK, BARBARA H" , Michael Richardson , =?utf-8?Q?Ole_Tr=C3=B8an?= , 6MAN <6man@ietf.org>, "iotops@ietf.org" To: "Templin (US), Fred L" References: <6816090d7f43480490396c569cf6e24b@boeing.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Iotops] Automatically connecting to stub networks... X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 21:00:23 -0000 --Apple-Mail=_4E636FE0-02AB-4F72-B716-296F7FF1A4AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 7, 2020, at 3:49 PM, Templin (US), Fred L = wrote: > Ted, it surprises me that I don=E2=80=99t seem to be reaching you on = this, so maybe we are > talking about different things? My model for a mobile node Stub routers aren=E2=80=99t mobile nodes in any meaningful sense. The = use case where a =E2=80=9Cmobile=E2=80=9D node might act as a stub = router is when it currently tethers, and now needs to provide continuity = of service for tethered devices when it has WiFi access. The mobile case = is out of scope, and indeed we=E2=80=99ve had a discussion here about = issues that come up when tethering with IPv6-only on a mobile device. = This is not that discussion. --Apple-Mail=_4E636FE0-02AB-4F72-B716-296F7FF1A4AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 7, 2020, at 3:49 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
Ted, it = surprises me that I don=E2=80=99t seem to be reaching you on this, so = maybe we are
talking about different things? My model for a mobile = node

Stub routers aren=E2=80=99t mobile nodes in any meaningful = sense. The use case where a =E2=80=9Cmobile=E2=80=9D node might act as a = stub router is when it currently tethers, and now needs to provide = continuity of service for tethered devices when it has WiFi access. The = mobile case is out of scope, and indeed we=E2=80=99ve had a discussion = here about issues that come up when tethering with IPv6-only on a mobile = device. This is not that discussion.

= --Apple-Mail=_4E636FE0-02AB-4F72-B716-296F7FF1A4AF-- From nobody Mon Dec 7 14:25:04 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7CC3A0BBC for ; Mon, 7 Dec 2020 14:25:00 -0800 (PST) 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=unavailable 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 p-0iHL02wZk5 for ; Mon, 7 Dec 2020 14:24:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836FB3A0BA4 for ; Mon, 7 Dec 2020 14:24:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ACB6389AE; Mon, 7 Dec 2020 17:27:04 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2RqrNHfXwhZS; Mon, 7 Dec 2020 17:26:56 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15592389AD; Mon, 7 Dec 2020 17:26:56 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 76CEB48F; Mon, 7 Dec 2020 17:24:47 -0500 (EST) From: Michael Richardson To: Henning Schulzrinne , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:25:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Henning Schulzrinne wrote: > It used to be that vendors announced end-of-life for products years a= fter > introduction. For example, there was no way for a purchaser of Window= s NT > to know, at purchase time, how long Microsoft was intending to suppor= t the > operating system. Now, better vendors seem to have started to make so= me > commitments, e.g., "this Android phone will receive new versions of t= he OS > for three releases and security updates until 2025". All the major Li= nux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposal= s (in > the UK?) of making vendors of IoT equipment state their support commi= tment, > so that a purchaser can choose "cheap" or "lasts a lifetime". yes, that's in the upcoming legislation. This document hints at it: https://assets.publishing.service.gov.uk/government/uploads/system/upl= oads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security= _October_2018.pdf This was a call for views that ended in September: https://www.gov.uk/government/publications/proposals-for-regulating-consu= mer-smart-product-cyber-security-call-for-views/proposals-for-regulating-co= nsumer-smart-product-cyber-security-call-for-views Box 4 - Requirement 3 - Provide transparency on for how long, at a minimu= m, the product will receive security updates Exact wording and approach to be finalised The =E2=80=98defined support period=E2=80=99 for the relevant =E2=80=98pr= oduct=E2=80=99 shall be published in an =E2=80=98accessible way=E2=80=99 that is =E2=80=98clear and transpa= rent=E2=80=99. This clause aligns with provision 5.3-13 of European Telecommunications Standards Institute (ETSI) European Standard (EN) 303 645 v2.1.1. > One reason for not upgrading: OS dependencies. Apple Big Sur (and Cat= alina) > broke a lot of printer drivers, so I had a choice: Upgrade my OS or k= eep my > printer working. Dell, the distributor of the printers (made by Fuji-= Xerox, > apparently) simply states that "due to circumstances beyond their con= trol", > they won't be providing any Catalina/Big Sur printer drivers. My mom's computer is just "too old", yet it is perfectly functional. > Given that most commercial systems are now assembled out of open-sour= ce > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committe= d to > long-term support. Are you prepared to fix them yourselves?" Some kind of expert system perhaps. Who'd pay to maintain this? And would it, itself, go out of support? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/Oq68ACgkQgItw+93Q 3WUtjAf/ZJpEJKbCj8J1vjx5O7upKjO1XOpWSbh+nDiSlh4GlgVLsN8A4/xUsbxu quCp01wA5Hs5Z06QdxsXPs31rVIpxJzjL/I7vI4+gwrxLH3tdyX3YP0FaWb2lS1t q0diUoEpkP4L6PgNFZrPYh2ifE2wn4QcSsw+pHp5g01YpMdlLGvz7WGJjlDm2WGK s2R7JkHLBKTEC+WfOxFPzhtOmysKKiKORvx9zlm98K4d7rc7EpMnJraHTPb1yIfE W1hkw15XfAJlS76w7JYJem4sQvEo9f/E5goZ4jIz+YNQL1+e47ipNFdfOqPviz3/ KnwzLSP5V6LXKCPFpx83ANKWND/BNA== =halJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 7 14:51:00 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833283A0C06 for ; Mon, 7 Dec 2020 14:50:59 -0800 (PST) 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 3JWd4Ncym8Ib for ; Mon, 7 Dec 2020 14:50:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877F83A0C03 for ; Mon, 7 Dec 2020 14:50:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 676D7389B1; Mon, 7 Dec 2020 17:53:05 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QdLhGOrR7VOc; Mon, 7 Dec 2020 17:53:04 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CEBE8389AE; Mon, 7 Dec 2020 17:53:04 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 29FEC48F; Mon, 7 Dec 2020 17:50:56 -0500 (EST) From: Michael Richardson To: iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:51:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable S=C3=A1vyo Vin=C3=ADcius wrote: > I really believe in the efficacy of an open source-based approach, but > there is a long way to develop a consistent framework (including comm= unity, > regulation, best practices, and other relevant stuff) to do it. > Still in this context, regulatory approaches need much attention beca= use > they can be restrictive to those companies, and contribute to more > bankruptcies. http://geer.tinho.net/geer.blackhat.6viii14.txt and https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html What can the IETF do? Mostly what we are already doing, which is to make it cheaper and easier to build products where the clients and the servers don't have to be vertically integrated. ... some text to tease you into going to read/listen-to the whole thing: 3. Source code liability -- CHOICE Nat Howard said that "Security will always be exactly as bad as it can possibly be while allowing everything to still function,"[NH] but with each passing day, that "and still function" clause requires a higher standard. As Ken Thompson told us in his Turing Award lecture, there is no technical escape;[KT] in strict mathematical terms you neither trust a program nor a house unless you created it 100% yourself, but in reality most of us will trust a house built by a suitably skilled professional, usually we will trust it more than one we had built ourselves, and this even if we have never met the builder, or even if he is long since dead. The reason for this trust is that shoddy building work has had that crucial "or else ..." clause for more than 3700 years: If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death. -- Code of Hammurabi, approx 1750 B.C. Today the relevant legal concept is "product liability" and the fundamental formula is "If you make money selling something, then you better do it well, or you will be held responsible for the trouble it causes." For better or poorer, the only two products not covered by product liability today are religion and software, and software should not escape for much longer. Poul-Henning Kamp and I have a strawman proposal for how software liability regulation could be structured. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/Osc8ACgkQgItw+93Q 3WUEwQgAllCgXfNv9bgHtOUybXjNaVf+6UT73U7PGvq48h7o4PIhsgvRxSsTNtUG Gfaa86QFoiZjI1smnXVWT4Ce5VRb2J2REclxPjw5yj7a5K3M+hLbl4tV7qK8JPGp P1OmQnA3aKCYi4fs7sdU2m/vtIk/LYYtbBxo60pkQeAoYPCJRb7/IMvUs4GkCBTM l40DoO5nN+hA4lugmwUwYoLDWOhyRWhjviQlaOrqZpxXNHURMb7UvN1UcHc8TPg9 bkW05IzY+USedO5GqsSd/8rx/x4yQW6vZdvfYFvGW5O/iVHoAIuuKxjiiW+Y37SF cu8hVkoYLPtbaSeHiXElv++tiK76wg== =MyTt -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 8 06:41:19 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7733A0F0F for ; Tue, 8 Dec 2020 06:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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=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 2wijoWN3rlZs for ; Tue, 8 Dec 2020 06:41:11 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 5FD923A0D41 for ; Tue, 8 Dec 2020 06:41:11 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id u19so17845861edx.2 for ; Tue, 08 Dec 2020 06:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=CCKLtmuZ0uJB3CZ62vJ0RKZrNQRbXHZ2X6QDJm9nDAv1xdLLWZBGW7BnfbrqCqtIEp q75yBiAL454Aa6sySw9YDD5Tl/l0g4Vx9CvK5a3sPUjkef8CcetmAS7qecbYeMztcxXF 9GQLoQvf3ckKevuVV3ZOZGal/mJT6MXu2HLv3AcnsvEhU38O0uhpKu9TGn+QqSXl/hCf BfIzpbtx0oNWfEWQZB+Zk5InXsOYccgHvxYF44pfA/C8ih5ywHEE7moirCo/4Q6y/Rn8 JYdQ4q0088+puaIqFhyaqBwLclgbQroDBqQWqfL3rN+G0qk12BPgsoUN6iJUpOFAkxAL sl+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=uZeQ9HCLGxpY3eORdyMxAsd21zVUfYQ5A2iMROjpTGNIAf7jflULxqOtgJH4/O+/JJ raT4QKecg+USXrCkefy3gILdXecth5qg0Hi9NbdNP1EOaZlDBPLifOGf2sc0uaD9KYAu q6u7o2/AfSBPPYW6Hso7OaEhNVl8vzCBtycdz4fUpkcztsEj1Q7IvgwvhOXnfq/l59tB AsYQeRVKe+Pg0HPTOLfqS9HmpXr9P8YtsPA6udAeSqK+/3J4j73vCgvqriK0VdHl2FEs ROwMQKrwFZAssCmlhI5veQH5msemY8915dWLTaxZvytNl47KhQ5Mhy0lCX8kY7himGCw pBRg== X-Gm-Message-State: AOAM532Oe3IKDXpZmtC/C1wVHu9PUbJAuWBcotGeEscgah4zS84SPV9N 4oQaCGAc2JzvyH005wokfEXx8O3E/uOeqLq2k9dgRjSbJZ8ZAhooSJs= X-Google-Smtp-Source: ABdhPJwOXAmuB4iBsPq09dURpxxHgLmP3dw31Nj6WCQNaPsPe0ipqPwcnO81YqT8U/T09dtKrSdBmQgJXlQEaoHuwfg= X-Received: by 2002:a05:6402:30ac:: with SMTP id df12mr9511452edb.175.1607438469796; Tue, 08 Dec 2020 06:41:09 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> <2741.1607381456@localhost> In-Reply-To: <2741.1607381456@localhost> From: =?UTF-8?B?U8OhdnlvIFZpbsOtY2l1cw==?= Date: Tue, 8 Dec 2020 11:40:57 -0300 Message-ID: To: Michael Richardson Cc: iotops@ietf.org, architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000fd971105b5f4eeb7" Archived-At: Subject: Re: [Iotops] [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 14:41:14 -0000 --000000000000fd971105b5f4eeb7 Content-Type: text/plain; charset="UTF-8" Michael Richardson wrote: > http://geer.tinho.net/geer.blackhat.6viii14.txt > and > https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html I agree that we need to put as much effort as is possible to reinforce security, but a regulation becomes useless if it only allows the commercialization of devices that nobody can afford. Regulations need to create a tradeoff between protection and affordability and this turns harder in in-development-countries. What can the IETF do? > Mostly what we are already doing, which is to make it > cheaper and easier to build products where the clients and the servers > don't > have to be vertically integrated. > ... and we have a long way to go, but a starting point could be this issue raised by RFC 8576 (section 5.5): "Like all commercial devices, IoT devices have a given useful lifetime. [...] A user should still be able to use and perhaps even update the device. This requires for some form of authorization handover. [...] CyanogenMod for Android devices and OpenWrt for home routers are two such instances where users have been able to use and update their devices even after the official EOL. Admittedly, it is not easy for an average user to install and configure their devices on their own. With the deployment of millions of IoT devices, simpler mechanisms are needed to allow users to add new trust anchors [RFC6024] and install software and firmware from other sources once the device is EOL." So how should we tackle this? Develop a framework to simplify the third part development of software/firmware updates after the EOL? And how to integrate SUIT work on it? --000000000000fd971105b5f4eeb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
http://geer.tinho.net/geer.blackhat.6viii14.txt
and
https://www.blackhat.com/us-14= /video/cybersecurity-as-realpolitik.html

I agree that we need to put as much effort as is possible to reinforce se= curity, but a=C2=A0
regulation becomes useless if it only allows = the commercialization of devices that=C2=A0
nobody can afford. Re= gulations need to create a tradeoff between protection and=C2=A0
= affordability and this turns harder in in-development-countries.
=

What can the IETF do?
Mostly what we are already doing, which is to make it
cheaper and easier to build products where the clients and the servers don&= #39;t
have to be vertically integrated.

... a= nd we have a long way to go, but a starting point could be this issue raise= d by RFC 8576 (section 5.5):

&qu= ot;Like all commercial devices, IoT devices have a given useful
lifetime. [...] A user should still be able to use an= d
perhaps even update the device.=C2=A0 Th= is requires for some form of
authorization= handover.

[...] CyanogenMod for Android devices and OpenWrt for home routers
are two such instances where users have bee= n able to use and update
their devices ev= en after the official EOL. Admittedly, it is not easy
for an average user to install and configure their devices on = their
own.=C2=A0 With the deployment of m= illions of IoT devices, simpler mechanisms
are needed to allow users to add new trust anchors [RFC6024] and install<= /div>
software and firmware from other sources o= nce the device is EOL."
<= br>So how should we tackle this?
Develop a framework to simplify the thi= rd part development of software/firmware updates after the EOL?
And how = to integrate SUIT work on it?
--000000000000fd971105b5f4eeb7-- From nobody Tue Dec 8 13:53:13 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D1A3A11F4; Tue, 8 Dec 2020 13:53:07 -0800 (PST) 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 0eb3G6jiI1z4; Tue, 8 Dec 2020 13:53:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 58F913A11DC; Tue, 8 Dec 2020 13:53:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kmkuk-0005yV-Ed; Tue, 08 Dec 2020 21:52:54 +0000 Date: Tue, 08 Dec 2020 13:52:53 -0800 Message-ID: From: Randy Bush To: Eliot Lear Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon In-Reply-To: <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 21:53:08 -0000 https://www.wired.com/story/amnesia33-iot-vulnerabilitiesmay-never-get-fixed/ From nobody Tue Dec 8 22:50:23 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420E03A0D07 for ; Tue, 8 Dec 2020 22:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5vmE7WDA2yqh for ; Tue, 8 Dec 2020 22:50:16 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06903A0D05 for ; Tue, 8 Dec 2020 22:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1607496615; x=1608706215; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=VhPFwg8rM9Ll5av1CzEb4VjfWqZCJjPd+F4Lfc0ndSk=; b=bgZ48bUax5QmY4Wnhu+0kd1EzKvAcHKNW8/ccZtxWS3/eMQ661KlR/OJ B7dmVBwuoc6dvnassbuMXkVXw3xkiyUrIfb0baEnDd2TiohH2CMwwZhvP GFfnMiwnZqdcKyfn/MzRDTOedj00h5VcGRXbfqt54lHp3WsqXGm1K75ta A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DcBQDActBflxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DH1cBIBIujG9TiCecMwQHAQEBCgMBASUKBAEBg0sBAXMBAQgCgX8mOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DIVyAQEBAQIBeQULCxguV?= =?us-ascii?q?wYTgyYBgmYgD6t6dIE0hVeFHgoGgTiBU4wLggCBOByCJy4+iAiCLASDeoFBZ?= =?us-ascii?q?5wJnBiCfoMjgTeWZgMfgxIBj2GPQbExg20CBAYFAhWBbSGBWTMaCBsVZQGCP?= =?us-ascii?q?j4SGQ2OO4NXillAAzA3AgYKAQEDCYpqAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,404,1599523200"; d="asc'?scan'208";a="31758964" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 06:50:11 +0000 Received: from [10.61.196.80] ([10.61.196.80]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B96oAv6027868 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Dec 2020 06:50:10 GMT From: Eliot Lear Message-Id: <302A37B6-4A3C-4CDE-8C29-410A982296FA@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 9 Dec 2020 07:50:09 +0100 In-Reply-To: Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.196.80, [10.61.196.80] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 06:50:17 -0000 --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Randy > On 8 Dec 2020, at 22:52, Randy Bush wrote: >=20 > = https://www.wired.com/story/amnesia33-iot-vulnerabilitiesmay-never-get-fix= ed/ Yes. That article hits on nearly every security and incentive problem = the IOT industry has. Eliot --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/Qc6EACgkQh7ZrRtnS ejN0Cgf9EbtIQG3V+9tPY/SYPwsns7hSAKuMTROI8Eu4Ra9bskzKdvVjyAxPwPdj Nn2Bmv+zQwp8QYs1qhrxkyTfWMcp+Bi4XrYdI+CrqwPc285O9n8XLtIIf1b+ZoAV UL2L1JsyH4FOpEApCkRbWmk2Py4fNMg6FnpZQaOUKyaTOfIDoz1P2mTh0NAGyu79 52SOobUOg+YPZmAq7n0vzC/qUdLEPNem75JBQaKB3A6oNBgjV8IuU5jCO9KkObtQ mcCxxB6ZG5n0AIeau008xStADDOWVBht8dBsi1lJNbv1VWT9aZUBohUYQ0CVw5mL fw21k7EnYsBt22NTfy0k8t3ujc7oig== =AU34 -----END PGP SIGNATURE----- --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042-- From nobody Mon Dec 14 09:00:33 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A204E3A08C5; Mon, 14 Dec 2020 09:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVoMFuXcBfac; Mon, 14 Dec 2020 09:00:23 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 31EAB3A08D4; Mon, 14 Dec 2020 09:00:23 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id s23so5679555uaq.10; Mon, 14 Dec 2020 09:00:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rQAnvdj/QI+sFitpvnp/PZr2uJQyILU7lCsbTiCEuik=; b=tkgAkrBzvSgBcchTUc5FnWdyJdp5pYCuh+9ayQRAGCi3M7ABo9WPsSxyUYt4YByZTV +aKzkiFdKGUFYCzKhlaJtfWHtsSeOFANROL+hoYcrF8Djn6o4g94M3ae8YcMypCVzoNU 9e4VnbxuEBq5otyJ8sn/MSYoHmKS7O25U1hRK7a5BSq0STfWLR754E7xTgviKVXUktTq DpTQWN/l5EBrQ4VxhSDjlkVDTY4OhI6Qqxs0NoD0S7tsxUEfRhkbO4HgJG/ue3XRLscx jcAHXwxynXaMP5Zoel1oQD0xzoPeuyrear8TsIxAcrCmwDVEVVs26/XYHKAl+1bxJfO1 bUlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rQAnvdj/QI+sFitpvnp/PZr2uJQyILU7lCsbTiCEuik=; b=oa1veA2eX28JQvKE4PgP64lTkfGPZAWJCiTofncllmbLzKS+ZNcPh8iZPAdokfbovW 7Y5BN6OkuGdapsBEd1gmqQDmCCad+k2ANeFp16SNcoAVMQyIxkzqMFXzyaAglV1CrEzy Ls/+wkCe+q2nKfekH6jT1SvH647VT4iUdzWQI953LREF34bYHNA3K+kIeerj6KFEuyqA iN6EW0fIG66dXeSkiMsq+u7C37JIFUTQa6xcRAW0tAZ+YxtjTvW1g7P5uGEqtF0beFc6 vpJICEAWwgjWqV+CR3/Au0TptKOqCZm5/rjuYQJmA3Cv+qnIVf9SM2M75amArfQ5R1Wl gx0A== X-Gm-Message-State: AOAM531EjkNcDjKkk2sqFGh4x8bY2V7j+LPZ1Wo5fBlj7/mpNieAT/IZ 6NCY87YAzj/j8bayLMSI3xut75875cdtVBFxuefb64kGXrs= X-Google-Smtp-Source: ABdhPJy6l86p8FhJo2m7g8CO8G3oTyQXjLIBPoHtMwLGg8KRukBUpF6VJBV0GcI8JDRl6D0Ft0rt5dYgGrkiLOA18QI= X-Received: by 2002:ab0:244f:: with SMTP id g15mr24281731uan.80.1607965222087; Mon, 14 Dec 2020 09:00:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Mon, 14 Dec 2020 12:00:10 -0500 Message-ID: To: Benjamin Kaduk Cc: Ace Wg , SPASM , anima@ietf.org, iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000dfb20a05b66f9357" Archived-At: Subject: Re: [Iotops] ACE new charter X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 17:00:26 -0000 --000000000000dfb20a05b66f9357 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, The current proposed charter for ACE is as follows. As soon as the charter is validated by the IESG, we will start call for adoption - at least for the CMPv2 and EAP items. The IESG may find useful that CMPv2 work may also be hosted in LAMPS (which revisits CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or IOTOPS. However, the discussion started in LAMPS and it was suggested ACE would be more appropriated [1] and the current proposed charter has been circulating on the lamps, anima, iotops mailing list and no concerns have been raised. We will however make sure , these related WG are informed of our progress. EAP work has been coordinated with EMU. In any case, if the work is being considered in ACE, we will make sure the corresponding WG will follow the progress. [1] https://mailarchive.ietf.org/arch/msg/spasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw= / Yours, Daniel """ The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and standardize as needed. """ Yours, Daniel On Sat, Dec 12, 2020 at 12:37 PM Dan Garcia Carrillo wrote: > Hi Mali=C5=A1a, > > > El 11/12/2020 a las 19:45, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3: > > Hi Dan, > > > > Thanks for the clarification regarding minimal-security. The points that > you mention below, e.g. flexible authentication or the fresh generation o= f > the PSK, were never in the design scope of our work. > > > > While I fail to understand what exactly do you plan on using EAP-over-CoA= P > for, I do not object on this work being done in ACE if you are willing to > spend cycles on it. I do have reservations on the lightweight aspect of > this, however, considering that the sequence diagram that you depict in > Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 rou= nd > trips just to get things started! Surely, we can do better? > > Yes, we will submit an updated version of the draft. > > Best Regards, > > Dan > > > > Mali=C5=A1a > > > > *From: *Dan Garcia Carrillo > *Date: *Friday 11 December 2020 at 18:41 > *To: *Mali=C5=A1a Vu=C4=8Dini=C4=87 , Michael Ri= chardson > , EMU WG > , "core@ietf.org WG (core@ietf.org)" > , > "ace@ietf.org" > *Cc: * > *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) > > > > Hi Mali=C5=A1a, > > My intention was not to turn this conversation into a criticism of your > work. =E2=80=9Cdeficiencies=E2=80=9D was not the most appropriate word. > > What we had in mind was a way of providing authentication to the variety > of IoT devices with different capabilities, limitations or different type= s > of supported credentials. A way of doing that is to provide different > authentication methods. Since in IoT there are different technologies we > looked for a link-layer independent solution. Additionally, since some > technologies are very constrained, we needed a very constrained protocol = to > carry out the process. > > EAP provides flexible authentication, and it has EAP Key Management > Framework which is well specified and working for many years, from which > you can generate generate a fresh pre-shared key (MSK) dynamically. This = is > even possible if you do not want to interact with AAA infrastructures > running EAP in standalone mode. Having said this, another thing that we > looked into was to give support to large scale deployments. We can ease > this process with EAP and its interaction with a AAA infrastructure, whic= h > gains relevance in Industrial IoT and 5G. > > All these characteristics can be provided by the use of EAP, if we of > course have a lightweight EAP lower layer to transport EAP from the IoT > device. Then we considered the usage of CoAP as EAP lower-layer. > > In this sense, we saw minimal security did not fit our view (no potential > interaction with AAA , flexible authentication, fresh generation of PSK). > In fact, the provisioning of the PSK was out of scope. > > At some level, we could even consider the work complementary. EAP over > CoAP could be a way of providing the PSK for the work of minimal security= . > > > Best Regards, > Dan. > > El 10/12/2020 a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3: > > Hi Dan, > > > > Could you be more specific on the point below, what deficiencies do you > have in mind? > > > > Mali=C5=A1a > > > > *From: *core on behalf of > Dan Garcia > *Date: *Thursday 10 December 2020 at 10:06 > *To: *Michael Richardson , > EMU WG , "core@ietf.org WG (core@ietf.org)" > , > "ace@ietf.org" > *Subject: *Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?) > > > > As you comment , draft-ietf-6tisch-minimal-security - offers minimal > security and has several deficiencies that can be solved by using EAP and > AAA infrastructures. > > --> > > -->_______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 Daniel Migault Ericsson On Mon, Dec 7, 2020 at 1:22 PM Daniel Migault wrote: > Hi, > > The ACE WG though you might be interested in knowing that the current ACE > charter considers, among other things, working on CMPv2 over CoAP. The > current charter can be found here [1]. > If you think the work should be done in another WG, please let us know > before Friday December 11, so we can move the charter forward. > > Yours, > Daniel > > [1] > https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXh= oDiptY/edit?usp=3Dsharing > > -- > Daniel Migault > Ericsson > --=20 Daniel Migault Ericsson --000000000000dfb20a05b66f9357 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

The current pr= oposed charter for ACE is as follows. As soon as the charter is validated b= y the=C2=A0IESG, we will=C2=A0start call=C2=A0for adoption - at least for t= he CMPv2 and EAP items.=C2=A0


The IES= G may find useful that CMPv2 work may also be hosted in LAMPS (which revisi= ts CMPv2), ANIMA ( which defines CMPv2 as an alternative to EST) or IOTOPS.= =C2=A0

Howe= ver, the discussion started in LAMPS and it was suggested ACE would be more= appropriated [1] and the current proposed charter has been circulating on = the lamps, anima, iotops mailing list and no concerns have been raised.=C2= =A0We will however make sure , these related WG are informed of our progres= s.


EAP work has been coordinated with EMU= . In any case, if the work is being considered in ACE, we will make sure th= e corresponding WG will follow the progress.


[1] https://mailarchive.ietf.org/arch/msg/s= pasm/uyYCf5sMcxg6xoQFcbe1sPxqVLw/

=
Yours,=C2=A0
Daniel

"""

The Authentication and = Authorization for Constrained Environments (ace) WG has defined a standardi= zed solution framework for authentication and authorization to enable autho= rized access to resources identified by a URI and hosted on a resource serv= er in constrained environments.=C2=A0

The access to the resource is mediated by an authori= zation server, which is not considered to be constrained.


Profiles of this framework f= or application to security protocols commonly used in constrained environme= nts, including CoAP+DTLS and CoAP+OSCORE, have also been standardized.=C2= =A0 The Working Group is charged with maintenance of the framework and exis= ting profiles thereof, and may undertake work to specify profiles of the fr= amework for additional secure communications protocols and for additional support services providing authorized access t= o crypto keys (tha= t are not necessarily limited to constrained endpoints, though the focus re= mains on deployment in ecosystems with a substantial portion of constrained= devices).


= In addition to the ongoing maintenance work, the Working Group will extend = the framework as needed for applicability to group communications, with ini= tial focus on (D)TLS and (Group) OSCORE as the underlying group communicati= on security protocols. The Working Group will standardize procedures for re= questing and distributing group keying material using the ACE framework as = well as appropriated management interfaces.=C2=A0


The Working Group will standardize a= format for expressing authorization information for a given authenticated = principal as received from an authorization manager.=C2=A0


The Working Group will exam= ine how to use Constrained Application Protocol (CoAP) as a transport mediu= m for certificate enrollment protocols, such as EST and CMPv2, as well as a= transport for authentication protocols such as EAP, and standardize as nee= ded.=C2=A0

"""

Yo= urs,=C2=A0
Daniel

=C2=A0

On Sat, Dec 12, 2020 at= 12:37 PM Dan Garcia Carrillo <ga= rciadan@uniovi.es> wrote:
=20

Hi Mali=C5=A1a,


El 11/12/2020 a las 19:45, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:
=20 =20 =20

Hi Dan,

=C2=A0

Thanks for the clarification regarding minimal-security. The points that you mention below, e.g. flexible authentication or the fresh generation of the PSK, were never in the design scope of our work.

=C2=A0

While I fail to understand what exactly do you plan on using EAP-over-CoAP for, I do not object on this work being done in ACE if you are willing to spend cycles on it. I do have reservations on the lightweight aspect of this, however, considering that the sequence diagram that you depict in Fig. 2 in draft-marin-ace-wg-coap-eap-06 spans 3 pages and consumes 2 round trips just to get things started! Surely, we can do better?

Yes, we will submit an updated version of the draft.

Best Regards,

Dan

=C2=A0

Mali=C5=A1a

=C2=A0

From: Dan = Garcia Carrillo <= garciadan@uniovi.es>
Date: Friday 11 December 2020 at 18:41
To: Mali=C5=A1a Vu=C4=8Dini=C4=87 <malisa.vucinic@<= /span>inria.fr>, Michael Richardson <mcr+ietf@sandelman.ca>, EMU WG <emu@iet= f.org>, "core@ietf.org WG (core@ietf.org)" <core@i= etf.org>, "ac= e@ietf.org" <= ace@ietf.org>
Cc: <garciadan@uniovi.es>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

=C2=A0

Hi Mali=C5=A1a,

My intention was not to turn this conversation into a criticism of your work. =E2=80=9Cdeficiencies=E2=80=9D was not th= e most appropriate word.

What we had in mind was a way of providing authentication=C2=A0 t= o the variety of IoT devices with different capabilities, limitations or different types of supported credentials. A way of doing that is to provide different authentication methods. Since in IoT there are different technologies we looked for a link-layer independent solution. Additionally, since some technologies are very constrained, we needed a very constrained protocol to carry out the process.

EAP provides flexible authentication, and it has EAP Key Management Framework which is well specified and working for many years, from which you can generate generate a fresh pre-shared key (MSK) dynamically. This is even possible if you do not want to interact with AAA infrastructures running EAP in standalone mode.=C2=A0 Having said this, another thing that we looked into was to give support to large scale deployments. We can ease this process with EAP and its interaction with a AAA infrastructure, which gains relevance in Industrial IoT and 5G.

All these characteristics can be provided by the use of EAP, if we of course have a lightweight EAP lower layer to transport EAP from the IoT device. Then we considered the usage of CoAP as EAP lower-layer.

In this sense, we saw minimal security did not fit our view (no potential interaction with AAA , flexible authentication, fresh generation of PSK).=C2=A0 In fact,=C2=A0 the provisioning o= f the PSK was out of scope.

At some level, we could even consider the work complementary. EAP over CoAP could be a way of providing the PSK for the work of minimal security.


Best Regards,
Dan.

El 10/12/2020 a las 18:43, Mali=C5=A1a Vu=C4=8Dini=C4=87 escribi=C3=B3:

Hi Dan,

=C2=A0

Could you be more specific on the point below, what deficiencies do you have in mind?

=C2=A0

Mali=C5=A1a

=C2=A0

From: co= re <core-boun= ces@ietf.org> on behalf of Dan Garcia <garciadan@uniovi.es>
Date: Thursday 10 December 2020 at 10:06
To: Michael Ri= chardson = <mcr+ietf@sandelman.ca>, EMU WG &l= t;emu@ietf.org>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>, "ace@ietf.org" <ace@i= etf.org>
Subject: Re: [core] [Ace] Proposed charter for ACE (EAP over CoAP?)

=C2=A0=

As you comment , draft-ietf-6tisch-minimal-security - offers minimal security and has several deficiencies that can be solved by using EAP and AAA infrastructures.=C2=A0<= /u>

--><= /u>

-->_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace


--
Daniel Migault
Ericsson

On Mon, Dec 7, 2020 at 1:22 PM Daniel Migault= <mglt.ietf@gmail.com> wro= te:
Hi,=C2=A0

The ACE WG though you might be interested= in knowing that the current ACE charter considers, among other=C2=A0things= , working on CMPv2 over CoAP. The current charter can be found here [1].=C2= =A0
If you think the work should=C2=A0be done in another WG, plea= se let us know before Friday December 11, so we can move the charter forwar= d.=C2=A0

Yours,=C2=A0
Daniel=C2=A0


--
Daniel Migault
Ericsson
--000000000000dfb20a05b66f9357-- From nobody Thu Dec 17 10:35:22 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1009C3A0E6E; Thu, 17 Dec 2020 10:35:18 -0800 (PST) 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 dV8w994UDQIY; Thu, 17 Dec 2020 10:35:16 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5D33A0E6D; Thu, 17 Dec 2020 10:35:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AA5C3389AC; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rhoCJCauHvAb; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 40983389A8; Thu, 17 Dec 2020 13:38:00 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9CCFF11B4; Thu, 17 Dec 2020 13:35:14 -0500 (EST) From: Michael Richardson To: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Iotops] DNS in IoT devices -- draft-richardson-opsawg-mud-iot-dns-considerations-03 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:35:18 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 3) Operational Considerations for use of DNS in IoT devices > draft-richardson-opsawg-mud-iot-dns-considerations-03 > Abstract > This document details concerns about how Internet of Things devices > use IP addresses and DNS names. The issue becomes acute as network > operators begin deploying RFC8520 Manufacturer Usage Description > (MUD) definitions to control device access. > This document explains the problem through a series of examples of > what can go wrong, and then provides some advice on how a device > manufacturer can best make deal with these issues. The > recommendations have an impact upon device and network protocol > design. This document is a BCP, and it creates no new protocol or on-the-wire-bits. It may be an appropriate document for IOTOPS if OPSAWG does not wish to work on it. Actually, I'm more and more convinced that this is an important aspect for an IETF architectural view on IoT. The ADD WG chairs examined it, as it has policy about when (not) to use DoT/DoH/QuadX-Do53, but determined that it was not in the rather narrow ADD charter. I would like to get early review from DNSOP, and I will endeavour to get th= at early in the new year. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bpOIACgkQgItw+93Q 3WWfnQgAv7rRo7KUbCj0hWcT2X1Kt7PUGAQ6Z7XPlDYcEn9islWNRBevIz6YvtnT 5IWQ30CsnS2fd7Ouh6kWM93CyS7bMlZlbnYWtYUWizUhm6WcRPRiJq56lVe3XPeL L55ktrq79JCzKAn+jdgo4+mChNLJH9m+KiqG75e49H677H57FDaqkrab/KBEUvTx s5oPx0JBd4rIodim9QO+iWPLf9bYkf58pTD3oE2QZrSbJn3xsAfcSJTIdwifLLsB wr+BtEs2knEipHmvMXT2+zDNcAn5zeRWoxAUA5+We16V5VVuo/ok063HjEzB8fmq t4RfYrNrACqvAbg7+XxGBUS7+G9XGA== =OTKk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 10:40:11 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698C63A0E78; Thu, 17 Dec 2020 10:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 0V5XUxTsfiEt; Thu, 17 Dec 2020 10:40:04 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EFF3A0E77; Thu, 17 Dec 2020 10:40:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 45CCE389AC; Thu, 17 Dec 2020 13:42:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NwBBggCDMJvp; Thu, 17 Dec 2020 13:42:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 405A4389A8; Thu, 17 Dec 2020 13:42:47 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94F6111B4; Thu, 17 Dec 2020 13:40:01 -0500 (EST) From: Michael Richardson CC: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Iotops] On loading MUD URLs from QR codes - draft-richardson-opsawg-securehomegateway-mud-05 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:40:07 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > 4) On loading MUD URLs from QR codes > draft-richardson-opsawg-securehomegateway-mud-05 > Abstract > This informational document details the mechanism used by the CIRA > Secure Home Gateway (SHG) to load MUD definitions for devices which > have no integrated MUD (RFC8520) support. This document is essentially complete. It does not create any on-the-wire protocol, at least no IP-wire. It described how to transmit MUD URLs over the optical-band ether[1], that is via QR code. The Return Logistics Alliance (rla.org) has a QR code format used today on many things, and a protocol for encoding and extending things. I have obtained a code point from them. While their document is open and available without marketing paywall, I have included just enough detail so that this document is probably stand-alone. Unless I hear otherwise, I intend to go to the ISE with this document. [1] - https://en.wikipedia.org/wiki/Aether_(classical_element) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bpgEACgkQgItw+93Q 3WX73Af+L6upCd2pVjxJ6SRMCNZEOLO/NLsVPY9kugAqID1+GelpdRAXyWB/XjNt 6fryNakwFRhEaboQKdf5/i92ieR3i3bYpSVm3jE8bGcIKh2KHdReb/tMZWyhOAXc DjjmqjJuZ5d9fr/g1CV9+qP0/3Da0JzSBGTUELlv2mRuw/XwjBdfZBKGy9l1CbNa Y7NxJVkEjz37dgqjSsZnyfrhDCvdkgtwlXlc7wKxB+Vzpg3naDtQUhwI72kxZJv3 2PtLT42vOpQG2k2W1B5ilyORxkfdisyAmVKhwGhdilnzVLN6ADpF8hmlOzDv4Kcc tl+081S/ZI1KMvekpsiu43gkIZ83aw== =NkL8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 17 11:23:43 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7413A0E8C; Thu, 17 Dec 2020 11:23:35 -0800 (PST) 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 9Ans20yp5L7m; Thu, 17 Dec 2020 11:23:34 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338403A0E60; Thu, 17 Dec 2020 11:23:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CB1AE389AC; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m9SbiclX722K; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 17199389A8; Thu, 17 Dec 2020 14:26:16 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5217E11B4; Thu, 17 Dec 2020 14:23:30 -0500 (EST) From: Michael Richardson to: mud@ietf.org, opsawg@ietf.org, iotops@ietf.org, suit@ietf.org In-Reply-To: <27659.1608229409@localhost> References: <27659.1608229409@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Iotops] Manufacturer Usage Description for quarantined access to firmware - draft-richardson-shg-mud-quarantined-access-02 X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 19:23:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > 5) Manufacturer Usage Description for quarantined access to firmware > draft-richardson-shg-mud-quarantined-access-02 [perhaps I should rename it with opsawg in the filename] > Abstract > The Manufacturer Usage Description is a tool to describe the limited > access that a single function device such as an Internet of Things > device might need. This is a small extension to RFC8520 which provides a new attribute to each ACL. It marks the ACL as being essential for firmware/software updates. In the parlance of draft-kuehlewind-update-tag-03 this document is an Exte= nds. The need for this extension became obvious during the PoC phase of the CIRA SecureHomeGateway back in 2018. We put a sample device into the deny list, kicking the device off the Internet, and and then wondered... so now what? How does it get updated? Is it landfill? There must be a better way. I believe that this work needs to be adopted by OPSAWG to be able to make p= rogress. I presented it at the spring IETF107 meeting in OPSAWG, but it is quite likely that are some Software Update people who haven't seen it. The slides are at: https://datatracker.ietf.org/meeting/interim-2020-opsawg-01/materials/s= lides-interim-2020-opsawg-01-sessa-device-quarantine-definition-for-manufac= turer-usage-descriptions-rfc8520-00 or: https://github.com/CIRALabs/shg-mud-quarantine/tree/master/presentations At present, the document isn't much more than a YANG modules with a lot of words in it! (Much like a third of the documents coming from the RTG area) The security considerations will need some work beyond "TBD": there are two= obvious concerns: 1) did a third party lie about what they essential connections are? This boils down to: how did the MUD controller establish trust in the MUD file in the first place. I have another document about that. 2) was did the manufacturer lazy and just marked everything as essential? Or, how can we be sure what's essential anyway? What kind of local policy might need to override this anyway, and does that render this all moot? In the two years since I started this document SUIT has made significant pr= ogress. One thing that the CIRA SHG team really wanted was to actually collect the firmware ourselves. That is, rather than allowing the device out to the network to get it's own firmware, we would have rather been able to discove= ry the URL of the new firmware using a standard protocol, cached it locally, a= nd then pointed the device at that copy. This would essentially have rendered the two concerns above irrelevant. SUIT has intentionally not standardized such a mechanism as being too much = of a bikeshed/rathole (I think), but I am interested if there is some interest in doing that. Perhaps in addition to this document, or maybe, instead of. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/bsDIACgkQgItw+93Q 3WXIegf/TVZcx9NkRXRuGulQ4U4EvZcn+PgYO1erpM+XCsYsgW5E6zz//3iag70I RQ/gh2ZYdiZtHQ5p00nFdv0OQ4QjgRmadz7FdNbiI0GuOKeR05jaQ/G+k+N4phhX ODqtTO5oAs2vXCAUDRlHFItrwAOCERunclULTzsP6NXJY61VdZXexc92/Jl9y3Ev QTp1eMvp8P/yUgeoEnvyPwEhx2vwpQob6ef86n0HJ9bjU5gecqNmXDmFh4L3nKyl /0vM7+FUtXEzE/C/ofAhQr0jCqxR5wUo0buzj4HYCrU/0Mm5czEaWhk3cNyTzmam Nk9sqnhP88mKHNeAWI6fch11j1j5TA== =/qtm -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 21 02:54:47 2020 Return-Path: X-Original-To: iotops@ietfa.amsl.com Delivered-To: iotops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563F43A109E; Mon, 21 Dec 2020 02:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZzf7OGXvL2T; Mon, 21 Dec 2020 02:54:36 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 0487F3A103D; Mon, 21 Dec 2020 02:54:35 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id w124so10863412oia.6; Mon, 21 Dec 2020 02:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rx7HI/ZcMZU9qJEFx/63DEd5yqFm3TDIgMIKjJjMnoY=; b=qSGGNXskNK5KoTzO2ObvVu4MqelVOOi7c4TBFSLnYR+XKbH8rIzlJ5V9BpKOw5hKjm IDYm2y+kaupUxnHXKXnwY2sEAl/sWxilr5Q2PSrRMQ0uI4ggFnaGsp/fxatqkhH8PbVq EzUHc3QWAeQMeIdrrhxd4CccTc0ZAVFE8F6mUFgoj6jHA/a4J6OVk/ZEHTFTYs7QLImP H94Pycxu2Wl0rB0KZuJ0BzldrUV45jdnzhcV1bdhejXLb2JnpwdqOoq5mDZSP/4kDFRc eN7svnT/DNdPjJE8P6vZ7vcMZ75XsesGwaZAc8iE83Xz0JlVOAA2eI4/ylhS+4171qZY /jpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rx7HI/ZcMZU9qJEFx/63DEd5yqFm3TDIgMIKjJjMnoY=; b=kpAQyvOZyovcm+hjjQVVpxXrFL5h4PbX5vlUORFNKAN8e0EVP/oiQYbEemBznmrEDG pgbeXJgN5CY45psHLnoq52OlC9GYJqN7bA97n90xFH5g5jVCl1DDkFdESpxGjTFTYPRI 6D/WSeoNn7TJKgNU/y9XMpmhtJWt/xHX7yqI8QxwNDb0ytJc+GvN8l0nbqviKCBjRcNG pWfYj3c5ZmRskBuL/vX4/9IapCXz+4Vs9EuJ+p/Ztzw6u1cbRdcTbz9cv9173voD2wvA 54PWLIwRnuWqm57p6kmV4w7udYSzoOoD/yoTa3irjWaUhOiEEIi1puW5dJodtaPrsc30 7L5Q== X-Gm-Message-State: AOAM532IupCyJjxcWHXCoe3sFjiVrRhiCCb+snDkwvdPhLRbl1Ur8zVp 6XjdxIKJmB66GnE7HuDOvU88p9riBHiSOroYHQ== X-Google-Smtp-Source: ABdhPJyEiY5vwEuml7qyGcSGhQmTvKPJIJXqmpWIURrnZPwJ2CGt1htjROl3i/MjSIKoYW6ap17B+Ff7YxhxXpdeKYQ= X-Received: by 2002:aca:4303:: with SMTP id q3mr10655010oia.133.1608548074907; Mon, 21 Dec 2020 02:54:34 -0800 (PST) MIME-Version: 1.0 References: <158561301296.11367.9776561744635554098@ietfa.amsl.com> <4603.1585620652@localhost> <20200331150202.GH50174@kduck.mit.edu> <600.1585687336@localhost> <5633.1585770340@localhost> <13227.1586052088@localhost> <14837.1586479192@localhost> <23785.1605650162@localhost> <26304.1607113986@localhost> In-Reply-To: From: Deb Cooley Date: Mon, 21 Dec 2020 05:54:23 -0500 Message-ID: To: Michael Richardson Cc: "anima@ietf.org" , "acme@ietf.org" , "iot-onboarding@ietf.org" , "iotops@ietf.org" , "lamps@ietf.org" , "Max Pritikin (pritikin)" , "Cooley, Dorothy E" Content-Type: multipart/alternative; boundary="0000000000009beb7505b6f7489d" Archived-At: Subject: Re: [Iotops] [Acme] [Anima] ACME integrations with BRSKI and the cmcRA EKU X-BeenThere: iotops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IOT Operations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2020 10:54:39 -0000 --0000000000009beb7505b6f7489d Content-Type: text/plain; charset="UTF-8" I don't post often, so go easy. And I've not read up on the current state of BRSKI or MASA. This response is based only on the original post. If you are looking for some sort of trust for an identity, then option 2 - the self signed cert w/ cmcRA bit set - is not it (as you allude to in your parenthetical). It is in the same category as a random certificate w/out the cmcRA bit (from your background). Option 3 is similarly flawed. raw public keys have no identity (obviously) and rely on knowledge of which ID goes with it via some sort of out of band mechanism. Now, I don't know how happy I would be to see cmcRA be an option in an auto issued certificate (i.e. via ACME). I'm not sure how that would work. We need to know the entity holding the key/certificate is actually supposed to have it. These are hard problems, for sure. Deb Cooley NSA for real work address: decoole@nsa.gov On Mon, Dec 7, 2020 at 8:54 AM Esko Dijk wrote: > Thanks for the useful intro Michael. > > > A Registrar that uses RFC8555 to talk to it's CA could have three > different > > kinds of anchors: > > The Registrar also could have different identities used at the same time: > > 1) ACME client TLS identity (towards ACME server) > 2) Registrar/EST-server TLS server identity (towards Pledges) > 3) Registrar/EST-server signing identity (for signing Voucher Requests) > 4) Registrar TLS client identity towards MASA server > > For #1, ACME client it could use any identity / 'account' that was able to > prove control of the DNS domain, so it can be unrelated to other > identities. > > > 1) it could use an RFC8555/ACME EE certificate that it obtained for > itself. > > In that case, the cmcRA bit is most likely not set. > > 2) it could have a self-signed EE certificate, where the cmcRA bit could > in > > fact be set. {Would it have any real meaning?} > > 3) it could use a raw-public-key. > > These options could be considered for the signing identity #3: > > 1) it wouldn't work if the 'RA' flag is not set. The BRSKI security > architecture depends on 'RA' being set for Registrars, and also ACP does. > In my view a MASA MUST check for 'RA'. > 2) this can work > 3) Registrar signs with a certificate not with a raw-public-key. And a > raw-public-key cannot have an 'RA' flag set. So that wouldn't work > > Option 2) looks good as an identity for signing Voucher Requests. Either > a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed-CA. > The latter is useful as it allows in the future more Registrars (with RA > flag set) > to be created within the same private domain (CA). Of course this > certificate / chain must then be created by hand i.e. it cannot be > automated using ACME. Do you see this as a problem? To me it seems > acceptable. > > Details of this solution: MASA will accept the above signing (since 'RA' > is set - check passes) and will pin one of these certs. The Pledge will too > accept as per BRSKI 5.6.2 because the Registrar's cert is either equal to, > or chains to, the pinned-domain-cert. > The Pledge will do after BRSKI-specific bootstrap operations the GET > /cacerts (Section 5.9.1) and the Registrar then serves back 2 CAs: { > self-signed CA , ACME CA } . The Pledge will then do EST e.g. > /simpleenroll with Registrar; and Registrar > meanwhile interfaces as a client with the ACME server to obtain a new > operational domain cert for the Pledge under the DNS domain owned by the > Registrar. The Pledge can verify this new cert against its trust store that > now contains the > two CAs: { self-signed CA , ACME CA } , so it will validate. Note that > the Registrar enrolls the Pledge into a domain (with ACME-issued cert) that > the MASA knows nothing about! I assume this is allowed by BRSKI as I read > that the Pledge is > supposed to install the /cacerts response in its trust store. > > Now if above solution option 2) works with ACME, there seems to be no need > to request certs with 'RA' set from the ACME CA. The 'RA' certs are under > the control of the Registrar's private domain. The auto-created EE certs > are created > by the ACME CA under control of Registrar. > > Or would there still be some need to use option 1) and update the ACME RFC > to enable ACME CA handing out certs with cmcRA set? > > > One thing that occurs to me that a pledge which *can* form an ACP, > probably > > should *not* if the cmcRA bit is not set. > > As said above the BRSKI security architecture depends on 'RA' being set > for Registrars, and also ACP does. So it seems risky to assume situations > in which it is not set and MASA lets the bootstrap continue. > So the Pledge doesn't need to evaluate if cmcRA is present - because the > bootstrap wouldn't succeed in the first place if cmcRA is absent, right? Or > do I miss something. > > Best regards > Esko > > IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl > > -----Original Message----- > From: Anima On Behalf Of Michael Richardson > Sent: Friday, December 4, 2020 21:33 > To: anima@ietf.org; acme@ietf.org; iot-onboarding@ietf.org; > iotops@ietf.org; lamps@ietf.org > Cc: Max Pritikin (pritikin) > Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --0000000000009beb7505b6f7489d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't post often, so go easy. And I've not = read up on the current state of BRSKI or MASA.=C2=A0 This response is based= only on the original post.

If you are looking= for some sort of trust for an identity, then option 2 - the self signed ce= rt w/ cmcRA bit set - is not it (as you allude to in your parenthetical).= =C2=A0 It is in the same category as a random certificate w/out the cmcRA b= it (from your background).

Option 3 is similarly f= lawed.=C2=A0 raw public keys have no identity (obviously) and rely on knowl= edge of which ID goes with it via some sort of out of band mechanism.
<= /div>

Now, I don't know how happy I would be to see = cmcRA be an option in an auto issued certificate (i.e. via ACME).=C2=A0 I&#= 39;m not sure how that would work.=C2=A0 We need to know the entity holding= the key/certificate is actually supposed to have it.

<= div>These are hard problems, for sure.=C2=A0

= Deb Cooley
NSA
for real work address:=C2=A0 decoole@nsa.gov


On = Mon, Dec 7, 2020 at 8:54 AM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
Thanks for the useful intro Michae= l.

> A Registrar that uses RFC8555 to talk to it's CA could have three = different
> kinds of anchors:

The Registrar also could have different identities used at the same time:
1) ACME client TLS identity=C2=A0 =C2=A0(towards ACME server)
2) Registrar/EST-server TLS server identity=C2=A0 (towards Pledges)
3) Registrar/EST-server signing identity=C2=A0 (for signing Voucher Request= s)
4) Registrar TLS client identity towards MASA server

For #1, ACME client it could use any identity / 'account' that was = able to prove control of the DNS domain, so it can be unrelated to other id= entities.

> 1) it could use an RFC8555/ACME EE certificate that it obtained for it= self.
>=C2=A0 =C2=A0 In that case, the cmcRA bit is most likely not set.
> 2) it could have a self-signed EE certificate, where the cmcRA bit cou= ld in
>=C2=A0 =C2=A0 fact be set. {Would it have any real meaning?}
> 3) it could use a raw-public-key.

These options could be considered for the signing identity #3:

1) it wouldn't work if the 'RA' flag is not set. The BRSKI secu= rity architecture depends on 'RA' being set for Registrars, and als= o ACP does. In my view a MASA MUST check for 'RA'.
2) this can work
3) Registrar signs with a certificate not with a raw-public-key. And a raw-= public-key cannot have an 'RA' flag set. So that wouldn't work<= br>
Option 2) looks good as an identity for signing Voucher Requests.=C2=A0 Eit= her a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed= -CA. The latter is useful as it allows in the future more Registrars (with = RA flag set)
to be created within the same private domain (CA).=C2=A0 Of course this cer= tificate / chain must then be created by hand i.e. it cannot be automated u= sing ACME.=C2=A0 Do you see this as a problem? To me it seems acceptable.
Details of this solution: MASA will accept the above signing (since 'RA= ' is set - check passes) and will pin one of these certs. The Pledge wi= ll too accept as per BRSKI 5.6.2 because the Registrar's cert is either= equal to, or chains to, the pinned-domain-cert.
The Pledge will do after BRSKI-specific bootstrap operations the GET /cacer= ts (Section 5.9.1) and the Registrar then serves back 2 CAs: { self-signed = CA ,=C2=A0 ACME CA } .=C2=A0 The Pledge will then do EST e.g. /simpleenroll= with Registrar; and Registrar
meanwhile interfaces as a client with the ACME server to obtain=C2=A0 a new= operational domain cert for the Pledge under the DNS domain owned by the R= egistrar. The Pledge can verify this new cert against its trust store that = now contains the
two CAs: { self-signed CA ,=C2=A0 ACME CA } , so it will validate.=C2=A0 No= te that the Registrar enrolls the Pledge into a domain (with ACME-issued ce= rt) that the MASA knows nothing about!=C2=A0 I assume this is allowed by BR= SKI as I read that the Pledge is
supposed to install the /cacerts response in its trust store.

Now if above solution option 2) works with ACME, there seems to be no need = to request certs with 'RA' set from the ACME CA.=C2=A0 The 'RA&= #39; certs are under the control of the Registrar's private domain. The= auto-created EE certs are created
by the ACME CA under control of Registrar.=C2=A0

Or would there still be some need to use option 1) and update the ACME RFC = to enable ACME CA handing out certs with cmcRA set?

> One thing that occurs to me that a pledge which *can* form an ACP, pro= bably
> should *not* if the cmcRA bit is not set.=C2=A0

As said above the BRSKI security architecture depends on 'RA' being= set for Registrars, and also ACP does. So it seems risky to assume situati= ons in which it is not set and MASA lets the bootstrap continue.
So the Pledge doesn't need to evaluate if cmcRA is present - because th= e bootstrap wouldn't succeed in the first place if cmcRA is absent, rig= ht? Or do I miss something.

Best regards
Esko

IoTconsultancy.nl=C2=A0 |=C2=A0 Email/Teams: esko.dijk@iotconsultancy.nl

-----Original Message-----
From: Anima <anima-bounces@ietf.org> On Behalf Of Michael Richardson
Sent: Friday, December 4, 2020 21:33
To: anima@ietf.org;= acme@ietf.org; iot-onboarding@iet= f.org; iotops@ietf= .org; lamps@ietf.or= g
Cc: Max Pritikin (pritikin) <pritikin@cisco.com>
Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--0000000000009beb7505b6f7489d--