Return-Path: X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D386A1200E5; Tue, 21 Jan 2020 05:50:21 -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, HTML_MESSAGE=0.001, 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 wuRz9n494h9d; Tue, 21 Jan 2020 05:50:17 -0800 (PST) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 09A1C120090; Tue, 21 Jan 2020 05:50:17 -0800 (PST) Received: from [192.168.2.1] ([IPv6:2601:184:407f:80ce:349f:2df:2bdc:d2ac]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 00LDnmpP004758 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Jan 2020 05:49:50 -0800 From: "David R. Oran" To: "Eliot Lear" Cc: "Mohit Sethi M" , "Lars Eggert" , "=?utf-8?b?0JLQsNGB0LjQu9C40Lkg0JTQvtC70LzQsNGC0L7Qsg==?=" , lwip@ietf.org, t2trg@irtf.org Date: Tue, 21 Jan 2020 08:49:42 -0500 X-Mailer: MailMate (1.13.1r5676) Message-ID: In-Reply-To: <37818CA3-93F3-43BC-A9F5-3CCAEC4C99A7@cisco.com> References: <6CB4D459-4AAA-4313-B95C-05DF22C9A9DD@eggert.org> <6B9FFEF5-CDC9-4703-BB10-616DBEDE80AB@gmail.com> <4528ED27-E3B6-43C4-99A5-715DE1B79A09@cisco.com> <247FD52A-D90D-498E-AD79-9DADA8653EB2@eggert.org> <08fa9838-bfa3-2b91-c7ba-9631a73da264@ericsson.com> <37818CA3-93F3-43BC-A9F5-3CCAEC4C99A7@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_C2772D24-9ED1-4D90-9D4C-2533A4D4D5FF_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Lwip] [T2TRG] QUIC on IoT boards X-BeenThere: lwip@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 13:50:22 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_C2772D24-9ED1-4D90-9D4C-2533A4D4D5FF_= Content-Type: multipart/alternative; boundary="=_MailMate_68F1A3FA-CE43-4081-9444-1547AB3A7D11_=" --=_MailMate_68F1A3FA-CE43-4081-9444-1547AB3A7D11_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 21 Jan 2020, at 5:24, Eliot Lear wrote: > Hi Mohit > >> On 21 Jan 2020, at 11:07, Mohit Sethi M w= rote: >> >> Hi Eliot, >> >> I find your example rather disturbing. I am sure a dad does not want e= veryone else on the Internet to see what his daughters toy is exfiltratin= g. You would need encryption for that? >> > > Yes, you would! But Dad might want to be able to have an agent to decr= ypt. Sure, which is why key sharing is probably appropriate and having standar= ds for doing that safely are important. Do we have a good way to maintain= PFS in those scenarios? > Indeed Dad may want an agent that blocks certain I can see two related reasons why this might be important: 1. To prevent =E2=80=9Cpacket of death=E2=80=9D scenarios where either bu= gs or malware can be exploited by a single crafted packet making it throu= gh to a vulnerable device. 2. To mitigate DoS attacks against devices that are not prepared to disca= rd traffic effectively, either due to processing or energy considerations= =2E #1 is quite difficult to achieve without full middle-box functionality, i= n which case I=E2=80=99d argue that rather than ACL-like blockage based o= n things like ports, you want a full application proxy that acts as an =E2= =80=9Cagent=E2=80=9D fronting the device. In this case the intermediary i= s trusted and already should have the necessary keys. #2 could be done with ACLs based on information in things like MUD profil= es, but I=E2=80=99d argue a better approach is something similar to STUN,= but whose purpose is for the device to install filtering or rate-limitin= g state in a cooperating device =E2=80=9Cupstream of it=E2=80=9D. My 2=C2=A2, FWIW=E2=80=A6 > >> >> I am totally with you on the need for knowing what's inside the device= and how is the device behaving. RFC 8576 identifies this in Section 5.6 = 'Verifying Device Behavior':https://tools.ietf.org/html/rfc8576#section-5= =2E6 > > Well indeed. But I do think we should be considering what the first cl= ass objects are in these cases. > > Eliot DaveO --=_MailMate_68F1A3FA-CE43-4081-9444-1547AB3A7D11_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On 21 Jan 2020, at 5:24, Eliot Lear wrote:

H= i Mohit

On 21 Jan 2= 020, at 11:07, Mohit Sethi M <mohit.m.sethi@ericsson.com> wrote:
Hi Eliot,

I find your example rather disturbing. I am sure a dad does not want ever= yone else on the Internet to see what his daughters toy is exfiltrating. = You would need encryption for that?

Yes, you would! But Dad might want to be ab= le to have an agent to decrypt.

Sure, which is why key sharing is probably appropriate an= d having standards for doing that safely are important. Do we have a good= way to maintain PFS in those scenarios?

I= ndeed Dad may want an agent that blocks certain

I can see two related reasons why this might be important= :

  1. To prevent =E2=80=9Cpacket of death=E2=80= =9D scenarios where either bugs or malware can be exploited by a single c= rafted packet making it through to a vulnerable device.

  2. To mitigate DoS attacks against devices t= hat are not prepared to discard traffic effectively, either due to proces= sing or energy considerations.

1 is quite difficult to achieve without ful= l middle-box functionality, in which case I=E2=80=99d argue that rather t= han ACL-like blockage based on things like ports, you want a full applica= tion proxy that acts as an =E2=80=9Cagent=E2=80=9D fronting the device. I= n this case the intermediary is trusted and already should have the neces= sary keys.

2 could be done with ACLs based on informat= ion in things like MUD profiles, but I=E2=80=99d argue a better approach = is something similar to STUN, but whose purpose is for the device to inst= all filtering or rate-limiting state in a cooperating device =E2=80=9Cups= tream of it=E2=80=9D.

My 2=C2=A2, FWIW=E2=80=A6

I am totally with you on the= need for knowing what's inside the device and how is the device behaving= =2E RFC 8576 identifies this in Section 5.6 'Verifying Device Behavior':<= a href=3D"https://tools.ietf.org/html/rfc8576#section-5.6" style=3D"color= :#999">https://tools.ietf.org/html/rfc8576#section-5.6 <ht= tps://tools.ietf.org/html/rfc8576#section-5.6>

Well indeed. But I do think we should be co= nsidering what the first class objects are in these cases.

Eliot

DaveO

--=_MailMate_68F1A3FA-CE43-4081-9444-1547AB3A7D11_=-- --=_MailMate_C2772D24-9ED1-4D90-9D4C-2533A4D4D5FF_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJJBAEBAgAzFiEEroJBCc9z/EJK1xs/eu0uvThCv/AFAl4nAXYVHGRhdmVvcmFu QG9yYW5kb20ubmV0AAoJEHrtLr04Qr/wCacP/iQzW1x/ezvb4N7MS7lKbMhSSbY9 b16Jy894AxLr5vcbRVRsOHWJM5C3dVlObesqusSusknN4lz4a5J9NoNATtgUTfG2 ++Ur9pXVwen5WSY8dDc007CNFyDMdzcLfZgk/zhvg8b+JxMjrKw8OpygP7HmOdu1 7Q8QdsJt/AZSmyiA8fjzsjc8uYQ8DMUIIJ2dNCO4AbjbqPyU6SaGG6r+s60tikCd hqnP7gX7r0sCyUX5DwviiLqxeckgQBQJMScjVhn+7IFDpbZuAnp4Rk0Vwoky6xfd P8pbt/SB2/CDNeLf/4CCKxqUlL1mZ9VPsNG+LuTM2Py/u9m4hFCRFk1WKrY54t+W KXiMTCGmagaj472iGqd4CsSQZbivqp1ajsH1QAAnawp8s54pryVh0PHHQMgSl1WI itEFfXzNFKum2mypaIM5rwQJgKRvLYou+nXr0FSrkhM/+6i2ZMbGh6GtyLPYA6H4 raedTk7FL/gd3sR5qGRXJXeI9Isyr/zsDwHQHGYboN3iFxG2uNBnNMkYTAkkZVYJ 4f+ovYJVfwfeukX0c/AFBDvK/eVKsEcF68Zc0v2FySPWFdDWbqMeCtkUCqFCagay f8ZQbt6rs71AuW5FWbdtCNdPFth6vQkz4eG+lbiftHhBHSrtRhR6YMxpIB4ZPJhd YIny6AF/5NT/DK6m =UJwr -----END PGP SIGNATURE----- --=_MailMate_C2772D24-9ED1-4D90-9D4C-2533A4D4D5FF_=--