ietf
[Top] [All Lists]

Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery

2012-02-24 10:20:32

Joe,

There were two things that I referenced in response to your initial
review that you hadn't seen.  More details on those below:


On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:

--------------------------------------------

INTERLEAVING- sec 7.7 says that the server MUST interleave
replies;
there doesn't seem a valid reason for this requirement. clearly the
receiver MUST tolerate interleaved replies. having the server interleave
replies is relevant only if each request/reply has its own timeout --
which should be overridden if there is another response in progress
anyway. This issue should be more clearly explained and motivated.

      Robert Sparks offered clarification, which I like
      a lot and have already agreed to use:

I didn't see that; can you send that to tsv-dir(_at_)ietf(_dot_)org and me?

     Is the requirement you are really trying to capture "MUST
     NOT block sending replies on new queries until all
     replies for the existing query are complete."?

        I wasn't clear here -- the entire result of our
        discussion was captured in the text above.

        Note that a server does not *have* to support multiple
        queries on the same connection.  If, however, a server
        chooses to do so, then the following discussion is
        operative:

        Based on my discussion with Robert Sparks, the sentence:

          "A server that is processing multiple queries
          simultaneously MUST interleave replies to the multiple
          queries within the stream of reply messages it sends."

        will be replaced by the sentence:

          "The server MUST NOT block sending replies on new
          queries until all replies for the existing query are
          complete."

-------------------------------------------------


- The protocol supports bulk transfer that is not data driven.
This could represent a security vulnerability by exposing
information that may not be on the data path (and thus already
accessible) to a relay agent. This should be discussed in the
security considerations section.

     All data that is exposed has already been
     exposed using UDP to regular DHCP port.   But please see
     my response to Stephen Farrell (which is too long to include
     here) to see if it covers the issues about which you
     have concerns.

Again, I didn't see it; please send a copy to tsv-dir(_at_)ietf(_dot_)org


        There are two related posts that I will include here
        in order to keep this discussion in some kind of order.

        Here are the words that I proposed to Stephen which
        he accepted:

  There are two specific issues regarding Bulk Leasequery
  security that deserve explicit mention.  The first is
  preventing information that Bulk Leasequery can provide from
  reaching clients who are not authorized to receive such
  information.  The second is ensuring that authorized clients of
  the Bulk Leasequery capability receive accurate information
  from the Server (and that this information is not disrupted in
  transit).

  To prevent information leakage to unauthorized clients Servers
  SHOULD restrict Bulk Leasequery connections and
  DHCPBULKLEASEQUERY messages to certain requestors, either
  through explicit configuration of the Server itself or by
  employing external network elements to provide such
  restrictions.  In particular, the typical DHCPv4 client SHOULD
  NOT be allowed to receive a response to a Bulk Leasequery
  request, and some technique MUST exist to allow prevention of
  such access in any environment where Bulk Leasequery is
  deployed.

  Connections not from permitted requestors SHOULD be closed
  immediately, to avoid server connection resource exhaustion or
  alternatively, simply not be allowed to reach the server at
  all.  Servers SHOULD have the capability to restrict certain
  requestors to certain query types.  Servers MAY reply to
  queries that are not permitted with the DHCPLEASEQUERYDONE
  message with a status-code option status of NotAllowed, or MAY
  simply close the connection.

  To prevent disruption and malicious corruption of Bulk
  Leasequery data flows between the server and authorized clients
  these data flows SHOULD transit only secured networks.   These
  data flows are typically infrastructure oriented, and there is
  usually no reason to have them flowing over networks where such
  attacks are likely.  In the rare cases where these data flows
  might need to be sent through unsecured networks, they MUST
  sent over connections secured through means external to the
  DHCPv4/DHCPv6 server and its client(s) (e.g., through VPN's).

        Here is Ted Lemon's reply to Stephen's suggestion about
        using SSH/TLS to secure the data flows of DHCPv4
        Bulk Leasequery:

From Ted Lemon, Feb 22 2012, 10:37:12 EST:

The main reason why TLS wasn't included is that there is zero
chance of anyone using it.   In practice this protocol is useful
only in a very specific sort of application: communications
between the core of an ISP network and the edge of the ISP
network.   Encrypting everything would be quite expensive; the
value of the data that would be acquired in an attack is low; the
risk that there could be an attacker that would do this is low,
since it would require physical access.   Furthermore, if someone
does break in, they can just collect this data with a sniffer.

Given these considerations, the additional verbiage and testing
required for TLS support seemed unnecessary and potentially
damaging, since untested code is vulnerable code.   The working
group did actually consider requesting that the authors add TLS
to the document, but concluded that it was not worthwhile.

-----------------------------

        Regards -- Kim





_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf