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
