[ntp:hackers] What does "interface listen wildcard" do?

Philip Prindeville philipp_subx at redfish-solutions.com
Fri Jul 12 04:25:44 UTC 2013


Inline…

On Jul 10, 2013, at 8:54 AM, Brian Utterback <brian.utterback at oracle.com> wrote:

> On 7/9/2013 11:30 PM, Danny Mayer wrote:
>> The short answer is "DON'T". The longer answer is that such packets are not allowed to be forwarded by a router so you should use a specific subnet specific address, e.g. 10.10.10.255 when using broadcast mode. I think that we allowed the wildcard address for such packets but it's not good news and interferes with configuring specific addresses. Danny
> 
> I find that position completely untenable.
> 
> 1. This used to work.

Lots of buggy or dangerous behavior "used to work". If it no longer does, that's usually a "win".


> 2. Users expect it to work.

Users expect to use weak passwords and not be hacked. Thank God for adult supervision.


> 3. I know of no network "best practice" or other document that even hints that one should used directed broadcasts in preference to undirected broadcasts. They each have specific uses and cannot replace one another.

Then you should refer to the IPv4 "Router Requirements" RFC-1812, specifically:

4.2.3.1 IP Broadcast Addresses


   For historical reasons, there are a number of IP addresses (some
   standard and some not) which are used to indicate that an IP packet
   is an IP broadcast.  A router

   (1) MUST treat as IP broadcasts packets addressed to 255.255.255.255
        or { <Network-prefix>, -1 }.

   (2) SHOULD silently discard on receipt (i.e., do not even deliver to
        applications in the router) any packet addressed to 0.0.0.0 or {
        <Network-prefix>, 0 }.  If these packets are not silently
        discarded, they MUST be treated as IP broadcasts (see Section
        [5.3.5]).  There MAY be a configuration option to allow receipt
        of these packets.  This option SHOULD default to discarding
        them.

   (3) SHOULD (by default) use the limited broadcast address
        (255.255.255.255) when originating an IP broadcast destined for
        a connected (sub)network (except when sending an ICMP Address
        Mask Reply, as discussed in Section [4.3.3.9]).  A router MUST
        receive limited broadcasts.

   (4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or {
        <Network-prefix>, 0 }.  There MAY be a configuration option to
        allow generation of these packets (instead of using the relevant
        1s format broadcast).  This option SHOULD default to not
        generating them.

   DISCUSSION
      In the second bullet, the router obviously cannot recognize
      addresses of the form { <Network-prefix>, 0 } if the router has no
      interface to that network prefix.  In that case, the rules of the
      second bullet do not apply because, from the point of view of the
      router, the packet is not an IP broadcast packet.


Limited broadcast packets are dangerous. You can broadcast storms and denial-of-service attacks that are leveraged via broadcasts. They are often NOT sent with a TTL of 1 as they are required to be.

There are also broken routers which violate this RFC 1812 requirement:

   (c) { -1, -1 }

         Limited broadcast.  It MUST NOT be used as a source address.

         A datagram with this destination address will be received by
         every host and router on the connected physical network, but
         will not be forwarded outside that network.

Then again, accepting directed broadcasts from outside your administrative domain is also brain-dead, but lots of people allow that too.


> 4. I know of at least one major router vendor whose NTP implementation does not allow the admin to set the broadcast address used by router for broadcast packets.


That's arguably not a bad thing. The broadcast address to use for a subnet broadcast is bound to the interface state, and should not be overridden by an application.  All NTP should care about is what interfaces it's sending [broadcast] packets out, and it can inherit that information from the interface.


> 5. I know of at least one major router vendor whose routers automatically convert directed broadcasts passing through the router into undirected broadcasts when the specified sub-net is reached.

That's extremely brain-dead. I would not buy a router from this manufacturer. Rewriting IP header fields (other than the TTL) is not to be done lightly.


> 6. The creation of subnetting was specifically designed so that the applications do not need to know the subnet masks of the adjacent sub-nets. Using directed broadcasts violates this principle and will probably break many configurations of virtual networking, certainly those using routers I mentioned in point 5.

No, subnetting was created to allow for more efficient use of network address space. Quoting RFC 950:

1.  Motivation

   The original view of the Internet universe was a two-level hierarchy:
   the top level the Internet as a whole, and the level below it
   individual networks, each with its own network number.  The Internet
   does not have a hierarchical topology, rather the interpretation of
   addresses is hierarchical.  In this two-level model, each host sees
   its network as a single entity; that is, the network may be treated
   as a "black box" to which a set of hosts is connected.

   While this view has proved simple and powerful, a number of
   organizations have found it inadequate, and have added a third level
   to the interpretation of Internet addresses.  In this view, a given
   Internet network is divided into a collection of subnets.

   The three-level model is useful in networks belonging to moderately
   large organizations (e.g., Universities or companies with more than
   one building), where it is often necessary to use more than one LAN
   cable to cover a "local area".  Each LAN may then be treated as a
   subnet.

But to address your actual point, if you don't know the topology of adjacent subnets and their masks, then you probably have no business communicating with them anyway as you might be an exploitable attack surface for a DDoS attack.


> 
> On a related but mostly independent note:
> 
> I think we made a big mistake in 2004, extending the usage of the system of binding all of the interfaces as documented in bug 314, instead of trying to eliminate it. At the time I was concerned about how prevalent IP_PKTINFO was, particularly since it wasn't available in Solaris. But I think it is now available in most platforms. Other than the single issue of whether of not it is a supported part of all of our supported platforms, there is no other argument against using IP_PKTINFO documented in bug 314 that I think has held up nine years on.

You could use SOCK_RAW as a work-around for platforms not providing IP_PKTINFO.  On Linux you could additionally use IP_RECVORIGDSTADDR.

-Philip


> 
> I argued against the introduction of the "interface listen" keywords exactly because I thought it would make it harder to adopt IP_PKTINFO, because by that point I was convinced that it was the right way forward, and I still think so.  Posix adopted IP_PKTINFO precisely to eliminate the need to bind to all interfaces. However, I no longer think that the "interface listen" configuration are actually an impediment. I would certainly love to see the ntp_io.c code refactored to use IP_PKTINFO.
> 
> Brian Utterback



More information about the hackers mailing list