From nobody Mon Apr 11 08:45:53 2022 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721FC3A112A; Mon, 11 Apr 2022 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Oqveamdw; dkim=pass (1024-bit key) header.d=yitter.info header.b=ci2nyVW1 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 DhOnGaKn_Bzu; Mon, 11 Apr 2022 08:45:47 -0700 (PDT) Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D372E3A1122; Mon, 11 Apr 2022 08:45:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 92958BD5C5; Mon, 11 Apr 2022 15:45:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691943; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=Oqveamdw7YqK0rpwlZWh7uZKQNGq+/DMZq41UANRw/1j8jnyxVugvSzPOucssuTSK 86rcxVL/Cew2dLX/gCszBe3Dqgo1/mKNes9lD9bu4OwgTCo9Sgq9Ua4l04luV2wzFx yl2qowdAiS0c2j0YlQt9dw7q89T/voesUAX4rxww= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4uScjukLMiG; Mon, 11 Apr 2022 15:45:41 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1649691941; bh=Nh43tYT1UxS2UWkzutCDJJRkJ6h0P2/en/DUkunrLuM=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=ci2nyVW1Q9H79yuZV1pDNZotPInsXt9L3SpOOICFz0PDgaNcax8erlSH5nSgPmEsA N0ZMn69OdrFvaUCQgaLHSzhYaKa1K3UD3m5dsV+Lbg41iYKOMlPrvMuUixE37cX0gX MMU+5wukJPkHqiv4S2UNq/L92QgE9v8U/zhwgbYg= Content-Transfer-Encoding: 7bit From: Andrew Sullivan Mime-Version: 1.0 (1.0) Date: Mon, 11 Apr 2022 11:45:39 -0400 Message-Id: <92E310C3-B9FA-4C8D-AB9A-06E069086BE2@anvilwalrusden.com> References: <24231.1649691469@localhost> Cc: dnsop@ietf.org, mud@ietf.org In-Reply-To: <24231.1649691469@localhost> To: Michael Richardson Archived-At: Subject: Re: [DNSOP] looking for reference for reverse maps do not work X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2022 15:45:52 -0000 --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in https://datatracker.ietf.org/doc/draft-= ietf-dnsop-reverse-mapping-considerations/, and got so many contradictory ed= its (see the history) that the final version ended up saying =E2=80=9CA or m= aybe not-A, or maybe both, your choice,=E2=80=9D so the then-chairs decided t= he document wasn=E2=80=99t worth sending through publication.=20 A =E2=80=94=20 Andrew Sullivan=20 Please excuse my clumbsy thums > On Apr 11, 2022, at 11:38, Michael Richardson wrot= e: >=20 > =EF=BB=BF > Hi, in reviews of > https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerati= ons-04.html >=20 > I was asked to expand upon why the reverse map can not be intelligently us= ed =20 > for MUD ACLs. (section 3, XXX stuff) > (MUD controllers, upon being presented with ACLs made up of > names need to do forward lookups of the names and build ACLs based upon th= e > IP addresses.) >=20 > There are two aspects of this: > 1) even in an ideal situation, it takes too long on the first packet to > extract a name from an IP address. Yes, that could be aggresively cac= hed. >=20 > 2) forward:reverse maps are N:M mappings, often with unidirectional parts= , and often > broken or not delegated. >=20 > Further, there is no authorization of the mappings, so an attacker who= > wants to be able to reach IP address 2001:db8::abcd, can insert a > reverse name of their choice, including updates.example.com, which is > permitted by the MUD ACL. >=20 > While I can write the above paragraph, I don't feel that it's detailed eno= ugh > for what is needed, and I feel that we (the IETF) must have documented the= > security issues with reverse/forward mismatched at least twice over the pa= st > 40 years. >=20 > I'm looking for a good well reviewed reference to use rather than repeatin= g > this again. >=20 > --=20 > Michael Richardson . o O ( IPv6 I=C3=B8T consult= ing ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Transfer-Encoding: 7bit --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I tried to document this ages ago in <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-mapping-= considerations/">https://datatracker.ietf.org/doc/draft-ietf-dnsop-reverse-m= apping-considerations/, and got so many contradictory edits (see the his= tory) that the final version ended up saying =E2=80=9CA or maybe not-A, or m= aybe both, your choice,=E2=80=9D so the then-chairs decided the document was= n=E2=80=99t worth sending through publication. 

A
=E2=80=94 
Andrew Sullivan 
Pl= ease excuse my clumbsy thums

On Apr 11, 2022, at 11:38, Michael Richardson <mcr+ietf@sandel= man.ca> wrote:

=EF=BB=BF
Hi, in reviews of
 https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-consid= erations-04.html

I was asked to expand upon= why the reverse map can not be intelligently used  
fo= r MUD ACLs. (section 3, XXX stuff)
(MUD controllers, upon be= ing presented with ACLs made up of
names need to do forward l= ookups of the names and build ACLs based upon the
IP address= es.)

There are two aspects of this:<= br>  1) even in an ideal situation, it takes too long on the firs= t packet to
    extract a name from an I= P address.  Yes, that could be aggresively cached.

 2) forward:reverse maps are N:M mappings, often with uni= directional parts, and often
    broken= or not delegated.

    = ;Further, there is no authorization of the mappings, so an attacker who
    wants to be able to reach IP address 20= 01:db8::abcd, can insert a
    reverse n= ame of their choice, including updates.example.com, which is
    permitted by the MUD ACL.
<= br>While I can write the above paragraph, I don't feel that it's detai= led enough
for what is needed, and I feel that we (the IETF)= must have documented the
security issues with reverse/forwa= rd mismatched at least twice over the past
40 years.<= br>
I'm looking for a good well reviewed reference to u= se rather than repeating
this again.
=
--
Michael Richardson <mcr+IETF@sandelman.ca&g= t;   . o O ( IPv6 I=C3=B8T consulting )
 &nb= sp;        Sandelman Software Works I= nc, Ottawa and Worldwide
___________________________________= ____________
DNSOP mailing list
DNSOP@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dnsop
= --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587 Content-Type: application/octet-stream; name=signature.asc; x-apple-part-url=1D73C416-64BA-4E16-A239-6ACCB655700F Content-Disposition: attachment; filename=signature.asc Content-Transfer-Encoding: 7bit Content-Id: <1D73C416-64BA-4E16-A239-6ACCB655700F> -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmJUS00WHG1jcitpZXRm QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZds5B/4mtGf3HeCwsNYMjd77ieEwJZR+ lffP/2xEfyj1VA9ou/a5hGssBKQQSob4zjOfLbW3iiTt9jexq0Qg/I/VsIpORUud o/fFOcKxdPjnMLSwuPyEJ47XY5XERovDYmiu9OUjyLeyfFdtzJcSqt649VUUrtnL rqQ6a0xXQlCx4sPfDtgygL1kwMGNBPWkRRlhUNFojB2HMpotrZuuzcOf839daaxV EED2m33gRxkfQx8KxDjytyTl+ZtmeXjX5rx7+IsHbw3bfF7KghY2kqtAwiD1RLvW nz0Ds+jtCD/D5EghwESYh3ZyijHsZY3edPJ0tFEQHkar9KBnVYhr7tJ8TMcc =I9iN -----END PGP SIGNATURE----- --Apple-Mail-38BA4F31-A61D-4D87-98B4-5F097734D587-- --Apple-Mail-9F2151B5-34BA-4095-8D13-CFB6B0331CA6--