On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)" <volz@xxxxxxxxx> wrote:
How about we address issue 1 by expanding the DHCID RR type code. We have 16-bits and we're just using 4 values presently. There's plenty of room for future expansion *SHOULD* someone come along and demand a new algorithm in the future. I can't see why this would EVER occur since this really isn't about strong cryptographic protection (we're just trying to make it non-trivial to find a client's identity by not storing it in clear text).
I think that's a good start; in fact, I was going to propose something very similar. This solves half the problem; particularly, it makes it possible to indicate that some other hash is in use. It does bind the hash to the type, rather than allowing them to be specified orthogonally, but I don't think that's a major problem. If it ever becomes an issue, there should be no problem defining a type where the next 16 bits indicate a subtype and the 16 bits after that indicate a hash.
However, it doesn't solve the other half of the problem, which is present even without considering changing hash algorithms. The problem is that for any given fqdn and DHCP client, there are multiple possible DHCID RR's; in particular, one for each type. In order the update mechanism to work without requiring either an advance query or multiple update attempts, all possible updaters must agree in advance on the type in use. This lack of negotiation seems problematic to me, even in the absence of multiple hash algorithms.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf