IETF Logo Mail Archive

Re: [OPSAWG] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

Eliot Lear <lear@cisco.com> Thu, 24 September 2020 08:37 UTC

Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FD33A0A21; Thu, 24 Sep 2020 01:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLKc45t17i8v; Thu, 24 Sep 2020 01:37:55 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70D53A0A24; Thu, 24 Sep 2020 01:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10148; q=dns/txt; s=iport; t=1600936675; x=1602146275; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=zFuXD8LKF1anQfnKXtZ07UdOciG0Sd80eIek6Ul6oRw=; b=A9y+QGt+ru0e8s9bsrcIxJyTulo1xbaxIzLtRg6YOvvH53puKReO/rpz nvBXN6Gdg5HlPM1v6Fu2hRrHGn/GvzE+Gh60gzJQCdZwD8c/l9XP2hy19 KT0zep5RIl4nEXO/G9YdyIIvjm5LoT4G7BVuT/Jfl/5TSRIoGnfRlTLgN I=;
X-Files: signature.asc : 488
X-IPAS-Result: A0BYAADMWWxf/xbLJq1gGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIFPgSOBB4FFASASLI0+iEGHY4wliBkEBwEBAQoDAQEvBAEBhEsCgislOBMCAwEBAQMCAwEBAQEFAQEBAgEGBG2FaIVyAQEBAQIBcgcFCwsYLlcGE4MmAYJcILUbdIE0hVOFBhCBOIFTi3SCAIE4HIJNPogHgi0EmlaBGZtEgnGDE4E0iweLBQMfoQqvI4NcAgQGBQIVgWsjKoEtMxoIGxVlAYI+PhIZDY5WjhI/AzA3AgYKAQEDCZAeAQE
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,296,1596499200"; d="asc'?scan'208,217";a="27445632"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2020 08:37:50 +0000
Received: from dhcp-10-61-109-24.cisco.com (dhcp-10-61-109-24.cisco.com [10.61.109.24]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08O8bnwq011661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Sep 2020 08:37:50 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <C614A7E9-EF1C-4A8E-BD5A-A17C074F3E09@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C657F58C-B383-42F4-A29E-E38C671793A4"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 24 Sep 2020 10:37:49 +0200
In-Reply-To: <16821.1600885661@localhost>
Cc: "Panwei (William)" <william.panwei@huawei.com>, opsawg <opsawg@ietf.org>, "mud@ietf.org" <mud@ietf.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <160082461405.2339.249127609152770744@ietfa.amsl.com> <f61a62eba99f4e17a96d222e384f4c8a@huawei.com> <16821.1600885661@localhost>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Outbound-SMTP-Client: 10.61.109.24, dhcp-10-61-109-24.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/dT3VzJvSMPZjLasmUGYBHRM9esU>
Subject: Re: [OPSAWG] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 08:38:04 -0000

Hi,

> On 23 Sep 2020, at 20:27, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> Yes, the CPE could look at the DNS queries the device is using, and then
> cache them.   Or, when it loads the MUD file, it could do a DNS lookup on all
> the names, and cache them.  Then, when the device asks, it is already cached,
> and one can be sure that a known IP/name combination is returned.
> If it does this DNS lookup on a regular basis (updating the MUD ACLs
> implemented in the forwarding plane), then the cache stays warm, and the
> rules are accurate.
> 
> This is how our implementation worked.

Either this, or there should be a relationship between the resolver and the AP/switch/firewall/CPE in which appropriate query responses are shared. That might be the better long term approach.  What is key- in order for protection to work, the infrastructure needs to know (1) what names are authorized and (b) their associated addresses.  As important, its understanding must be the same as that of the device that makes the query.

Eliot

v2.23.0 | Report a Bug | By Email