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