[DNSOP] looking for reference for reverse maps do not work
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 11 April 2022 15:38 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 8C27D3A09B7; Mon, 11 Apr 2022 08:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, 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 (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 dudD-RgWMD5l; Mon, 11 Apr 2022 08:37:56 -0700 (PDT)
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 4828D3A0FE2; Mon, 11 Apr 2022 08:37:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 83D4038C3C; Mon, 11 Apr 2022 11:49:21 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Sw8hvGqwY5yR; Mon, 11 Apr 2022 11:49:20 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F1CE38C27; Mon, 11 Apr 2022 11:49:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1649692160; bh=C6JYezNT1qyyXdl/X+70PXPdxEUeP42AY+HRTQIzIII=; h=From:To:Subject:Date:From; b=8F0TMyivGtY5izxXixK+ZgsMrGp/FXtRf+W1x/zAAV+SIk5orSiNcgJ4FPIEYag8C teIlsDjI6q035vFYqwbdAexh1jkogWpEurSQy/H8c8uXnVlG67aisnTUHPUI9AFM4p 6Lbud1rykblstkyqm+9epnyNRdVRotS4qHov+aY/TucwKpIr5LMJ/nZeJs6wzLH0il g2znib1okeSb0lnQZmMON5nvryCqV/GoxK57WSV/5DvIaT8kgIc/93vPFcJSjMgJaZ 50NrBYm6f8hyi7TmvJEfVKWRGonqW8PId3Q7Qhgfn7WuylwBNp6x/U+0vvPRBTlCEg q1KANyTXE0vZA==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60D29A7; Mon, 11 Apr 2022 11:37:49 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dnsop@ietf.org, mud@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Mon, 11 Apr 2022 11:37:49 -0400
Message-ID: <24231.1649691469@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/a5BI0LaksJFtbQAxvCUwp-dwTHc>
Subject: [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 <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2022 15:38:01 -0000
Hi, in reviews of https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-iot-dns-considerations-04.html I was asked to expand upon why the reverse map can not be intelligently used 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 the IP addresses.) 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 cached. 2) forward:reverse maps are N:M mappings, often with unidirectional 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 2001:db8::abcd, can insert a reverse name of their choice, including updates.example.com, which is permitted by the MUD ACL. While I can write the above paragraph, I don't feel that it's detailed enough 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 past 40 years. I'm looking for a good well reviewed reference to use rather than repeating this again. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [DNSOP] looking for reference for reverse maps do… Michael Richardson
- Re: [DNSOP] looking for reference for reverse map… Andrew Sullivan
- Re: [DNSOP] [Mud] looking for reference for rever… Michael Richardson