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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
