A Method for Storing IPsec Keying Material in DNS
RFC 4025

Note: This ballot was opened for revision 12 and is now closed.

(Steven Bellovin) Yes

(Allison Mankin) Yes

Comment (2003-12-03 for -)
No email
send info
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]).

(Harald Alvestrand) (was Discuss) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ned Freed) No Objection

Comment (2003-11-26 for -)
No email
send info
No IPR boilerplate

(Ted Hardie) No Objection

Comment (2003-12-02 for -)
No email
send info
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.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) (was No Record, Discuss) No Objection

Comment (2004-09-27)
No email
send info
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.

(Jon Peterson) No Objection

Comment (2003-12-04 for -)
No email
send info
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.

(Bert Wijnen) (was Discuss) No Objection

(Alex Zinin) No Objection