[DNSOP] DNSOP: question about hardening "something like mDNS" against attacks

Toerless Eckert <tte@cs.fau.de> Sun, 25 October 2020 19:25 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7088F3A1557 for <dnsop@ietfa.amsl.com>; Sun, 25 Oct 2020 12:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2wAMEsdoMbb2 for <dnsop@ietfa.amsl.com>; Sun, 25 Oct 2020 12:25:02 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7521C3A1554 for <dnsop@ietf.org>; Sun, 25 Oct 2020 12:25:02 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DE833548068; Sun, 25 Oct 2020 20:24:56 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D80EF440059; Sun, 25 Oct 2020 20:24:56 +0100 (CET)
Date: Sun, 25 Oct 2020 20:24:56 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: dnsop@ietf.org
Cc: kaduk@mit.edu
Message-ID: <20201025192456.GG48111@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Hd9hm9udGyvZ86xMG_ThcLVAJ98>
Subject: [DNSOP] DNSOP: question about hardening "something like mDNS" against attacks
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: Sun, 25 Oct 2020 19:25:04 -0000

Ben Kaduk (SEC AD) was wondering about the appropriateness of a hardening suggestion
in draft-ietf-anima-autonomic-control-plane-29. Let me translate this into
mDNS, even though its about GRASP, but IMHO for the purpose of this issue
its equivalent:

Node wants to discover on a LAN a particular service and unfortunately, attackers
on the LAN want to spam it.  For example by sending out a significant number
of false mDNS messages claiming the service is available on a variety of 
of ports (lets keep attacks against other serive parts like the I address
out of this). And in effect, the node will attempt a lot of service instantiations
to bogus ports.

Now, in one case, the service may have an IANA registered well-known TCP or UDP
port number. So the hardening recommendation in our draft text is that if a lot
of answers are received AND the node knows that there is a well-known port, then
it should prioritize trying the service over that well known port.

Any reason why this would not be a good obvious heuristic ?
Has this been considered for mDNS alreay anywhere (rfc ?).

Of course, if there is no well known port, this does not help. And if
the non-attacker can only offer a service with a well-known port number only
on a non-well-known port number, than it actually hurts, but i think those
are unavoidable limitations. And it easily spells out that one of the
key benefits of getting a well-known port number for something is to
be able to avoid having to guess in the face of such attacks, when discovery
of port number can not be secured.

Aka: In our case we have one potential upcoming service over DTLS, and
this text could help decide later on if we wanted to apply for a
well-known port number for this service if we get operational experience
that that could help in conjunction with this hardening recommendation.


P.S.: for original text in subject draft look for "Attackers on a subnet may be able to inject malicious"