Skip to main content

A Method for Storing IPsec Keying Material in DNS
RFC 4025

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 steering group 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 steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Bert Wijnen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Jon Peterson; former steering group 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 steering group member) No Objection

No Objection ()

                            

(Ned Freed; former steering group member) No Objection

No Objection (2003-11-26)
No IPR boilerplate

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Scott Hollenbeck; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group 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 steering group 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.