Thanks, Ted.
I agree with your overall assesment, but the question was what
an implementation should do in the face of a particular pre-existing
condition: Aka: With mDNS or GRASP as they both stand today
(me of course right now primarily interest in GRASP< but if
implementation/operational guidance for mDNS existed, i could simply
point to that).
The networks where i am worried are not home networks,
but something like an office park network, where supposedly each
tenant (company) should have gotten their disjoint L2 domains, ... and then
they didn't. And one of the tenants has a "funny" network engineer/hacker.
So, eliminate for your assessment the option of better
protocols. Now, why would this heuristic then still be
"very bad" ? To me it just eliminates the benefits of
dynamic port signaling when there is an attack. And has no
impact under no attack.
Cheers
Toerless
On Sun, Oct 25, 2020 at 03:41:26PM -0400, Ted Lemon wrote:
> That would be a very bad heuristic. The whole point of SRV records is to
> eliminate the dependency on reserve ports.
>
> Really this is a non problem. We are not seeing this on home networks at
> present, because it???s just not an interesting attack. But supposing that we
> wanted to do something about it, the way to do so would be twofold.
>
> First, use protocols that allow for establishment of trust so that an on link
> spammer???s offered service can???t mimic a trusted service. E.g., use self
> signed certs and TOFU to prevent spoofing.
>
> Second, switch away from Multicast to DNSSD over DNS, and establish trust
> that way. If services register using DNSSD Service Registration Protocol,
> FCFS naming prevents spoofing of trusted services.
>
> Of course there always has to be a trust establishment process, like BRSKI.
>
> I???m sure that something similar can be done with anima.
>
> > On Oct 25, 2020, at 15:25, Toerless Eckert <t...@cs.fau.de> wrote:
> >
> > ???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.
> >
> > Cheers
> > Toerless
> >
> > P.S.: for original text in subject draft look for "Attackers on a subnet
> > may be able to inject malicious"
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
--
---
t...@cs.fau.de
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
