On Mon, Oct 26, 2020 at 04:39:10PM -0400, Ted Lemon wrote: > On Oct 26, 2020, at 4:14 PM, Toerless Eckert <t...@cs.fau.de> wrote: > > And the question from the AD was what could be done. So, do you have any > > implemention suggestion ? Are there any sugestions for mDNS ? > > There are no simple mitigations. If there were, they would already be in the > protocol.
And with protocol you also include local state machineries such as the heuristic i described ? (sorry, just wanting to make sure). > > Btw: I do agree that for most use of mDNS as it is relying on dynamic ports, > > my suggestion would create an undesired trend of allocating static port > > numbers. > > This is also true for GRASP in general, but for the specific use-cases > > in mind in my text, which are really inside-network infra protocols, the > > argument could be > > made that static port allocation was indeed well feasible (as we're talking > > about a > > very small number here) . But we had not done it because we hadn't vetted > > the benefits > > of doing such a port allocation. > > If it???s a multicast discovery protocol with no authentication, then > constraining the set of allowed ports just means that the node that???s > attacking you has to be able to listen on that port, which it likely can. So > I think this reduces function without increasing hardening. Elimination of the port number as an announced service element (and instead assuming there is a well-known port) eliminates the amplified attack of sending such announcements with a sweep of port numbers and therefore condemning the consuming client to try out all those port numbers. > What actually hardens mDNS is that it???s a link-local protocol. > It doesn???t work across links. I am not aware that the solutions to extend mDNS across multiple hops would be any more hardened necessarily. But water under the bridge. > This limits the attack surface. > But there???s no way to eliminate the attack surface. > If I were in Ben???s shoes, I???d be asking you to change the protocol > to support authentication and ToFU as a hardening strategy, > with some better trust establishment mechanism as future work based > on the existing presence of crypto signatures. > But the current consensus of the IETF is apparently that ADs aren???t allowed > to insist on things like that. :( Well, it would singling out new work with a humunguously higher bar to jump over than widely used protocols even including similar DoS attack in DAAD if i am not mistaken (given how mDNS isn't all that prevalent). Or just look at how convoluted the work was to attempt making process with neighbor discovery in routing protocols. Actually for our specific use-case i would like to propose an authenticated method, alas there is no pre-established knowledge of the cert of the neighbor, so it might have to include the whole bloody cert in a packet to authenticte the packet, and that might be problematic size-wise. Maybe payload-layer segmented multicasting *sigh*. Discussion for another time. -- --- t...@cs.fau.de _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
