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

Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

    Date:        Mon, 14 Jul 2008 00:09:45 -0700
    From:        Ted Lemon <Ted.Lemon at nominum.com>
    Message-ID:  <1A6237355F59494CB8CD9791D7F9D1D9059CF1D1 at exchange-01.WIN.NOMINUM.COM>

  | This simply isn't true.   The way I have always envisioned writing
  | this code (which, I admit, I have never written) is to represent the
  | option internally as zeroes, and then call the routine that constructs
  | the packet.   Then compute the actual checksum.

That might be possible for the existing AUTH option, it is not for the
CGA signature (that is, that isn't how public key signatures are constructed).

But in any case, since you need special case code for the option, why
would you be just shoving it at any random place, rather than last
which is when the calculations are needed anyway.

  | Actually, it wouldn't be natural to optimize this case, because there's
  | no way to optimize it.   You can't traverse the options backwards.

That's not the kind of optimisation I was thinking of.  for a signature
for a CGA, all of the other data in the packet needs to be fed into the
hash function.   The API for the hash function is generally
	hash_init()
	bufp = packet;
	while (not end) {
		if (seg_wanted)
			hash_include_data(bufp, seg_len);
		bufp += seg_len;
	}
	hash_result()

The optimisation is

	hash_init()
	hash_include_data(packet, packet_len-sig_len)
	hash_result()

that is, there is only one call to the "calculate the hash of the
data" function, and it hashes everything from the start of the packet
to the beginning of the sig option.   Doing it this way makes the code
easier to write, and more likely to be correct.

  | The obvious optimization for both the server and client is to put
  | the option at the beginning.

Since there's a fixed header on the packet that you can't put the
option before (I believe), that still means having split data.

I have no idea why this would be an optimisation for the server, anywhere
but last (assuming your method worked) would mean two operations, first
allocating and clearing the option space, and second calculating and
filling in the hash result (or signature in the CGA case).   Adding
it last means all this gets done together.

For the client, sure, having the auth data first means it could be
verified before looking at the rest of the packet, but I think that's
the kind of optimisation that looks good at first glance, but turns out
to be a poor choice.   Before doing the (even hash function not all
that expensive) calculations, the client should at least ensure the
packet looks to be correctly formatted - that is, the options and their
lengths nicely take the parser to the end of the packet, nothing required
is missing, no other base rules violated, ... all those are cheap checks,
even cheaper than a hash calculation, and definitely cheaper than a
public key validation.

  | This is exactly backwards.   We want broken clients to fail early
  | and often.   Otherwise they never get fixed.

Yes, that's what I'd want too.   My point is that I don't really see the
auth option occurring anywhere but last, and certainly not a CGA
signature, regardless of where it is permitted to be.   What's more,
I think if you did actyally write the code, and weren't deliberately
concentrating on this little discussion, you'd put it at the end too.
It is just easier that way (I have written code like this).

  | The best place for the server to put the option is in the middle
  | of the packet, where neither the assumption that it's at the beginning,
  | nor the assumption that it's at the end, will work.

Sure, if the point of the server is to stress clients (and the rules allow
that).   Somehow, I doubt most server authors really write their code so
as to cause problems for clients.   We all know (in all areas, not just DHCP)
that the average user's opinion is that "it works with that server, it
doesn't work with your server, your server must be broken", and no matter
how much you point out that your server is just implementing things
differently, unless you can show that the other server is broken (and it
isn't here), you can't win that argument.

This is even more true with things like dhcp clients, of which organisations
have orders of magnitude greater numbers than dhcp servers, and for which
changing the client is often essentially impossible, but changing the
server is just a few hours work.

  | This is also untrue.   You want to use the regular packet construction
  | code to place the option in the packet;

Of course, the question is not the code that adds the option, but the
order in which it is added.   It has to be done in some order or other.
Last is just easier.

  |  There are no primitives for "get the last option" or "put this at the end."

You don't need the former, and the latter is the same as "add this option",
that is, they're all "added at the end", it is just that after adding each,
the end moves.   The only thing in question is the sequence of option
adding.

kre

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg