A Method for Storing IPsec Keying Material in DNS
draft-ietf-ipseckey-rr-12
Yes
(Steven Bellovin)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Harald Alvestrand)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
Note: This ballot was opened for revision 12 and is now closed.
Allison Mankin Former IESG member
Yes
Yes
(2003-12-03)
Instead of RFC1521 for Base64 (v. old), reference RFC3548. In the examples, replace ip6.int with ip6.arpa. In the IANA Considerations, there's a typo: This document creates an IANA registry for the algorithm type field. Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3 through 255 can be assigned by IETF Consensus (see RFC2434 [6]). This document creates an IANA registry for the gateway type field. Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4 ^ Gateway type through 255 can be assigned by Standards Action (see RFC2434 [6]).
Steven Bellovin Former IESG member
Yes
Yes
()
Alex Zinin Former IESG member
No Objection
No Objection
()
Bert Wijnen Former IESG member
(was Discuss)
No Objection
No Objection
()
Bill Fenner Former IESG member
No Objection
No Objection
()
David Kessens Former IESG member
No Objection
No Objection
()
Harald Alvestrand Former IESG member
(was Discuss)
No Objection
No Objection
()
Jon Peterson Former IESG member
No Objection
No Objection
(2003-12-04)
The end of Section 4 says: Any user of this resource record MUST carefully document their trust model, and why the trust model of DNSSEC is appropriate, if that is the secure channel used. Does that really mean "any user"? Do we require end-users of our specifications to generate documentation these days? If this is instead referring to derivate specifications or IETF-shepherded operational models based on these RRs, it should say so explicitly here. Nit: Should we encourage/require people who use xml2rfc to use the <?rfc compact="yes"?> directive? The amount of whitespace that is generated otherwise is a little bothersome.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Ned Freed Former IESG member
No Objection
No Objection
(2003-11-26)
No IPR boilerplate
Russ Housley Former IESG member
No Objection
No Objection
()
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Ted Hardie Former IESG member
No Objection
No Objection
(2003-12-02)
This text: 2.1 IPSECKEY RDATA format The RDATA for an IPSECKEY RR consists of a precedence value, a public key, algorithm type, and an optional gateway address. seems to leave out gateway type, described in section 2.4. The rest of the document is clear, but it would probably be good to add it in here.
Thomas Narten Former IESG member
(was No Record, Discuss)
No Objection
No Objection
(2004-09-27)
New text is better. Thanks. Some minor wordsmithing suggested for first two paragraphs: Suppose we have a host which wishes (or is required by policy) to establish an IPsec tunnel with some remote entity on the network prior to allowing normal communication to take place. In many cases this end system will be able to determine the DNS name for the remote entity (either by having the DNS name given explicitely, by performing a DNS PTR query for a particular IP address, or through some other means, e.g., by extractng the DNS portion of a "user@FQDN" name for a remote entity). In these cases the host will need to obtain a public key in order to authenticate the remote entity, and will also need some guidance about whether it should contact the entity directly or use another node as a gateway to the target entity. The IPSECKEY RR provides a storage mechanism for storing such information.