From nobody Fri Nov 12 04:44:42 2021 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 F209A3A0E94 for ; Fri, 12 Nov 2021 04:44:41 -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, 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 d5m42BspwM2H for ; Fri, 12 Nov 2021 04:44:37 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 4C2333A0E96 for ; Fri, 12 Nov 2021 04:44:37 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id nh10-20020a17090b364a00b001a69adad5ebso7504884pjb.2 for ; Fri, 12 Nov 2021 04:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:cc:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=A+plH65bB9VOPlRUftxw7Yl5FUjVwRQBMSXLBgfUQzg=; b=KbDBeLTueJdOLgrRs/s9gWyhJf0UtRmwS8kJuVQROad4CgGTzj7E5gaVJc+QBYvg3/ JWmjDIF7RpcIBSaHMdgzIMpdwzLZTfKrjRhIM1DJZsgtyLMKNgHuLG0JTGhmcAPcoexq RSyb62m9dso/3Al/a1thNGSyHzL3GvVnsAehx6ryWiTA24/JKH1GSRQVWuxSp2frrgIW bgr/JopX4Fnj53XZdlQy489/Uz75Z3u/LfAK0oM5A9/w71fYXN/7CR3Xb6FYkYE35EzW rJ1/G40XpgK4m4wB19rJb1X6zXYGvVJWZwoWvF+wi79G6/X6E8PONLva3iA2GHxmLcqH Xxaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=A+plH65bB9VOPlRUftxw7Yl5FUjVwRQBMSXLBgfUQzg=; b=4SJ2fyqcAVfJRiS/Kv8meTigoriUSMATlM+Rz9BE5/wNv3EkV76Qn/D7FVdlKhfkmR YJjJLhWbsMrO/d1XawKjdtYTVgpkbifuqPV5dn+e/7RvaSqWGtzViEAs+ryAFKYBMTI1 /DwckmVk4ykMCjNo+u9EQRQPgulB7UV3GEBDg3xGKSwDMyfuLvyzGMGvdjkKWzojFmSX 7NmpmWzlwHkykAAPPG4yYpfnBqtCpB5tXzj43jB2CBmwU+pd100P114sgYfoF5aF3fIG Maf6ScGn9qiSJ1dl6UTYSpjmgjbimop9Zq5KX3Mcnma2+E/M3vp4im+mFbKN4ymktYw7 cpEA== X-Gm-Message-State: AOAM530Y432IyBNg04p7Hf/9is58CFQN2FIoxL8s8gVjiMY3WZBnAoEM faOX52XRAf5KIhv9J58QrSEYI80RQuth5A== X-Google-Smtp-Source: ABdhPJzjWVCWPU0YfKIt/0AgcbIQD+RubVz4kTqMgz76tm53IRJRZexWyiMGCCgxPzaDFJORBg2q8w== X-Received: by 2002:a17:902:e9c6:b0:141:c588:99b2 with SMTP id 6-20020a170902e9c600b00141c58899b2mr7705866plk.63.1636721075368; Fri, 12 Nov 2021 04:44:35 -0800 (PST) Received: from [192.168.1.15] (c-73-202-182-183.hsd1.ca.comcast.net. [73.202.182.183]) by smtp.gmail.com with ESMTPSA id u13sm4742252pga.92.2021.11.12.04.44.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Nov 2021 04:44:35 -0800 (PST) From: "Kiran Makhijani" To: "Michael Richardson" Cc: "iotops@ietf.org" Date: Fri, 12 Nov 2021 12:44:34 +0000 Message-Id: In-Reply-To: <20485.1635269111@localhost> References: <163519232941.3009.16757291279466571366@ietfa.amsl.com> <9B658720-6682-478C-96D5-13EE50511884@getmailspring.com> <20485.1635269111@localhost> Reply-To: "Kiran Makhijani" User-Agent: eM_Client/8.2.1687.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt 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, 12 Nov 2021 12:44:42 -0000 Hi Michael,=0ASincere apologies, somehow I did not see this email until now= . Maybe a =0Aconfig-error with my inbox filters.=0A=0AYour point is well ta= ken and to be honest I struggled myself on how much =0Adetail should go in= - whether it is too much or too little. But I had =0Ato start somewhere. T= hat is why, there is nothing as a proposal, but =0Asome place holders and= exposing different areas.=0A=0ASection 5, just draws an architectural view, = I tried to map IIoT levels =0Ato interfaces. This is where exchange of pro= tocols and security occurs =0Aand help us normalize how traffic could flow= in and out of a factory =0Afloor. One example, would highlight what (how) e= xisting solution such as =0ADetnet edge/cloud cases come into play. Second= ly, the network on the =0AIndustry zone itself - I had written this in prev= ious document andI did =0Anot copy over (just yet). Third, there is an endp= oint/device aspect its =0Aonboarding, addressing, trust etc.=0A=0AI will tr= y to raise this during IOTOPS, and accordingly progress the =0Adocument.=0A= =0A-Kiran=0A=0A------ Original Message ------=0AFrom: "Michael Richardson"= =0ATo: "Kiran Makhijani" =0ACc= : "iotops@ietf.org" =0ASent: 10/26/2021 10:25:11 AM=0ASubj= ect: Re: [Iotops] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt=0A=0A>= =0A>Kiran Makhijani wrote:=0A> > As per the feed= back from last meeting, we came up with a sketch of=0A> > framework for = Industrial networks. We hope to have more discussions and=0A> > receiv= e feedback on this document.=0A>=0A>Last time, we were discussing:=0A> = I-D.draft-km-industrial-internet-requirements=0A>=0A>I have reviewed the "= iiot-frwk" document, but I don't really know what you=0A>intend to do with= it. You've described a whole bunch of pieces, but I can't=0A>really see a= proposal in that satisfies:=0A>=0A>from your abstract:=0A> > It suggest= s the use=0A> > of IIN to bridge the differences between OT and IETF te= chnologies.=0A>=0A>Section 5 deals with this, but if you intend to propose= something, I've=0A>missed it.=0A>=0A>--=0A>Michael Richardson . o O ( IPv6 I=C3=B8T consulting )=0A> Sandelman So= ftware Works Inc, Ottawa and Worldwide=0A>=0A>=0A>=0A> From nobody Wed Nov 17 10:57:16 2021 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 B9B183A005C for ; Wed, 17 Nov 2021 10:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 GPrBXvIHrwpA for ; Wed, 17 Nov 2021 10:57:08 -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 15DAD3A003F for ; Wed, 17 Nov 2021 10:57:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D23C21801B; Wed, 17 Nov 2021 13:59:30 -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 OB33Ig5N4xHp; Wed, 17 Nov 2021 13:59:27 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C8BA1800C; Wed, 17 Nov 2021 13:59:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637175567; bh=qm7kmFWwTItiYucwaPkjbrcrFgcdjja7+biRITLWUho=; h=From:To:Subject:In-reply-to:References:Date:From; b=6U/nF4WKiR+2XoyT1SPtuSxKxwbWgI9JY6RVcUyL4Lo7y/XzWkQBtDB+wiXbs5h8J Q+iCXxbHlSd1ShojnubjchLCY0y2MPA2avxMdm7VairYi7u1VI2oNqTk4nlmho6YhD NEwInX0Xfc0xjN2mNfTqA1kP4W9nG27Avo939EdMoaUEx8EtpR17MdomDVNumLaSkn oCUvHJ2yEMin1iWRJr6MHixvz24bCVyrltTCAkBsIUMK6ycZxXkVDBRs2SVeRRSaMM F+t22+o//xVe3qd5JWk0w12X95J320U7Z9PDSAWLWmLBcQU/wimD+ptKKO6StRtHgn /ZPadF7rvt3Hw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63ADC8D5; Wed, 17 Nov 2021 13:57:01 -0500 (EST) From: Michael Richardson To: "Kiran Makhijani" , "iotops\@ietf.org" In-reply-to: References: <163519232941.3009.16757291279466571366@ietfa.amsl.com> <9B658720-6682-478C-96D5-13EE50511884@getmailspring.com> <20485.1635269111@localhost> Comments: In-reply-to "Kiran Makhijani" message dated "Fri, 12 Nov 2021 12:44:34 +0000." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 X-Attribution: mcr 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] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt 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, 17 Nov 2021 18:57:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kiran Makhijani wrote: > Hi Michael, Sincere apologies, somehow I did not see this email until > now. Maybe a config-error with my inbox filters. (Google hates my SMTP sender, and puts a lot of stuff in spam now.) > Your point is well taken and to be honest I struggled myself on how > much detail should go in - whether it is too much or too little. But I > had to start somewhere. That is why, there is nothing as a proposal, > but some place holders and exposing different areas. > Section 5, just draws an architectural view, I tried to map IIoT leve= ls > to interfaces. This is where exchange of protocols and security occurs I had suggested that having a way to map IPv6 IID's (the lower 64bits) to these other legacy systems, e.g. Modbus, Profibus, CANbus, Profinet... so that all end points could be addressed from an IPv6 backbone via gateway systems. I think that would be useful work, but really, it needs to be do= ne along *with* someone building those gateways. ("running code") Your document claims that tunneling these other things across ethernet/IPv6 would be too much overhead. I strongly disagree, given Gigabit Ethernet, it's just not an issue when the legacy transports are in the kilobit or les= s. This mapping could/should be coordinated with DETNET, and I'll be that that there people there who want to do this. For things like Ether/IP which is strongly IPv4 focused, NAT64 *into* that network provides a very nice way to distribute and connect networks while n= ot introducing weird default routes into those networks. (that's because NAT64 translates to an IPv4 address that is IPv4 on-link) =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+93Q3WUFAmGVUH0ACgkQgItw+93Q 3WUc3gf+KyrKW30SXjTrz8AdYSmgL4lzB7Wsw/ZuX3O49J2QkZW/eRNomT8iL/qC 3Cor/jZwMbatYRZr91gYQOHvtRfsv/qbG2owbyINChOAhf946FlYgk6hD2nmdVI+ xfkJEk9w7qvjEY/B90FOsVLvopiTtNuN2SYBDg3CllsvadDHq4oP32cGNI6p4Zxq 6hPEVemkA/DkacXRTgR1DM8GfUth8yJu/rUmIh0ikhHwai+Rq0EMUKSHdDALJEKh dtStFtX6ai0yOReaG4oaSas3DoURKLNiRdgcZ00bg1u82bc1vawaH+8ibBfAd9QE ixojEWaxCU65f5xhxmU0rLpkZzAxiQ== =zw5R -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 18 17:41:53 2021 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 89F3D3A0045 for ; Thu, 18 Nov 2021 17:41:52 -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, 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 TOtF1our2Zur for ; Thu, 18 Nov 2021 17:41:47 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 4D9653A0038 for ; Thu, 18 Nov 2021 17:41:47 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id r5so7186012pgi.6 for ; Thu, 18 Nov 2021 17:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=fjCKpnCPNqRktBua4xBynyiqdCivzsH36iROZURhVhw=; b=ZuODNQCvZlCE1PYuyJ97j/pxZEgf3KFCVmTKXzzK1eO5F4R3mO+h+VR3gGfHwjmOxJ ycn5QdoacA2eQ2hklPMBGw4RgcT54KlHo3bs8kpr+8Zgqmd7XmIb1mZGoQm/SBMYzXOU JwX6lAHBk1SvrdeabeJQvbjueaUTY85PO2//i4eVWORpzUfxokGjQHtV5XKbugfLBrjG +sqQc/o/iK7bZVFLNgcbJmHN1t0UsaZmwOUkUrk9xdxV337AoY5MKZieQ8wgnWN+9b+o bt2gW00oOwviDzBNC3aauXDCMvjq7t19eg/qziFeYyCUE92nTiTR5ZAmEx+mRL/XLUjF Auzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=fjCKpnCPNqRktBua4xBynyiqdCivzsH36iROZURhVhw=; b=oqc5TAOavboXZbIjpUlK9q1zK5+rjFY4mtxV9/fGGZhC2MdNKk6N77663XUR7ApPZl 2KoohAYSi24182L47n34G3np6LEkGGvcFPQWQgqnjDmWTAXRRKzBjsnUtOWzIQFzQBIU m8JOfu9xEgQmeA6nYI4MpPbRbg8m0EQuqiVtJWi6TcaEjKdFDGT2pTYIQtQvIDgRHmky p95cfpMMba8HrBnqijocMyKijAPu/guiE6UnvLfgoYTWOc58djKE74Ezvjf43asdxniP cvJoprQHmRcpD6qDonFDy3+c+AF7DFASx0CfZdHA2Z4gcOilS/ef1ZUZJpCRh87Kg6ho MLRg== X-Gm-Message-State: AOAM530JfCe05L2kBiIXYjiljcGxyn7aFfLBVSRCB5lQ4jh/wZ97vKES Jlo8VboVJxqBt3cQ1b3DyXyDE0i7mFE= X-Google-Smtp-Source: ABdhPJxuT3bGsByCsfhA+rOy7nUfrv7nACwDHY9T8CnhSOLYCuKe/I3oXXxeIDUvQNiwkZQuplZoxw== X-Received: by 2002:a63:b252:: with SMTP id t18mr14663653pgo.19.1637286105136; Thu, 18 Nov 2021 17:41:45 -0800 (PST) Received: from [192.168.1.15] (c-73-202-182-183.hsd1.ca.comcast.net. [73.202.182.183]) by smtp.gmail.com with ESMTPSA id b18sm693259pjo.31.2021.11.18.17.41.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Nov 2021 17:41:44 -0800 (PST) From: "Kiran Makhijani" To: "Michael Richardson" , "iotops@ietf.org" Date: Fri, 19 Nov 2021 01:41:43 +0000 Message-Id: In-Reply-To: <23469.1637175421@localhost> References: <163519232941.3009.16757291279466571366@ietfa.amsl.com> <9B658720-6682-478C-96D5-13EE50511884@getmailspring.com> <20485.1635269111@localhost> <23469.1637175421@localhost> Reply-To: "Kiran Makhijani" User-Agent: eM_Client/8.2.1687.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iotops] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt 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, 19 Nov 2021 01:41:53 -0000 Hi Michael,=0APlease see inline. Yes, use of IID is a good starting point.= =0ACheers,=0AKiran=0A=0A------ Original Message ------=0AFrom: "Michael Ric= hardson" =0ATo: "Kiran Makhijani" ; "iotops@ietf.org" =0A=0ASent: 11/17/2021 10:57:01 AM= =0ASubject: Re: Re[2]: [Iotops] Fwd: I-D Action: =0Adraft-iotops-km-iiot-fr= wk-00.txt=0A=0A>=0A>Kiran Makhijani wrote:=0A> > = Hi Michael, Sincere apologies, somehow I did not see this email until=0A> = > now. Maybe a config-error with my inbox filters.=0A>=0A>(Google hates = my SMTP sender, and puts a lot of stuff in spam now.)=0A>=0A> > Your p= oint is well taken and to be honest I struggled myself on how=0A> > muc= h detail should go in - whether it is too much or too little. But I=0A> = > had to start somewhere. That is why, there is nothing as a proposal,=0A>= > but some place holders and exposing different areas.=0A>=0A> > S= ection 5, just draws an architectural view, I tried to map IIoT levels=0A> = > to interfaces. This is where exchange of protocols and security occur= s=0A>=0A>I had suggested that having a way to map IPv6 IID's (the lower 64b= its) to=0A>these other legacy systems, e.g. Modbus, Profibus, CANbus, Profi= net...=0A>so that all end points could be addressed from an IPv6 backbone v= ia gateway=0A>systems. I think that would be useful work,=0AYes, I like t= he idea of mapping type/plc/devices to IID. For an =0Aindustrial network, i= t gives us enough room to provide PLC & device =0Abinding. It definitely do= es tunnel free connectivity. With gateway, you =0Amean the border gateway - = the boundary of factory floor - the traffic =0Aflow out of a cite. Am I ri= ght?=0A=0A>but really, it needs to be done=0A>along *with* someone building = those gateways. ("running code=E2=80=9D)=0A=0AWhile "running code=E2=80=9D = at least on linux-type POC, should not be too =0Adifficult once we have a= proper encoding format. The hard part is =0Afinding interest from those bui= lding such gateways.=0A>=0A>=0A>Your document claims that tunneling these o= ther things across ethernet/IPv6=0A>would be too much overhead. I strongly = disagree, given Gigabit Ethernet,=0A>it's just not an issue when the legac= y transports are in the kilobit or less.=0A>This mapping could/should be co= ordinated with DETNET, and I'll be that that=0A>there people there who want = to do this.=0AIt=E2=80=99d depend on the design. imagine on a factory flo= or you end up adding =0Anew health check and security sensors without reall= y upgrading the =0Abandwidth and routers. Each sensor emits a byte of infor= mation at =0Aregular intervals. We=E2=80=99d be burning 20-40 bytes of head= er to ship one =0Abyte of data. If remote visual inspections using cameras= and advanced =0Amedia technologies take off, then there is a high volume of = real-time =0Adata.=0A>=0A>=0A>For things like Ether/IP which is strongly I= Pv4 focused, NAT64 *into* that=0A>network provides a very nice way to distr= ibute and connect networks while not=0A>introducing weird default routes in= to those networks. (that's because NAT64=0A>translates to an IPv4 address t= hat is IPv4 on-link)=0AIt could. But then we will have 2 things at the boun= dary protocol - IID =0Aand NAT64. May be we can build on IID first, and see = if the need for =0ANAT64 comes up (a personal preference for non-NATed sol= ution)=0A>=0A>=0A>=0A>--=0A>Michael Richardson .= o O ( IPv6 I=C3=B8T consulting )=0A> Sandelman Software Works In= c, Ottawa and Worldwide=0A>=0A>=0A>=0A> From nobody Fri Nov 19 07:07:33 2021 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 E0B913A0120 for ; Fri, 19 Nov 2021 06:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NONE=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=nqminds-com.20210112.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 l8aTSEvxF0w1 for ; Fri, 19 Nov 2021 06:47:24 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 D20703A011F for ; Fri, 19 Nov 2021 06:47:24 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id k1so10429766ilo.7 for ; Fri, 19 Nov 2021 06:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nqminds-com.20210112.gappssmtp.com; s=20210112; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=imUooG9YaiiREp/uw9+av3SErsnxOSp8/pFZCVEXmos=; b=pTT3v1kRr5440JMuwBBTTOcKDnoptYZQkvtnb3vXDpmuaGOUzL1i/9Y21Wmu7qzcPo +gsdpWGFmUq8SyLhrv3rN1ccKPJZuDySi7ycNmkBD5hpnJKcN6pvdXzKbDFm8AJIsr/i M1iEoeJnXa7uGCzQgxh3WfcbBqDpeD6YSZjRb+SJwIPEVkm6NFbOcvqhchFsK7Z0QMZm THV9U+Nz8paTXTpuMiDBBV6pgcM2IF/eUEnz88a5/FbJCUafW6c0ZpPIQJaCx/1KZ3aN gxqUmH55lqXZ4XmIvhH2+Ng2iFY0a6cQzbeqfZjiDZO3yUxoW/VwcW7tyUnLeTk8luZP 9kfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=imUooG9YaiiREp/uw9+av3SErsnxOSp8/pFZCVEXmos=; b=BC1Z3LbWDDG+FAJH36Y08/SDkAtpemhIwyGLBtLS8MEfCnrqXrskpcK12h16iNv28V OKYtlteZhnTJfY9iLYfXzzxVZEPpzGMvnaQuyyZdZJc+B4UOgtNUrqFQnG/xLR5AsOog EjdnsRRaL1jLmjlBarY3SWihBa2VGwfRhpgfyPe15Ph2khGhuLx5tgBnr5X7aZ+4OBW3 SVgXfcYGuRbILNqhZBGHbFqzOzUkAh/zLbAgjf5cdAq32h9zvYt8VWknrYZsV7JctfWZ Ln+QH49kMWU2wcl1W9+0h0NJgQAYuqHmKfKmRnsY6hCTjSYpUmkVJimHLf7HL/NTeY9h oi4g== X-Gm-Message-State: AOAM532meYjDs/rlUb2Hy96WkTjm0gYpeysK5H8nHIj+tDDV97S3jAwf zCEW1A+Ve69S5vap5Hk+Eew3N0agMVvjIDU8IDIGgLHdKeG3TA== X-Google-Smtp-Source: ABdhPJyEzicNi5E9A5dmtG1bPamU7tMsF4ClrEA0p+RkYQUpFlT7YJ0m8URlzGRNz2TBbLIMsrZFvQ+pk0Uc9GP+THY= X-Received: by 2002:a05:6e02:190b:: with SMTP id w11mr5340120ilu.211.1637333242407; Fri, 19 Nov 2021 06:47:22 -0800 (PST) From: Nick Allott References: b18ee3b9312ecfc621fcd1417bd4625e@mail.gmail.com In-Reply-To: b18ee3b9312ecfc621fcd1417bd4625e@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdfdT/CAJ/TZLQYiQb2LYxQUT/elGgABFgWA Date: Fri, 19 Nov 2021 14:47:19 -0000 Message-ID: To: iotops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 19 Nov 2021 07:07:32 -0800 Subject: [Iotops] Secure browsing local web resources 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, 19 Nov 2021 14:47:29 -0000 Thanks for the opportunity to present last week. Pleased it generated some discussion! [1]. The slides [2] I note neglected to include the reference to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the problem. Accessing local web base resources locally and securely, we think is an important problem to address. The IETF community is better placed than most/all to qualify and refine this requirement and help develop and evaluate the potential solutions. These are the active questions we have, which it would be useful to get confirmed (or refuted) 1. There is a problem: there is a clearly defined issue. a) Bootstrapping a TLS connection between a browser and a local web resource (IOT or not) on local internet (reserved IP address/Private Use) is hard to do b) Given (a) sniffing administrative passwords for local resource (e.g. IOT), an otherwise intercepting traffic is relatively easy to do and therefore a serious internal threat 2. It's a pervasive problem: the problem currently manifests itself on many/most consumer routers and many/most IOT devices that connect via Wifi and/or cabled IP. 3. There is no known best practice for practically and securely authenticating local web clients against, local IP based IOT devices We would be delighted in ether outcome: either agreement in the statements above, or a clear refutation of any of the issues. We hope to publicise the internal document outlining a potential solution space next week. We are just cleaning the docs and making ready for comment. I will follow up with the links asap, which assuming there is agreement an issue exists - may help plant some seeds on how it can be addressed But in the interim, there are further comments/discussion that help calibrate the problem, that would be great. Also reminder, public facing paper on the problem [4] [1] https://jabber.ietf.org/jabber/logs/iotops/2021-11-12.html [2] https://datatracker.ietf.org/doc/slides-112-iotops-suib-browsing-local-web -resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special -case/ [3] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf [4] https://manysecured.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow ser-WG.pdf Nick Allott nquiringminds From nobody Fri Nov 19 11:30:15 2021 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 A9B783A09FB for ; Fri, 19 Nov 2021 11:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 N3qea4gs324P for ; Fri, 19 Nov 2021 11:30:08 -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 DE5C23A09F9 for ; Fri, 19 Nov 2021 11:30:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CC6091801B; Fri, 19 Nov 2021 14:32:38 -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 Ax8Hf_lXRJ3Q; Fri, 19 Nov 2021 14:32:34 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46F891801A; Fri, 19 Nov 2021 14:32:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637350354; bh=TMR/NVpM/Ons9Nhf0VG6ZU2FLrTLPGyFNEz595fpxhI=; h=From:To:Subject:In-Reply-To:References:Date:From; b=8+KuoGynt5TtmIrFqt13+4AS7OOiRWPRgW/Qx7NsNIP5Kqub5fCgzrJfeoN6mSuzY eETAGyqAD4Qz93O0NOlusItbrYAzTpMZqvNwhtxHfZWBR03UAGWIGM1lf/k+mt/jGY +FbJFU1v7iOxbDoCsosDvkesAwSl2xxE5XOpcVcC7Gi9heNuJxrCcJrUOQYe3okNFj IaTCwAYN/KGgEA/jg/3jSBCwXYuozQaK3/BFene4z+bu3vdR987z64/xfFjzYqW2Ul Rts3o6MjhycrqBTNgNn/KTG+VIDo67OsCMvmPaIRckNq0VTb0VOtZWFsJAo7E1v6aj JNrRdclOwVIxg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 75152A9F; Fri, 19 Nov 2021 14:30:00 -0500 (EST) From: Michael Richardson To: "Kiran Makhijani" , "iotops\@ietf.org" In-Reply-To: References: <163519232941.3009.16757291279466571366@ietfa.amsl.com> <9B658720-6682-478C-96D5-13EE50511884@getmailspring.com> <20485.1635269111@localhost> <23469.1637175421@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] Fwd: I-D Action: draft-iotops-km-iiot-frwk-00.txt 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, 19 Nov 2021 19:30:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kiran Makhijani wrote: >> I had suggested that having a way to map IPv6 IID's (the lower 64bit= s) to >> these other legacy systems, e.g. Modbus, Profibus, CANbus, Profinet.= .. >> so that all end points could be addressed from an IPv6 backbone via = gateway >> systems. I think that would be useful work, > Yes, I like the idea of mapping type/plc/devices to IID. For an indus= trial > network, it gives us enough room to provide PLC & device binding. It > definitely does tunnel free connectivity. With gateway, you mean the = border > gateway - the boundary of factory floor - the traffic flow out of a c= ite. Am > I right? No, I mean a gateway between the legacy systems and the IPv6/ethernet backbone that connects parts of the factory together. It could, yes, at the boundary of the factory, but it could also be within the factory. >> but really, it needs to be done >> along *with* someone building those gateways. ("running code=E2=80= =9D) > While "running code=E2=80=9D at least on linux-type POC, should not b= e too difficult > once we have a proper encoding format. The hard part is finding inter= est from > those building such gateways. Yes, the point being, if there isn't demand for such a thing, then maybe don't write the spec. >> Your document claims that tunneling these other things across ethern= et/IPv6 >> would be too much overhead. I strongly disagree, given Gigabit Ethe= rnet, >> it's just not an issue when the legacy transports are in the kilobit= or less. >> This mapping could/should be coordinated with DETNET, and I'll be th= at that >> there people there who want to do this. > It=E2=80=99d depend on the design. imagine on a factory floor you en= d up adding new > health check and security sensors without really upgrading the bandwi= dth and > routers. Each sensor emits a byte of information at regular intervals= . We=E2=80=99d > be burning 20-40 bytes of header to ship one byte of data. If remote = visual > inspections using cameras and advanced media technologies take off, t= hen > there is a high volume of real-time data. I don't understand the for instance. If the new sensor is a modbus/profibus/canbus, then it would live behind su= ch a gateway. If the new sensor is IP, then there would be no tunnel. It's only if you have a (new) need for some sensor behind (say) modbus gateway A, to talk to an actuator behind modbus gateway B. The distance is too far for the modbus, so the gateways encapsulate over ethernet. Modbus runs over RS232 and 432, and has speeds in the 100kbs maximum. That would hardly tax a switched GbE. And Modbus already has versions that run over TCP, and IP. >> For things like Ether/IP which is strongly IPv4 focused, NAT64 *into= * that >> network provides a very nice way to distribute and connect networks = while not >> introducing weird default routes into those networks. (that's becaus= e NAT64 >> translates to an IPv4 address that is IPv4 on-link) > It could. But then we will have 2 things at the boundary protocol - I= ID and > NAT64. May be we can build on IID first, and see if the need for NAT6= 4 comes > up (a personal preference for non-NATed solution) The point of the NAT64, is to embed IPv6 to IPv4, so the two things are not seperable, if embedding multiple RFC1918 networks into a single IPv6 management space is going to be done. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGX+zgACgkQgItw+93Q 3WV85AgAmPwrWyAnHlT9B3oWBNH9Y/YmgHn9+YOUPs1SAuNtvSRbGxMOcBHyMdIl kOWkzjTYg6hycdD9dr1PvDascVqyfESq3wccbMzTepcYHp9vVlVbW6Ww6ihytJP4 6DwwfeW8BVrwLg8rmUc2PBDmXNLz/U8AglSfGSvtvYzPYywoigDtN6TH3SZhe8IY u17XjdHuIFCPw5bEbCyV6OEwKX8xAMk8pElz6AqnUcPJLFBjbZyC4MhSdN7VPx0e crnypujMUOQdfhHuFyRjOmiguSmNsx9avZQY5IJ1aXGxDWnLvTGfmUZ/e4O8PQUx iOpMbyOryZ+BzD+sv/+TdAvDLp6uoQ== =ndnc -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 22 02:31:00 2021 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 740E83A07D4 for ; Mon, 22 Nov 2021 02:30:58 -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 1CXRy1AtMxDM for ; Mon, 22 Nov 2021 02:30:52 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130127.outbound.protection.outlook.com [40.107.13.127]) (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 81DB03A07CF for ; Mon, 22 Nov 2021 02:30:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a4S+ZjNWcYpmO32ypbVfkjMUu5fFSEWrC7EAKlFf+iT/hvq3kXBDuOMJFbpwWdONkPG8EFMkF/mo/pMh6CoRb1g5xQSO+/9YQo+szAiSnLPMxdm5ABvo+jkOzH5ADzZWBe/PQlPcdzBXJxo6H/KG5fYIfSZeR+UEFodwlEvLWKHRsa5mTayvgugeOBbLaoa54BCy+YQbHu7+7yPfhFBxxm6hAIsnxtZnUmySAjRQyb03iqRcyxY34sogJyuZLN+ETp/UCBomrEqYVyeCn/mM4wahfEq1dg+aoF+mqH3aQWtZekqlSgDAGkMNALH45tM2HlVI+NAaEaYUFbCM5fqu8Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vslxzGMMKhcJl2JV1TxSMy2z/BU0kfFFwhrEo1ju290=; b=OS2LITYnyGSY9Ffjwg8ZhhvMd5dbewqbwWXp6QxFBVfzxNd80eVmG2kvwVLUCjfyfs5TCKrzAjwcY0qLvRCBZNhAyDF7m+E7uCWWu3fsUbbyl5dWGCWZJ7T7XeZ4KsX6i0WOFXVRGAqM6xEmp9R/6GnE95yKxuMZYKV9xfteWokGwJ7jT7wwzcvOwTD49Cyk7tt2bILSsY5QqJIvSqLeIJ0kcDNMcBr+0xdzyRPhGo8PXn236gedDuwRGepaRXoJCW6YdJ9id8bhJBUUMF/8UE5fHWpbcbTsrqR+gInJbezLUvuB8xO0GVboDM+ncfbD27nCjHwxmx+ASnw1pc3EkA== 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=vslxzGMMKhcJl2JV1TxSMy2z/BU0kfFFwhrEo1ju290=; b=suJXgJ7gXd0uOTynx5xXs14X+XFFu9LgLO54n2n+BD8koTRt5qw28a8DHYb5lZyq9u3nAukhH3mOguX0/fyrmey1ReaPllqH7gRvpBjZkJ6OF367E7xDc53A7/O3SjOO0u9NDqI9jx8uJCCWTuNMIarlPq2YUoy5WNUWoc9ps8c= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1569.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3e7::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.22; Mon, 22 Nov 2021 10:30:42 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::c41d:c9d6:d8c7:65c8%7]) with mapi id 15.20.4713.025; Mon, 22 Nov 2021 10:30:42 +0000 From: Esko Dijk To: Nick Allott , "iotops@ietf.org" Thread-Topic: [Iotops] Secure browsing local web resources Thread-Index: AdfdT/CAJ/TZLQYiQb2LYxQUT/elGgABFgWAAIyS3bA= Date: Mon, 22 Nov 2021 10:30:41 +0000 Message-ID: References: b18ee3b9312ecfc621fcd1417bd4625e@mail.gmail.com In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9312d17-e6b3-49c0-603f-08d9ada3228f x-ms-traffictypediagnostic: AM9P190MB1569: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pBLsJoA1zr7EL74/86F8m2TwtSFXI4G5Xin2k/vr83Us/lvCR3JvYMKwMiY44uH9AN6bQ2eCuKPP/WTmVYQpV1qw2OmALQoqYKRyGW8XaSw/Gy7P6uL5AT6KU/TnykRZfnPoG4HVjOCAWyDG4Fxj7BtwWUH8ker9fqwzwvF2kJkTHO5vpRU8bTBQ75iYF3iIISTGKDrh66mtsEwHNT3FjnnNO/nqgJ1AOYE9xStW9CPPsO8K44TyD9fTB+H9Fk09F60ZQh8HLAR26Hwpk7spY01t2cvlqgvUtQuEB/x86d5z/UyBpPcUz2U40q58TKh9XTsXCW5XYkOCp0Iy/FkpJ5jr6E+1Ip1AhdTz/ykU7QVFow3fhnEOAi2fKFJ/+8+nVoIFdwBe1LUFo5U1EEuU2gSTHnC31rhYiac9aC7mYhB3a/GgN10uS7yVbY3cUvIR9/GPYEDcxslC9CDY9iUBnDw3k8td+jFDY7ABSJ7eS6xpTat+ESi0gXYdFc5gdY/Df0z70GIIylkGc9ArMcyJiU7St8iXy0MY/q17Z0gXvg4Ayd1rtjQppWA9J6BNCKplkYtT4byZUW1gEHZsDdzbR0eZNwdqPs9HDaiC1ZNRmJf+oXEGMQ17K5Tc//Me4lGWqIrk+aeEJEjTz9WJOBJu0xnAWAArqlHzzrAKEbi9KJMmHatGdXfS6IPuuezYy5SQDfHWFYOvjMxfmcDdAyCDXMDBF268Aq3P859MZH+KzTtZkROlzMrrQvAoVW63LwrQxRZ7Gqt4KBYB5vi/pzTIdZ2Qdripd5QkKekYdkMgT/7tn/cxuIx/6Kd7xk/kOHlI05F3JnUOSq473w/BVPcIARUaeEaIQPyXRTl1ygrjc+M= 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:(136003)(346002)(396003)(366004)(39830400003)(376002)(110136005)(33656002)(66574015)(5660300002)(7696005)(83380400001)(186003)(122000001)(8936002)(508600001)(52536014)(38100700002)(316002)(71200400001)(2906002)(66556008)(86362001)(55016002)(8676002)(44832011)(64756008)(66476007)(66446008)(76116006)(66946007)(38070700005)(966005)(53546011)(4001150100001)(6506007)(9686003)(15398625002)(43620500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dTY5ZXorRnpwcE1vWlBOQ3liOXNzekYyTkcwNnNRVnVZYWRVM215ek4wdm5v?= =?utf-8?B?Z010R29VSWVTaGpaQnJ2cUwrM3VnSjlNaFdYQ0JVUE02OE40Sk4ySXBwSTY4?= =?utf-8?B?MjZuczRrMDlqdFp4KzFLWDgxSjRMY2RoNFRuTEJYcnR1QkRsUjdYQ0VSVFRU?= =?utf-8?B?bHc1aUgxQ0puWlRraDh0a1h5dnU5a2VwL29JK1loVzNkcitrbTkxL3pXVEhk?= =?utf-8?B?dG9QRUF0R2dPdVZoZ0dJdkFEbWpYbXZNY1A0Uy9JeXRPOU9yamVyRUhKYVdw?= =?utf-8?B?SWdyOXZjSS81WVYwMlhVRGpWRnR4M1lDVWVYYVU5aVhnY2V6R3p1ZWxsM08w?= =?utf-8?B?aEJrRktBbXVXL2lxYVBvQnVGSnpXMlFIKzlYZHVDSXYzeWdrQUlXYlNVdDBp?= =?utf-8?B?ZWJ3TUpFeEJyMC9WeDFtNG9USW1EOFByU2duR3pad1BuNVNmVy9PaWdpSnpt?= =?utf-8?B?RTgzcXpXTFIzeHgxZmtmWFNxSG1oUW9JNEtOOE52UTJUY1F2UUJrME02T3VJ?= =?utf-8?B?dlRtcFNvb2I3R2twY1NWeFErV3BEM1laTnQ4aUw3b2R5SDVIRGY3K2xIRjdh?= =?utf-8?B?VnRrUVpIbmIzWTk4YkQxNTFmczZHU3BPdWlSMmNhbUpEQ2RESzFnZjJGSTU1?= =?utf-8?B?VXgrNjVsR2RHV2J3dEs4QnQvM0Vpd212d1BFbFFpWTJRSS9rQ1RWZkVtazdW?= =?utf-8?B?dEdDaFpLQU9xN2lrMGZsR0pCM05JbVJUVUVpUGxpcCtaVmU0R0hUcjZRSVIw?= =?utf-8?B?NjQvRmJlaW9OVEdMTHpHTVh3dkJ4OUR4ay80Nmc3VXRvd2ozWmF1Wm5oSXBm?= =?utf-8?B?Y0hvRS82NzZ1RUdLTStRamE1bVZPdDIyVDFpVlBJTThpdTZFWjZFTkZycHkr?= =?utf-8?B?M0psemlsSUNrcWhIbnMzMDBvZ3FBeGtLdk5IZXdxdkJMYi9uendDaWx2UXcz?= =?utf-8?B?cldoNzIrNHd2N0ZqSWc0WXI4L2tseGtIcElFMnZtcDlFd2lHeEJzeklJZDV6?= =?utf-8?B?ai9WektVZ1lEcUdWUUxwRHptZXBYWnNGN055bUhzc3ZKYXhaeEk3Smt1SnBB?= =?utf-8?B?U1pDb255bS9RL2g1MXc5L2xscmJnZUpWdEJsZGkyUXQ4Zis4Z3lscm52VG51?= =?utf-8?B?a0JOQVdhM1d6d1cxUzBEOWREQVl0UitWN1ptWmNPbUlWak5KSGRxSjIwUG5C?= =?utf-8?B?WUFIU1dPZDdwalVxMHFlQ0lTOVUwMjBoT3RNVXhwUFpnOHN3TU9XTGtSdmJy?= =?utf-8?B?YnNCSzJ4RjNNSVd1Ukh5eXdHYmhlQTFjTEFGZ2dYZUl0R3N1UzJWNDRHa1dQ?= =?utf-8?B?emdmOW0zT3VXTk80MFNSSUFhdFphbmQ1TWFGWGVYa1RxYXNOZXhiVU1ndEgw?= =?utf-8?B?cFJ2TUxOWmhBU24wcWw0REl2NE5qSS8wOWxEK2t0Zm1QZHIxYU5IMEN6REUw?= =?utf-8?B?T0swTWZXS0RPczdTdTFUMVFFQTRINW12VExCc2FOdmJSZ0pmVzluTWpUNmRa?= =?utf-8?B?a091b09tYTZFRzNSWVRjQUpwaUNqbUdsNjZNZEQxODdTWGMwSmpvWlBCbUhS?= =?utf-8?B?dWpaNy9MTnpUSGxTWmY0SEwwamRGRjNsaENYUS9ocm5FSmJLZ0hUdjV1RzBU?= =?utf-8?B?SUQrL3c2dXkyUVp3NVE5Qk1RWnZjTmg2NEs0QUJBWTB1VHc0c0lXL2JoWXpn?= =?utf-8?B?S1IvUVA1dU8vcVEreXRNKy9BWlNUL1RzTlFVNEhmUWxabE9EZDc5bzFVOHR3?= =?utf-8?B?L0d0QXova3YwS09RUy85UEtOalNPS2JEajlBaHJEbUt0RlBieTdmM0xqL3hq?= =?utf-8?B?SFNtcU9sWUlYR1BObG8rVis2SmU0ZUxhUzhxSFBBWmpwWHAzaFdUZnZUL2V1?= =?utf-8?B?MllIV2E4TDdCUVFGS05OMm1KdmIwUDNzOXp4NFZPVFlFQ0NoL09OeHRrd1dE?= =?utf-8?B?ZEhLb3ZhQlpZNGtlSml3RnZMWStFam1vY2pEZTdvN0NBNkdaSXFQdHAycmo0?= =?utf-8?B?VWhRV2MzazZzZVNqSzJldGFIZys3OG80Mk9VMWU3TjRVZVZqV0h4Tyt1SzQz?= =?utf-8?B?aEpGb1Q5Y29RNzZmc0JMTkhJYTJjRFNUQnp3ZGVQZ2lOV2s3WFM5L2lZNWln?= =?utf-8?B?OE16ekVBK2VwYlU0UjN6djBwcmZNQ09zOUJmQ21Zam9sWENMRGgxQjNJNm9U?= =?utf-8?B?c3YzR0pYeWZab1ZNMmVFRkh5QlZ6bTY2VmZ0dnpXcWdZeTNtYzVsS29ENjFQ?= =?utf-8?B?a21aaGNnWHdnK2JOT042MVVNV2swRXVuSjNDNGRiMWRGc0JuMWdwdUhyS2h0?= =?utf-8?B?OTErZUtLblFkWERjS2Z3L0kzNStmL1RBUkZWRCt4eXlvcGFLQ21YQT09?= 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: f9312d17-e6b3-49c0-603f-08d9ada3228f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2021 10:30:41.9656 (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: 4M9SWaA1mB2ioqZyCbXLmCyssozccqp1nJqT6Yoeq3JtK99bCf7LekxdOR66gEXb4xd8wNbbuiQ9vcG9+HM5ytb/xqkJZEfh+a8zkIh83S4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1569 Archived-At: Subject: Re: [Iotops] Secure browsing local web resources 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, 22 Nov 2021 10:30:59 -0000 SGkgTmljaywNCg0KQWdyZWUgd2l0aCB0aGUgcHJvYmxlbSBhcyBzdGF0ZWQgaW4geW91ciBlbWFp bCBhbmQgc2xpZGVzLiAoVGhlIGxhdHRlciBleHBsb3JlIHNvbWUgaW50ZXJlc3Rpbmcgc29sdXRp b25zLikNCkEgc29sdXRpb24gaW4gSUVURiBzY29wZSBtYXkgYmUgc29tZSBjbGFzcyBvZiAiSW9U IiBzZXJ2ZXIgY2VydGlmaWNhdGUgdGhhdCBpcyB0cnVzdGVkIG9ubHkgaW4gbGluay1sb2NhbCBz Y29wZSwgYWxzbyBieSBicm93c2Vycy4gKFRydXN0ZWQgZW5vdWdoIHRvIGFsbG93IHRoZSB1c2Vy IHRvIHZpZXcgdGhlIHBhZ2UuKQ0KVGhpcyBjb3VsZCBiZSBhbiBJRGV2SUQtdHlwZSBjZXJ0aWZp Y2F0ZS4gDQoNCkZvciBlbmhhbmNlZCBzZWN1cml0eSB0aGUgYnJvd3NlciBjb3VsZCBldmVuIGJl IGluc3RydWN0ZWQgaW4gc29tZSB3YXkgKFFSIGNvZGU/IDQtbGV0dGVyIGNvZGU/KSB0byB0ZW1w b3JhcmlseSB0cnVzdCBhbGwgSURldklEIGNlcnRpZmljYXRlcyBmcm9tIHZlbmRvciBYIGZvciB0 aGUgZHVyYXRpb24gb2YgdGhlIGJyb3dzZXIgdGFiIGJlaW5nIG9wZW4uDQoNCnJlZ2FyZHMNCkVz a28NCg0KSW9UY29uc3VsdGFuY3kubmwgIHwgIEVtYWlsL1RlYW1zOiBlc2tvLmRpamtAaW90Y29u c3VsdGFuY3kubmwgDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSW90 b3BzIDxpb3RvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE5pY2sgQWxsb3R0DQpT ZW50OiBGcmlkYXksIE5vdmVtYmVyIDE5LCAyMDIxIDE1OjQ3DQpUbzogaW90b3BzQGlldGYub3Jn DQpTdWJqZWN0OiBbSW90b3BzXSBTZWN1cmUgYnJvd3NpbmcgbG9jYWwgd2ViIHJlc291cmNlcw0K DQpUaGFua3MgZm9yIHRoZSBvcHBvcnR1bml0eSB0byBwcmVzZW50IGxhc3Qgd2Vlay4gUGxlYXNl ZCBpdCBnZW5lcmF0ZWQgc29tZQ0KZGlzY3Vzc2lvbiEgWzFdLiBUaGUgc2xpZGVzIFsyXSBJIG5v dGUgbmVnbGVjdGVkIHRvIGluY2x1ZGUgdGhlIHJlZmVyZW5jZQ0KdG8gdGhlIENBL0Jyb3dlciBm b3J1bVszXSBndWlkZWxpbmVzICg3LjEuNC4yLjEpIHdoaWNoIGhlbHAgdW5kZXJzdGFuZCB0aGUN CnByb2JsZW0uDQoNCkFjY2Vzc2luZyBsb2NhbCB3ZWIgYmFzZSByZXNvdXJjZXMgbG9jYWxseSBh bmQgc2VjdXJlbHksIHdlIHRoaW5rIGlzIGFuDQppbXBvcnRhbnQgcHJvYmxlbSB0byBhZGRyZXNz LiBUaGUgSUVURiBjb21tdW5pdHkgaXMgYmV0dGVyIHBsYWNlZCB0aGFuDQptb3N0L2FsbCB0byBx dWFsaWZ5IGFuZCByZWZpbmUgdGhpcyByZXF1aXJlbWVudCBhbmQgaGVscCBkZXZlbG9wIGFuZA0K ZXZhbHVhdGUgdGhlIHBvdGVudGlhbCBzb2x1dGlvbnMuDQoNClRoZXNlIGFyZSB0aGUgYWN0aXZl IHF1ZXN0aW9ucyB3ZSBoYXZlLCB3aGljaCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZ2V0DQpjb25m aXJtZWQgKG9yIHJlZnV0ZWQpDQoNCjEuIFRoZXJlIGlzIGEgcHJvYmxlbTogdGhlcmUgaXMgYSBj bGVhcmx5IGRlZmluZWQgaXNzdWUuDQphKSBCb290c3RyYXBwaW5nIGEgVExTIGNvbm5lY3Rpb24g YmV0d2VlbiBhIGJyb3dzZXIgYW5kIGEgbG9jYWwgd2ViDQpyZXNvdXJjZSAoSU9UIG9yIG5vdCkg b24gbG9jYWwgaW50ZXJuZXQgKHJlc2VydmVkIElQIGFkZHJlc3MvUHJpdmF0ZSBVc2UpDQppcyBo YXJkIHRvIGRvDQpiKSBHaXZlbiAoYSkgc25pZmZpbmcgYWRtaW5pc3RyYXRpdmUgcGFzc3dvcmRz IGZvciBsb2NhbCByZXNvdXJjZSAoZS5nLg0KSU9UKSwgYW4gb3RoZXJ3aXNlIGludGVyY2VwdGlu ZyB0cmFmZmljIGlzIHJlbGF0aXZlbHkgZWFzeSB0byBkbyBhbmQNCnRoZXJlZm9yZSBhIHNlcmlv dXMgaW50ZXJuYWwgdGhyZWF0DQoNCjIuIEl0J3MgYSBwZXJ2YXNpdmUgcHJvYmxlbTogdGhlIHBy b2JsZW0gY3VycmVudGx5IG1hbmlmZXN0cyBpdHNlbGYgb24NCm1hbnkvbW9zdCBjb25zdW1lciBy b3V0ZXJzIGFuZCBtYW55L21vc3QgSU9UIGRldmljZXMgdGhhdCBjb25uZWN0IHZpYSBXaWZpDQph bmQvb3IgY2FibGVkIElQLg0KDQozLiBUaGVyZSBpcyBubyBrbm93biBiZXN0IHByYWN0aWNlIGZv ciBwcmFjdGljYWxseSBhbmQgc2VjdXJlbHkNCmF1dGhlbnRpY2F0aW5nIGxvY2FsIHdlYiBjbGll bnRzIGFnYWluc3QsIGxvY2FsIElQIGJhc2VkIElPVCBkZXZpY2VzDQoNCldlIHdvdWxkIGJlIGRl bGlnaHRlZCBpbiBldGhlciBvdXRjb21lOiBlaXRoZXIgYWdyZWVtZW50IGluIHRoZSBzdGF0ZW1l bnRzDQphYm92ZSwgb3IgYSBjbGVhciByZWZ1dGF0aW9uIG9mIGFueSBvZiB0aGUgaXNzdWVzLg0K DQpXZSBob3BlIHRvIHB1YmxpY2lzZSB0aGUgaW50ZXJuYWwgZG9jdW1lbnQgb3V0bGluaW5nIGEg cG90ZW50aWFsIHNvbHV0aW9uDQpzcGFjZSBuZXh0IHdlZWsuIFdlIGFyZSBqdXN0IGNsZWFuaW5n IHRoZSBkb2NzIGFuZCBtYWtpbmcgcmVhZHkgZm9yDQpjb21tZW50LiBJIHdpbGwgZm9sbG93IHVw IHdpdGggdGhlIGxpbmtzIGFzYXAsIHdoaWNoIGFzc3VtaW5nIHRoZXJlIGlzDQphZ3JlZW1lbnQg YW4gaXNzdWUgZXhpc3RzIC0gbWF5IGhlbHAgcGxhbnQgc29tZSBzZWVkcyBvbiBob3cgaXQgY2Fu IGJlDQphZGRyZXNzZWQNCg0KDQpCdXQgaW4gdGhlIGludGVyaW0sIHRoZXJlIGFyZSBmdXJ0aGVy IGNvbW1lbnRzL2Rpc2N1c3Npb24gdGhhdCBoZWxwDQpjYWxpYnJhdGUgdGhlIHByb2JsZW0sIHRo YXQgd291bGQgYmUgZ3JlYXQuDQoNCkFsc28gcmVtaW5kZXIsIHB1YmxpYyBmYWNpbmcgcGFwZXIg b24gdGhlIHByb2JsZW0gWzRdDQoNClsxXSBodHRwczovL2phYmJlci5pZXRmLm9yZy9qYWJiZXIv bG9ncy9pb3RvcHMvMjAyMS0xMS0xMi5odG1sDQpbMl0NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL3NsaWRlcy0xMTItaW90b3BzLXN1aWItYnJvd3NpbmctbG9jYWwtd2ViDQotcmVz b3VyY2VzLWluLWEtc2VjdXJlLXVzYWJsZS1tYW5uZXItaW90LWRldmljZS1jb25maWd1cmF0aW9u LWFzLWEtc3BlY2lhbA0KLWNhc2UvDQpbM10gaHR0cHM6Ly9jYWJmb3J1bS5vcmcvd3AtY29udGVu dC91cGxvYWRzL0NBLUJyb3dzZXItRm9ydW0tQlItMS44LjAucGRmDQpbNF0NCmh0dHBzOi8vbWFu eXNlY3VyZWQubmV0L3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDIxLzAzL01TLVNlY3VyZS1JbnRyYW5l dC1Ccm93DQpzZXItV0cucGRmDQoNCk5pY2sgQWxsb3R0DQpucXVpcmluZ21pbmRzDQoNCi0tIA0K SW90b3BzIG1haWxpbmcgbGlzdA0KSW90b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lvdG9wcw0K From nobody Mon Nov 22 06:13:14 2021 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 1982F3A0B9B for ; Mon, 22 Nov 2021 06:13:06 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.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 wmckFLiaW2ty for ; Mon, 22 Nov 2021 06:13:01 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 CF8523A0AEF for ; Mon, 22 Nov 2021 06:12:55 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id 8so16630847qtx.5 for ; Mon, 22 Nov 2021 06:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BybLCiCXupXmcpYzQPiAezFLCF9L0btXJ0urGkiCtYw=; b=U45shG/pA5yBpn7MIIo9o3nuPzvSmHVjj3des/GF9T8QBKPhmwy7eQYXjyufUTkcqF RmKnVlEA6DO3JapJqgSjHEcPa3IbeBzYRhv8CEKhYy/PPgBMDxUyJsw+cl3gNb2PTg9f jiWOz88G8rc/SNsSF3js62eTacWnzrzwBdcg2XJDtx3dDOQKRPvpLpfkEl6RCjuCGWd8 BJ/WuveglrqyNrdmEEEfmd2oz5htEK6cbTHRbQCYEJupnM9pQCF1vMMTPfhvIVKhx9qo wp5/qbmVylBJExdXBwHNO5HNYDdJCuJAN4uXWhtLwj9FGsHfer1amB7BI6AAGrYmiiWM GkUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BybLCiCXupXmcpYzQPiAezFLCF9L0btXJ0urGkiCtYw=; b=GDtNTacZK0iejJhGnJiwo4VXRNrHzKIdO9KCnryyPzoOHQXdGDakSTPyn+/37LuF8z D+Y5+NaxUEVn8hSQ20NO0amCLacdXqT/Gthw+DgfhsTY8tn7QDxqzJCsdSqeKO01q47x QCCyQNGpFFgtNmVFOhfNbFdH2qzpJBpIrw8ex50cJEwbbYVqe50V4QUBBb2STUfVnSI8 DatXicZ7MJQn/8wefTjQYSd+d7Hgipdo5NQUUERnsFl3Rj3xHfZgvMsSTKFLIH5TMCBs Ab8d2QelgtTPSmanCT9p0h8TBa9NoMkGLQlmq0LSKJLw4KsPzvX77U6mFv9vksPyXDYD NxPA== X-Gm-Message-State: AOAM533dkcNZmsyShhUanxtVVLKBzXK0PTOWubx2PMDLP7sSDRUfy+Y+ PirmY3Ee1m6it1Kn5bmTuZx31wgYKM4Fg5wjvB0CJAro6vw= X-Google-Smtp-Source: ABdhPJzmnY5jY7jO6RI56S0njFbnjlPbV4x4q2QSWHF64wCtHDHbVhi4/aovPZrRmR14qTjlu8eS7CxLLDgnZwAA1lE= X-Received: by 2002:ac8:5e0f:: with SMTP id h15mr31483283qtx.123.1637590373793; Mon, 22 Nov 2021 06:12:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ash Wilson Date: Mon, 22 Nov 2021 09:12:42 -0500 Message-ID: To: Esko Dijk Cc: Nick Allott , "iotops@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008494af05d161384e" Archived-At: Subject: Re: [Iotops] Secure browsing local web resources 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, 22 Nov 2021 14:13:12 -0000 --0000000000008494af05d161384e Content-Type: text/plain; charset="UTF-8" We had a brief discussion at IETF 110 in the DANISH BoF (which has evolved into the DANCE WG) about how DNS-SD/mDNS might work to tie link-local identities to DANE DNS records. This would give you the ability to have a universal server identifier/public key in DNS which the IoT TLS server could claim and prove to a client device. The downside here is that DANE is not currently browser-supported, though it is supported in various TLS libraries. On Mon, Nov 22, 2021 at 5:31 AM Esko Dijk wrote: > Hi Nick, > > Agree with the problem as stated in your email and slides. (The latter > explore some interesting solutions.) > A solution in IETF scope may be some class of "IoT" server certificate > that is trusted only in link-local scope, also by browsers. (Trusted enough > to allow the user to view the page.) > This could be an IDevID-type certificate. > > For enhanced security the browser could even be instructed in some way (QR > code? 4-letter code?) to temporarily trust all IDevID certificates from > vendor X for the duration of the browser tab being open. > > regards > Esko > > IoTconsultancy.nl | Email/Teams: esko.dijk@iotconsultancy.nl > > > > -----Original Message----- > From: Iotops On Behalf Of Nick Allott > Sent: Friday, November 19, 2021 15:47 > To: iotops@ietf.org > Subject: [Iotops] Secure browsing local web resources > > Thanks for the opportunity to present last week. Pleased it generated some > discussion! [1]. The slides [2] I note neglected to include the reference > to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the > problem. > > Accessing local web base resources locally and securely, we think is an > important problem to address. The IETF community is better placed than > most/all to qualify and refine this requirement and help develop and > evaluate the potential solutions. > > These are the active questions we have, which it would be useful to get > confirmed (or refuted) > > 1. There is a problem: there is a clearly defined issue. > a) Bootstrapping a TLS connection between a browser and a local web > resource (IOT or not) on local internet (reserved IP address/Private Use) > is hard to do > b) Given (a) sniffing administrative passwords for local resource (e.g. > IOT), an otherwise intercepting traffic is relatively easy to do and > therefore a serious internal threat > > 2. It's a pervasive problem: the problem currently manifests itself on > many/most consumer routers and many/most IOT devices that connect via Wifi > and/or cabled IP. > > 3. There is no known best practice for practically and securely > authenticating local web clients against, local IP based IOT devices > > We would be delighted in ether outcome: either agreement in the statements > above, or a clear refutation of any of the issues. > > We hope to publicise the internal document outlining a potential solution > space next week. We are just cleaning the docs and making ready for > comment. I will follow up with the links asap, which assuming there is > agreement an issue exists - may help plant some seeds on how it can be > addressed > > > But in the interim, there are further comments/discussion that help > calibrate the problem, that would be great. > > Also reminder, public facing paper on the problem [4] > > [1] https://jabber.ietf.org/jabber/logs/iotops/2021-11-12.html > [2] > https://datatracker.ietf.org/doc/slides-112-iotops-suib-browsing-local-web > -resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special > -case/ > > [3] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf > [4] > https://manysecured.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow > ser-WG.pdf > > > Nick Allott > nquiringminds > > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > -- *Ash Wilson * | Technical Director *e:* ash.wilson@valimail.com This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. --0000000000008494af05d161384e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We had a brief discussion at IETF 110 in the DANISH BoF (w= hich has evolved into the DANCE WG) about how DNS-SD/mDNS might work to tie= link-local identities to DANE DNS records. This would give you the ability= to have a universal server identifier/public key in DNS which the IoT TLS = server could claim and prove to a client device. The downside here is that = DANE is not currently browser-supported, though it is supported in various = TLS libraries.=C2=A0

On Mon, Nov 22, 2021 at 5:31 AM Esko Dijk <esko.dijk@iotconsultancy.nl>= wrote:
Hi Nick,=

Agree with the problem as stated in your email and slides. (The latter expl= ore some interesting solutions.)
A solution in IETF scope may be some class of "IoT" server certif= icate that is trusted only in link-local scope, also by browsers. (Trusted = enough to allow the user to view the page.)
This could be an IDevID-type certificate.

For enhanced security the browser could even be instructed in some way (QR = code? 4-letter code?) to temporarily trust all IDevID certificates from ven= dor X for the duration of the browser tab being open.

regards
Esko

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



-----Original Message-----
From: Iotops <iotops-bounces@ietf.org> On Behalf Of Nick Allott
Sent: Friday, November 19, 2021 15:47
To: iotops@ietf.org
Subject: [Iotops] Secure browsing local web resources

Thanks for the opportunity to present last week. Pleased it generated some<= br> discussion! [1]. The slides [2] I note neglected to include the reference to the CA/Brower forum[3] guidelines (7.1.4.2.1) which help understand the<= br> problem.

Accessing local web base resources locally and securely, we think is an
important problem to address. The IETF community is better placed than
most/all to qualify and refine this requirement and help develop and
evaluate the potential solutions.

These are the active questions we have, which it would be useful to get
confirmed (or refuted)

1. There is a problem: there is a clearly defined issue.
a) Bootstrapping a TLS connection between a browser and a local web
resource (IOT or not) on local internet (reserved IP address/Private Use) is hard to do
b) Given (a) sniffing administrative passwords for local resource (e.g.
IOT), an otherwise intercepting traffic is relatively easy to do and
therefore a serious internal threat

2. It's a pervasive problem: the problem currently manifests itself on<= br> many/most consumer routers and many/most IOT devices that connect via Wifi<= br> and/or cabled IP.

3. There is no known best practice for practically and securely
authenticating local web clients against, local IP based IOT devices

We would be delighted in ether outcome: either agreement in the statements<= br> above, or a clear refutation of any of the issues.

We hope to publicise the internal document outlining a potential solution space next week. We are just cleaning the docs and making ready for
comment. I will follow up with the links asap, which assuming there is
agreement an issue exists - may help plant some seeds on how it can be
addressed


But in the interim, there are further comments/discussion that help
calibrate the problem, that would be great.

Also reminder, public facing paper on the problem [4]

[1] https://jabber.ietf.org/jabber/logs/io= tops/2021-11-12.html
[2]
https://datatracker.i= etf.org/doc/slides-112-iotops-suib-browsing-local-web
-resources-in-a-secure-usable-manner-iot-device-configuration-as-a-special<= br> -case/
[3] https://cabforum.org/wp-con= tent/uploads/CA-Browser-Forum-BR-1.8.0.pdf
[4]
https://manysecu= red.net/wp-content/uploads/2021/03/MS-Secure-Intranet-Brow
ser-WG.pdf

Nick Allott
nquiringminds

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


--

Ash Wilson | Technical Director
e: <= a href=3D"mailto:ash.wilson@valimail.com" target=3D"_blank">ash.wilson@vali= mail.com

This email and all data transmitted with= it contains confidential and/or proprietary information intended solely fo= r the use of individual(s) authorized to receive it. If you are not an inte= nded and authorized recipient you are hereby notified of any use, disclosur= e, copying or distribution of the information included in this transmission= is prohibited and may be unlawful. Please immediately notify the sender by= replying to this email and then delete it from your system.<= /p>

--0000000000008494af05d161384e-- From nobody Mon Nov 22 07:15:07 2021 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 6BE6D3A0BFB for ; Mon, 22 Nov 2021 07:15:05 -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=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 37zG54VbwHsp for ; Mon, 22 Nov 2021 07:15:02 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 3948E3A0BFC for ; Mon, 22 Nov 2021 07:15:02 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id d5so33384171wrc.1 for ; Mon, 22 Nov 2021 07:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WqdFIpCLpoY/ZY74PeMGPo5YZlHACnNBJwWkoSVgVGk=; b=OhQY+laTAlnDg4Gv89PuyjbuJ2rbYn3Jx6aAlZmlAgkCmDojl6B+qI6+H8GP0UGxpN fDCQoy92ZKAWEUrJ37W2NZUwHr1Trtm6pbmtFCH7EPfae9j9WDwCyBKZFhq7SFJjX1Ro rbHHwLMrds9zlZsXyza7eeC8DqhVdqhxCbc32AgyUJ/nc0f1+VxCPVw2IAURCKRPJx8w yldpulGRKR7+LEpyh4OFbpMOW07ka06DF3G8Q16v1F5HB/eVcAjjxIfFnjv2wSTkz+Up 0CkYOHmrm6v1wqfcz1UkQ5SmpLGW6b8pu84QrXUpAMeO6nft2PERfETflN2sH3zV42/X PxVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WqdFIpCLpoY/ZY74PeMGPo5YZlHACnNBJwWkoSVgVGk=; b=Ilo6idqZ5yZpiJEP7EYwuT7U6s7xQQbVfJUHjv9Rl7ota5q8BVMIBlPgc1tEBbRNCH uAZtTnOZYsauUoJpD2tx9CkqLbcvjgAtT2riqjnqMzl/AoQUfFIcJ155BwFNfwLs/eXK FApq4lbYJZTZ8ka+Q56dF4Uc5kto887VsegBXUJ3PUkD9O7waCsqVf3f3sDZqNiZLBA2 LqB24rXoNW9LJyl8ZI+DE5X7aqd9vK5CpQnmhoHRTvYGQwAymLy7I5jlM7VJMWe00L/4 lBe7EBTVvi+WVp1PBFDa66/Hy3obpqmlchgwttHBgZsE0qROzHPbURHDBo7Mr2PVYXqs XuIA== X-Gm-Message-State: AOAM533bGCjQtOwcHZpZuInQZltOPIza6vCx/ynXIbdxno2sjq1AldHY T7f+9DpOJ8kdR/uEYv1q9CI63aTxAIjFCkLLRrbDXRap X-Google-Smtp-Source: ABdhPJzB36YQRfWQGHtEfyQFY2yKnm258rW7ShQyQtbmsVKORO+nbe+FtgPFWZnYfW9QMt9v7bCZfaGjB9tGO9zrp+4= X-Received: by 2002:a5d:550f:: with SMTP id b15mr36973705wrv.212.1637594097026; Mon, 22 Nov 2021 07:14:57 -0800 (PST) MIME-Version: 1.0 References: <163759345909.25982.6148538891904763496@ietfa.amsl.com> In-Reply-To: <163759345909.25982.6148538891904763496@ietfa.amsl.com> From: =?UTF-8?Q?S=C3=A1vyo_Morais?= Date: Mon, 22 Nov 2021 12:14:45 -0300 Message-ID: To: iotops@ietf.org Content-Type: multipart/alternative; boundary="000000000000708c4305d1621651" Archived-At: Subject: [Iotops] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt 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, 22 Nov 2021 15:15:05 -0000 --000000000000708c4305d1621651 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello guys, This is a draft we are proposing to append a security functionality to MUD (RFC 8520) with a vulnerability management system for IoT networks with a short security experts team. Hope you will appreciate this, and please let us know about any suggestions, comments or corrections in the document. -- Best Regards, S=C3=A1vyo Morais. ---------- Forwarded message --------- De: Date: seg., 22 de nov. de 2021 =C3=A0s 12:04 Subject: New Version Notification for draft-morais-iotops-inxu-00.txt To: S=C3=A1vyo Vin=C3=ADcius de Morais , Claudio Miceli = de Farias < cmicelifarias@gmail.com> A new version of I-D, draft-morais-iotops-inxu-00.txt has been successfully submitted by S=C3=A1vyo Vin=C3=ADcius de Morais and p= osted to the IETF repository. Name: draft-morais-iotops-inxu Revision: 00 Title: Intra-Network eXposure analyzer Utility Specification Document date: 2021-11-22 Group: Individual Submission Pages: 39 URL: https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.txt Status: https://datatracker.ietf.org/doc/draft-morais-iotops-inxu/ Html: https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-morais-iotops-inxu Abstract: This document proposes the Intra-Network eXposure analyzer Utility (INXU) as a vulnerability management solution for IoT networks. The goal of INXU is to extend the functions of the RFC 8520 and support a Security Experts Team on protecting multiple heterogeneous IoT networks, even when there is a few or none private information of the networks. INXU identifies and analyzes the capability of an IoT device being exploited by an well known malicious activity. We also propose the Malicious Traffic Description (MTD), a data-model to describe traffic related to malicious activities. The IETF Secretariat --000000000000708c4305d1621651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello guys,

This is a draft we are prop= osing to append a security functionality to MUD (RFC 8520) with a vulnerabi= lity management system for IoT networks with=C2=A0a short security experts = team.
Hope you will appreciate this, and please let us know about= any suggestions, comments or corrections in the document.

--
Best=C2=A0Regards,
S=C3=A1vyo Morais.
--------= -- Forwarded message ---------
De: <internet-drafts@ietf.org>
Da= te: seg., 22 de nov. de 2021 =C3=A0s 12:04
Subject: New Version Notifica= tion for draft-morais-iotops-inxu-00.txt
To: S=C3=A1vyo Vin=C3=ADcius de= Morais <savyovm@gmail.com>,= Claudio Miceli de Farias <cm= icelifarias@gmail.com>



A new version of I-D, draft-morais-iotops-inxu-00.txt
has been successfully submitted by S=C3=A1vyo Vin=C3=ADcius de Morais and p= osted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-morais-iotops-inxu
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Intra-Network eXposure analyzer Ut= ility Specification
Document date:=C2=A0 2021-11-22
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 39
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-morais-iotops-inxu/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.htm= l
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/html/draft-morais-iotops-inxu


Abstract:
=C2=A0 =C2=A0This document proposes the Intra-Network eXposure analyzer Uti= lity
=C2=A0 =C2=A0(INXU) as a vulnerability management solution for IoT networks= .=C2=A0 The
=C2=A0 =C2=A0goal of INXU is to extend the functions of the RFC 8520 and su= pport a
=C2=A0 =C2=A0Security Experts Team on protecting multiple heterogeneous IoT=
=C2=A0 =C2=A0networks, even when there is a few or none private information= of the
=C2=A0 =C2=A0networks.

=C2=A0 =C2=A0INXU identifies and analyzes the capability of an IoT device b= eing
=C2=A0 =C2=A0exploited by an well known malicious activity.=C2=A0 We also p= ropose the
=C2=A0 =C2=A0Malicious Traffic Description (MTD), a data-model to describe = traffic
=C2=A0 =C2=A0related to malicious activities.




The IETF Secretariat


--000000000000708c4305d1621651-- From nobody Tue Nov 23 01:43:15 2021 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 A64003A05E2; Tue, 23 Nov 2021 01:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 FL8ibQGIvcs4; Tue, 23 Nov 2021 01:43:08 -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 E52153A05AA; Tue, 23 Nov 2021 01:43:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DEEEB1806E; Tue, 23 Nov 2021 04:45:50 -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 JThDbQmFKBje; Tue, 23 Nov 2021 04:45:45 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF99A18016; Tue, 23 Nov 2021 04:45:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1637660744; bh=NMJPq0g+fphs2xGjICkN6QctT2sjyvq1O8sH69kY/VU=; h=To:Subject:In-reply-to:References:From:cc:Date:From; b=YNPYuRzCaHJP14FDGIIT0pud92l0cE1p7m6UEDfv3HbExBaC2EJvwGUx8F1kw7fN9 duYIssEFGO67tIInNobSCN8OC3rwObT3l76GW2fEB127CvK9pk3WPqSbC/jHA5q7iB jUk3hP/zJJyKL1kHEtp1skpBLQGnLk3B4xe4p4i8P0h9cb3usfraHFHFjXYTIZNVpt CMzxUDhgixZDj7JsJe0pGDgCu/FxuVoFhCVVptc0oUEKDaYp5aYxQO8fYqvQRfWGf5 VLefzPjMkBlsaeqIP6dLfGfdJYUPHpDOCLeIENJK6QIatd5UZvsHN6Q83KNQZOnFnM 5PHbPSqZIGIvw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 979E9128B; Tue, 23 Nov 2021 04:42:57 -0500 (EST) To: =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FS=3DC3=3DA1vyo=5FMorais=3F=3D?= , iotops@ietf.org, mud@ietf.org In-reply-to: References: <163759345909.25982.6148538891904763496@ietfa.amsl.com> Comments: In-reply-to =?us-ascii?Q?=3D=3FUTF-8=3FQ=3FS=3DC3=3DA1vyo=5FMora?= =?us-ascii?Q?is=3F=3D?= message dated "Mon, 22 Nov 2021 12:14:45 -0300." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 From: Michael Richardson cc: iot-wg@ripe.net X-Attribution: mcr 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] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt 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, 23 Nov 2021 09:43:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you for your interesting draft. I've CC'ed mud@ietf.org as well. {My first dyslexia induced thought is that INXU is close to NIXU, which some of us know as former Int-Area AD Pekka Nikkander's company... } There is some overlap here with DOTS. I'm not an expert on DOTS, so I can't say exactly, but I'm sure that the whole ISP talks to CPE model is in there. DOTS is more about offloading t= he traffic from the CPE device to the ISP... but according to what criteria, a= nd this is where the MTD might help. Minor: There are some terms that you've used which might be translations which are uncommon in english: "short team" and also "TCP connection starter" I think you mean "small team", but I'm uncertain if there is a more subtle meaning. I think that "TCP connection starter" probably means "TCP initiator" (the end that sends the TCP SYN). I really like your draft. From what I can tell, your MTD isn't an extension to MUD, but rather an parallel object which looks very much like a MUD file, but is provided by an ISP or security team to a CPE to help it deal with an active attack. I wrote a document, https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/ that w= as about how a compromised device went back into order. It turned into a RIPE presentation at the IoT WG: I hoping that some of the ISPs would tell me wh= at they are doing for communication among themselves. http://www.sandelman.ca/SSW/talks/ripe-iot-unquarantine2019/ ROLIE, SCAPv2, TAXI, STIIX were mentioned from some of the government/enterprise people, but apparently nobody was doing any of that a= s yet. Your work seems to overlap a bit with some of these. In the above deck, there is an auxiliar slide 51, where you see a "swifter = API" which is essentially your MTD and MTD server. The SHG project (now defunct= , alas) never implemented that part. S=C3=A1vyo Morais wrote: > This is a draft we are proposing to append a security functionality to > MUD (RFC 8520) with a vulnerability management system for IoT networks > with a short security experts team. Hope you will appreciate this, a= nd > please let us know about any suggestions, comments or corrections in > the document. > https://www.ietf.org/archive/id/draft-morais-iotops-inxu-00.html > Abstract: This document proposes the Intra-Network eXposure analyzer > Utility (INXU) as a vulnerability management solution for IoT network= s. > The goal of INXU is to extend the functions of the RFC 8520 and suppo= rt > a Security Experts Team on protecting multiple heterogeneous IoT > networks, even when there is a few or none private information of the > networks. > INXU identifies and analyzes the capability of an IoT device being > exploited by an well known malicious activity. We also propose the > Malicious Traffic Description (MTD), a data-model to describe traffic > related to malicious activities. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmGct6EACgkQgItw+93Q 3WV+4QgAuxf0j1XhuB/Qfy6LuoUAI86QRqox+BlFysdiUfWM3FOKUHo32iMNk4AB Srlfk6/FL9F3+7BW578YZRAGuIAHS9m/aB1LXrfLaRPXt214a7cgbYHXtwhYCvLM QwthPL/C7VcEv4QuWaMsIFjZPkZRP4ef/lF/4NJ7oIiBDMOvYrrxLSmYpbrl6b3R 1Fm5hD+OtKnQgKnHeTduamseRdsFGhwmluPD9SWbsnFjlPEVCDx8JX7y2qpRfaV1 4bdSeu7nLGVch4aXUJDS6i2Ah/ZqF9sJ1etYPNJb3KAj8xZZXzCe5G06RxAFlceE Q3IKiaD6yv0wKF9Ch12Vf5eT9O75fg== =ip9D -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 23 06:22:57 2021 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 AF26A3A0855; Tue, 23 Nov 2021 06:22:53 -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 MlAnMcq1q-ub; Tue, 23 Nov 2021 06:22:49 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 B9F9F3A0851; Tue, 23 Nov 2021 06:22:48 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id n33-20020a05600c502100b0032fb900951eso2410956wmr.4; Tue, 23 Nov 2021 06:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/qG++dPF6/cNCcYM1BGKnJk0oYPXbSr4WGd30YwypR8=; b=MAoUBUYn7WymcJaoVSzzypcpI3Zehx0yXJg1U/+gWGORe1oXJZO0eEmERD30OvzMTh LVrlqd8oCHJp8gR8dO6EZjN7yjV7f94/ksWP4H0Cw7WW9NpUzMCYn7DxKjrS99oTDfii UnCgLNWQKCVAjnEGXJsI3Qmd7Wt3JREw4u76b7ZsRdbhT2z/ibaDlSfgAcUFw1+a/+ds gZ77VFS2g9I673LQuqpsVzxJh33FbJa0hdTMTfL1pOP/j4/4h2v8oZ2RDbI6lgH6U2kZ XMwVOA1MpWK5NvZLA4/922eZk5VXjXfy4+SZnEUEfXCifAfCxHRhzFoC6wgjsl3w9UUA Sngw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/qG++dPF6/cNCcYM1BGKnJk0oYPXbSr4WGd30YwypR8=; b=h/D3evpz8s9SO2/7JHHuedDONwpgjsDMVeOJPTmTRIIyVf8p5JpQr7CsK3AkEaBki/ O71IEsU5C7DGw7uUamAx59BhYs6jKMKbOTUag4nFmcRQs1VYNjSF1nuGssPYFBsHV6Ly Um/6/y7oYDKNBTvWikHnohJALuy0xDCoWAInp4+YDHeRxquMGnYQRnIBmz4Hg99mkH7P aoInulwln6eeS3YKCPz+ffThA9T3S00f6JZZyYSDVMbH4owzB6GdrLvxBF5mlqYE5iNE 1WOFc1NRGu/8RMxKpjOMk2aiqwMIvsWjS/NZ78l7tUg8fMHz7aATDjnw1GN+xQySDj4m V3pA== X-Gm-Message-State: AOAM533FLl3DsoAuFBCBsmLYp7h/4rELYwXzTFWS60KEzMcdXKYgGM8m B5p91vsKY7YxdosdLLnWT80UNQ0bMfl0WbVkBGg= X-Google-Smtp-Source: ABdhPJw+S08/tmKX3Q4OA+z4xeN9MT9Zh/ouyXUCpqHqCszQp+wZ9lgNeVC22pi7LL6QGRk5Br2H5vgrdKDLbD0c09s= X-Received: by 2002:a05:600c:3541:: with SMTP id i1mr3850223wmq.124.1637677365948; Tue, 23 Nov 2021 06:22:45 -0800 (PST) MIME-Version: 1.0 References: <163759345909.25982.6148538891904763496@ietfa.amsl.com> <11174.1637660577@localhost> In-Reply-To: <11174.1637660577@localhost> From: =?UTF-8?Q?S=C3=A1vyo_Morais?= Date: Tue, 23 Nov 2021 11:22:34 -0300 Message-ID: To: Michael Richardson Cc: iotops@ietf.org, mud@ietf.org, iot-wg@ripe.net Content-Type: multipart/alternative; boundary="000000000000a7786b05d175798b" Archived-At: Subject: Re: [Iotops] Fwd: New Version Notification for draft-morais-iotops-inxu-00.txt 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, 23 Nov 2021 14:22:54 -0000 --000000000000a7786b05d175798b Content-Type: text/plain; charset="UTF-8" Hi Michael, thanks for your helpful comments. Please find some notes inline below: > {My first dyslexia induced thought is that INXU is close to NIXU, which some > of us know as former Int-Area AD Pekka Nikkander's company... } This was not planned hahahaha, but it can be changed in future draft updates. A Fun fact about INXU name is that it makes reference to a wasp that is common in my region. > > There is some overlap here with DOTS. > I'm not an expert on DOTS, so I can't say exactly, but I'm sure that the > whole ISP talks to CPE model is in there. DOTS is more about offloading the > traffic from the CPE device to the ISP... but according to what criteria, and > this is where the MTD might help. I would say they are complementary from what I could see in the DOTS Requirements (RFC 8612), INXU is more about managing the risks around well known vulnerabilities, covering manufacturer's lack of bug fixes, and supporting the devices life after its end-of-life. It also fights DDoS, but more by breaking the botnet's gears than by blocking the outgoing DDoS traffic. Maybe in this case I could change the Simple Example section. > Minor: > There are some terms that you've used which might be translations which are > uncommon in english: "short team" and also "TCP connection starter" > I think you mean "small team", but I'm uncertain if there is a more subtle > meaning. > I think that "TCP connection starter" probably means "TCP initiator" > (the end that sends the TCP SYN). A native speaker suggestion always helps :D I will update both in the text. > I really like your draft. From what I can tell, your MTD isn't an extension > to MUD, but rather an parallel object which looks very much like a MUD file, > but is provided by an ISP or security team to a CPE to help it deal with an > active attack. Agree with you in the point of extension/parallel, I just did not find a good way to say that as you did. Gotta update it. Regarding the second point, I just need to stress that INXU does not include the intrusion detection element, it just looks at the network and says "okay, someone can exploit this, so please prevent bad things from happening". > I wrote a document, > https://datatracker.ietf.org/doc/draft-richardson-shg-un-quarantine/ that was > about how a compromised device went back into order. I can see INXU supporting a kind of partial quarantine in this context. Also maybe the state update from device-of-interest to suspect. > It turned into a RIPE > presentation at the IoT WG: I hoping that some of the ISPs would tell me what > they are doing for communication among themselves. And how was their feedback? I can also try to do something similar in LACNIC/LACNOG. > ROLIE, SCAPv2, TAXI, STIIX were mentioned from some of the > government/enterprise people, but apparently nobody was doing any of that as yet. I'll take a look at this, but I guess nobody implemented it due to potential usability implications. At least this is my main concern on improving INXU to avoid getting stuck at home because someone can scan my door lock. > > In the above deck, there is an auxiliar slide 51, where you see a "swifter API" > which is essentially your MTD and MTD server. The SHG project (now defunct, alas) > never implemented that part. I have implemented an INXU Module (the module analyzes threats) prototype, maybe it can be helpful just in case SHG rises from the ashes like a phoenix. It is just a draft code running the core of the threat analysis, but we can go further and implement it into the OpenWRT. --000000000000a7786b05d175798b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael, thanks for your helpful comments.
Please fi= nd some notes inline below:

> {My first dyslexia induced thought = is that INXU is close to NIXU, which some
> of us know as former Int-= Area AD Pekka Nikkander's company... }


This was not planned = hahahaha, but it can be changed in future draft updates.
A Fun fact abou= t INXU name is that it makes reference to a wasp that is common in my regio= n.
=C2=A0
>
> There is some overlap here with DOTS.
> = I'm not an expert on DOTS, so I can't say exactly, but I'm sure= that the
> whole ISP talks to CPE model is in there. =C2=A0 DOTS is = more about offloading the
> traffic from the CPE device to the ISP...= but according to what criteria, and
> this is where the MTD might he= lp.


I would say they are complementary from what I could see in = the DOTS Requirements (RFC 8612),

INXU is more about managing the ri= sks around well known vulnerabilities,
covering manufacturer's lack = of bug fixes, and supporting the devices life after its end-of-life.
It also fights DDoS, but more by breaking the botnet's gears than by b= locking the outgoing DDoS traffic.
Maybe in this case I could change the= Simple Example section.

> Minor:
> There are some terms th= at you've used which might be translations which are
> uncommon i= n english: "short team" and also "TCP connection starter&quo= t;
> I think you mean "small team", but I'm uncertain i= f there is a more subtle
> meaning.
> I think that "TCP co= nnection starter" probably means "TCP initiator"
> (th= e end that sends the TCP SYN).

A native speaker suggestion always he= lps :D
I will update both in the text.

> I really like your dr= aft.=C2=A0 From what I can tell, your MTD isn't an extension
> to= MUD, but rather an parallel object which looks very much like a MUD file,<= br>> but is provided by an ISP or security team to a CPE to help it deal= with an
> active attack.

Agree with you in the point of exten= sion/parallel, I just did not find a good way to say that as you did.
G= otta update it.

Regarding the second point, I just need = to stress that INXU does not include the intrusion detection element,
=
it just looks at the network and says "okay, someone can exploit = this, so please prevent bad things from happening".

>= I wrote a document,
> https://datatracker.ietf.org/doc/draft-r= ichardson-shg-un-quarantine/ that was
> about how a compromised d= evice went back into order.


I can see INXU supporting a kind of = partial quarantine in this context.
Also maybe the state update from dev= ice-of-interest to suspect.
=C2=A0
> It turned into a RIPE
>= presentation at the IoT WG: I hoping that some of the ISPs would tell me w= hat
> they are doing for communication among themselves.


A= nd how was their feedback?
I can also try to do something similar in LAC= NIC/LACNOG.

> ROLIE, SCAPv2, TAXI, STIIX were mentioned from some= of the
> government/enterprise people, but apparently nobody was doi= ng any of that as yet.


I'll take a look at this, but I guess= nobody implemented it due to potential usability implications.

At l= east this is my main concern on improving INXU to avoid getting stuck at ho= me
because someone can scan my door lock.
=C2=A0
>
> In t= he above deck, there is an auxiliar slide 51, where you see a "swifter= API"
> which is essentially your MTD and MTD server.=C2=A0 The = SHG project (now defunct, alas)
> never implemented that part.

I have implemented an INXU Module (the module analyzes threats) protot= ype,
maybe it can be helpful just in case SHG rises from the ashes like = a phoenix.

It is just a draft code running the core of the threat an= alysis,
but we can go further and implement it into the OpenWRT.
--000000000000a7786b05d175798b--