[dns-operations] Having doubts about BCP38 solving the ORN problem

Vernon Schryver vjs at rhyolite.com
Mon Apr 1 17:14:21 UTC 2013


> From: Fred Morris <m3047 at m3047.net>

> The premise with regard to BCP38 + open resolvers is that the spoofed
> packets reside on different networks than the resolvers. If these
> resolvers are primarily CPE and other unmaintained equipment, then it
> stands to reason that they reside inside networks containing other
> equipment; and this equipment could be the source of the source-spoofed
> (DNS) packets.
>
> Reflecting traffic off of an open resolver on one's own network would
> serve to cloak the true identity of the originator.

Other responses have been good about the general issue of where
ingress filtering must be done, but I think that scenario is so
specific that it wants a narrow response.

The rest of the Internet does not care which boxes inside the customer
network send the stream of UDP/53 packets.  It doesn't matter to the
rest of the Internet whether the bad guy reflects them off resolvers
inside the customers network or sends them directly.  On the outside,
it *is* a simple DoS attack without reflection complications.

The customer might care, because floods reflected off internal
resolvers might cause spikes on the resolvers that might be more
noticable than valid packets (at least not violating BCP38 filters)
directly from the corrupt systems to the outside target.

Floods sent directly from the corrupt systems to the distant target
instead of by reflection will have fewer packet losses.  If the bad
guy can forge source addresses, then a Dos attack direct from the
corrupt system can appear to come from the customer's resolver, but
without triggering rate limits or other defenses on the resolver.

Only if the customer has unusual firewall rules limiting *outbound*
UDP/53 to the resolvers and if those rules are not based on more
than IP source address would reflections be better for the bad guy
than sending directly.


Vernon Schryver    vjs at rhyolite.com



More information about the dns-operations mailing list