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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Kim,

On 2/23/2012 10:57 AM, Kim Kinnear wrote:

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@xxxxxxxx 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.

Thanks for the clarification.

	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."

That's awkward. I know you intend this to mean "replies to new queries MUST NOT block on the current response", but it also reads as implying "the server MUST not block on the current response, but can block after that".

Perhaps "the server MUST NOT allow any one response to block other pending responses; where multiple responses are pending, they MUST be interleaved (round-robin per-request? round-robin weighted by response length? other?)."

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


- 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@xxxxxxxx

	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.

IMO, that's an insufficient reason; the Internet is rife with protocols that nobody would look at - until they did ;-)

...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.

Either:
	a) if this is true, then the protocol needs a mechanism
	to *enforce* its use *only* in this sort of environment
or
	b) IMO, it *will* be used elsewhere, and such use should
	be anticipated in its design

I favor the latter approach, but either one is a path forward.

Joe

... 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]