From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Dec 10 20:39:15 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00170 for ; Wed, 10 Dec 2003 20:39:14 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1XPi10782 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 10 Dec 2003 20:33:27 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBB1ZFK21574 for ipseckey-outgoing; Wed, 10 Dec 2003 20:35:15 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1ZC821562 for ; Wed, 10 Dec 2003 20:35:12 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:cd96:c8ed::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1VU810707 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 10 Dec 2003 20:31:40 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBB1RR5R001071 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 10 Dec 2003 20:27:29 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBAMrYv8009895 for ; Wed, 10 Dec 2003 17:53:34 -0500 To: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: ipseckey out of iesg (part deux) In-reply-to: Your message of "Mon, 08 Dec 2003 16:19:52 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Dec 2003 17:53:34 -0500 Message-ID: <9894.1071096814@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- IESG> Thomas Narten: IESG> Discuss: IESG> Meta issue (this is why I'm putting in a discuss): IESG> IESG> Intro (actually no part of the document) actually explains what this IESG> RR is useful for. Consider a reader not familar with this effort who IESG> would like to understand why this RR is needed, who uses it, and in IESG> what situations its useful. For instance, it would be useful to IESG> include an example of how the RR is expected to be used. I.e., it's IESG> not until halfway down the document that one figures out the RR could I use the word "entity" rather than end system. Perhaps this is wrong. The document now reads: Abstract This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. The record also includes provisions for indicating what IP address (v4 or v6) should be contacted when establishing an IPsec tunnel with the entity in question. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. ... 1. Introduction It postulated that there is an end system desiring to establish an IPsec tunnel with some remote entity on the network. This system, having only a DNS name of some kind (forward, reverse or even user@FQDN) needs a public key to authenticate the remote entity. It also desires some guidance about whether to contact the entity directly, or whether to contact another entity, as a gateway to that entity. The IPSECKEY RR provides a storage mechanism for such items as the public key, and the gateway information. The type number for the IPSECKEY RR is TBD. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP9ej5oqHRg3pndX9AQEJkAQA4jDwV4CW5VVmXb8Wv64/QFSAGazpOAgd meuIwSS7IbgWhVkN6IGjNAM4GLAmnmJOsvVqK32Hi82ujUfg29dsrCXAplOjtkU5 kfaBy8UF9onf87aWksRNOGRpB+FOc+ByY98ehaaM+KhsWjRKVbATQIbWhDKfmHG+ F6jY+jghB1o= =mFGk -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Wed Dec 10 20:39:28 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00196 for ; Wed, 10 Dec 2003 20:39:27 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1Y1i10789 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Wed, 10 Dec 2003 20:34:03 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBB1ZCA21560 for ipseckey-outgoing; Wed, 10 Dec 2003 20:35:12 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1ZB821555 for ; Wed, 10 Dec 2003 20:35:11 -0500 (EST) Received: from sandelman.ottawa.on.ca ([2002:cd96:c8ed::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBB1VU210707 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Wed, 10 Dec 2003 20:31:38 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBB1RR5V001071 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 10 Dec 2003 20:27:29 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBAMgmYk009565 for ; Wed, 10 Dec 2003 17:42:48 -0500 To: ipseckey@sandelman.ca Subject: [IPSECKEY] Re: ipseckey out of iesg In-reply-to: Your message of "Mon, 08 Dec 2003 16:19:52 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 10 Dec 2003 17:42:47 -0500 Message-ID: <9564.1071096167@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- The IESG has made the following comments, which you can read at: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1082&filename=draft-ietf-ipseckey-rr I include the comments below, as a quote, and am responding to them, as I act on them. IESG> Last Call to expire on: 2003-11-17 IESG> Please return the full line with your position. IESG> Yes No-Objection Discuss Abstain IESG> Harald Alvestrand [ ] [ XX] [ X ] [ ] IESG> Steve Bellovin [ X ] [ ] [ ] [ ] IESG> Bill Fenner [ ] [ X ] [ ] [ ] IESG> Ned Freed [ ] [ X ] [ ] [ ] IESG> Ted Hardie [ ] [ X ] [ ] [ ] IESG> Russ Housley [ ] [ X ] [ ] [ ] IESG> Allison Mankin [ X ] [ ] [ ] [ ] IESG> Thomas Narten [ ] [ ] [ X ] [ ] IESG> Jon Peterson [ ] [ X ] [ ] [ ] IESG> Margaret Wasserman [ ] [ X ] [ ] [ ] IESG> Bert Wijnen [ ] [ ] [ X ] [ ] IESG> Alex Zinin [ ] [ X ] [ ] [ ] IESG> 2/3 (9) Yes or No-Objection opinions needed to pass. IESG> DISCUSSES AND COMMENTS: IESG> ====================== IESG> Ned Freed: IESG> Comment: IESG> No IPR boilerplate Added. I didn't find anything in the IRP WG's documents with a template. I took one from the first RFC I found that had one, which happened to be 3584.txt. IESG> Ted Hardie: IESG> Comment: IESG> This text: IESG> IESG> 2.1 IPSECKEY RDATA format IESG> IESG> The RDATA for an IPSECKEY RR consists of a precedence value, a IESG> public key, algorithm type, and an optional gateway address. IESG> IESG> seems to leave out gateway type, described in section 2.4. The IESG> rest of the document is clear, but it would probably be good to add IESG> it in here. Fixed. IESG> Allison Mankin: IESG> Comment: IESG> Instead of RFC1521 for Base64 (v. old), reference RFC3548. Done. IESG> In the examples, replace ip6.int with ip6.arpa. Already done in my copy. IESG> In the IANA Considerations, there's a typo: IESG> IESG> This document creates an IANA registry for the algorithm type field. IESG> IESG> Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3 IESG> through 255 can be assigned by IETF Consensus (see RFC2434 [6]). IESG> IESG> This document creates an IANA registry for the gateway type field. IESG> IESG> Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm IESG> numbers 4 IESG> ^ Gateway type IESG> through 255 can be assigned by Standards Action (see RFC2434 [6]). Fixed. IESG> Thomas Narten: IESG> Discuss: IESG> Meta issue (this is why I'm putting in a discuss): IESG> IESG> Intro (actually no part of the document) actually explains what this IESG> RR is useful for. Consider a reader not familar with this effort who IESG> would like to understand why this RR is needed, who uses it, and in IESG> what situations its useful. For instance, it would be useful to IESG> include an example of how the RR is expected to be used. I.e., it's IESG> not until halfway down the document that one figures out the RR could IESG> identify a gateway one connects to to create an IPsec tunnel to a IESG> particular site. But the RR is keyed by an address. Why does one need IESG> to map from the address to a gateay? I suspect 1 or 2 paragraphs IESG> would to the trick. IESG> IESG> Specific comments: IESG> IESG> Abstract could be a lot better. Reading it, one doesn't really know IESG> what this document is about or how the RR is used. Hmm. The purpose of this WG is to replace the functionality lost in the RFC3445. 2535 doesn't say what the record is for either. So I feel that this is really putting a higher standard on this record than there was in 2535. In addition, we carefully avoided saying very much about what the key means, (semantics), since that goes towards usage. We did say that any system that defines semantics must specify this stuff. Having grumbled, my next message contains suggested text, since I want to highlight this. IESG> IESG> > The RDATA for an IPSECKEY RR consists of a precedence value, a public IESG> > key, algorithm type, and an optional gateway address. IESG> IESG> picture also shows a 'gateway type' field... Already caught above. IESG> IESG> > 2.2 RDATA format - precedence IESG> > IESG> > This is an 8-bit precedence for this record. This is interpreted in IESG> > the same way as the PREFERENCE field described in section 3.3.9 of IESG> > RFC1035 [2]. IESG> IESG> say "unsigned"? also, why not just specify the semantics of the IESG> preference here, rather than pointing to a (rather unrelated) MX IESG> record RR? Hunting for the MX text in another document seems IESG> suboptimal (and results in an odd normative reference). Chairs? Copy and paste from 1035? We already reference 1035 for other reasons. IESG> > Gateways listed in IPSECKEY records with lower precedence are to be IESG> > attempted first. Where there is a tie in precedence, the order IESG> > should be non-deterministic. IESG> IESG> Note: the above text seems out of place, given the previous paragraph IESG> which just points to MX. Can't you just specify the behavior here (in IESG> its entirety) and remove the normative dependency? We could do that. Chairs? IESG> > 3 A wire-encoded domain name is present. The wire-encoded format is IESG> > self-describing, so the length is implicit. The domain name MUST IESG> > NOT be compressed. IESG> > IESG> IESG> "wire-encoded" could be made more precise. I.e., Refer to DNS spec IESG> (and specific section?). (There is better text later in the draft, IESG> actually) I've added a reference to 1035, IESG> > A 32-bit IPv4 address is present in the gateway field. The data IESG> > portion is an IPv4 address as described in section 3.4.1 of RFC1035 IESG> > [2]. This is a 32-bit number in network byte order. IESG> > IESG> > A 128-bit IPv6 address is present in the gateway field. The data IESG> > portion is an IPv6 address as described in section 2.2 of RFC1886 IESG> > [7]. This is a 128-bit number in network byte order. IESG> IESG> Why are (apparently normative) references to other RRs given here? IESG> Can't the format just be written out here, since it's basically one IESG> sentence saying N-bits in network byte order? Chairs? The reference seems appropriate to me, but I don't care. IESG> > IESG> > This document updates the IANA Registry for DNS Resource IESG> > Record Types IESG> > by assigning type X to the IPSECKEY record. IESG> IESG> Add: IESG> IESG> This document creates two new IANA registries, both specific to the IESG> IPSECKEY Resource Record. Done. IESG> Jon Peterson: IESG> Comment: IESG> IESG> The end of Section 4 says: IESG> IESG> Any user of this resource record MUST carefully document their trust IESG> model, and why the trust model of DNSSEC is appropriate, if that is IESG> the secure channel used. IESG> IESG> Does that really mean "any user"? Do we require end-users of our IESG> specifications to generate documentation these days? If this is IESG> instead referring to derivate specifications or IETF-shepherded IESG> operational models based on these RRs, it should say so explicitly IESG> here. now reads: Any derivative standard that makes use 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. IESG> Nit: Should we encourage/require people who use xml2rfc to use the IESG> <?rfc IESG> compact="yes"?> directive? The amount of whitespace that is IESG> generated otherwise is a little bothersome. Didn't know about it. Hmm. My version doesn't have that. I will look later, when online. IESG> Bert Wijnen: IESG> Bigger issue: IESG> IESG> - The examples use the reverse DNS records to convey IPSECKEY record. IESG> Does this have some unstated assumptions about the deployment of IESG> IPSECKEY (e.g., to be usable, the participating nodes should record IESG> the RRs in reverse records), or is this just a coincidence? IESG> I note that the document does not discuss the deployment at all, but IESG> that is probably intentional. IESG> IESG> If there is no connection to the reverse records, I'd suggest IESG> rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com IESG> IN IPSECKEY ..."; if there is a requirement for reverse records, this IESG> issue needs to be explicitly discussed.. DNS deployment folks might IESG> have something to say about that :-) Chairs. Reverse is clearly in scope here. Can you discuss with Bert? IESG> Nits: IESG> IESG> - Reorder sections 2.3 and 2.4 to be in the saem order as the fields. Done. IESG> - Replace the references to RFC1886 with RFC3596. Done. IESG> - Add IPR section Done. IESG> - Rename the draft shortname (at each page header) from "ipsecrr" to IESG> something else. Any suggestions? IESG> - Remove the dot from the title and upper-case it. upper-case what? "IPsec"? the whole thing? I'll ask Bert directly. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP9ehZYqHRg3pndX9AQFPFAP8CSrYOof39FLt8ba3MFoDZ+ANnQmSQqDr Bc9F8mWxgG91VircwqOnftoOJOi8XnaKa25ix1g3SuEl7GJo7H+N94VVy1VH61D+ LrZel5UdtssFqhqT1KQQAUm5iCYMFO+mvJzPyD8gC+3/KwQh1y+jtk6XLgw4Pxe1 uHXBgLiafW0= =Ylnq -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From mcr@lox.sandelman.ottawa.on.ca Mon Dec 15 11:49:31 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16318 for ; Mon, 15 Dec 2003 11:49:29 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFGnDu04727 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 15 Dec 2003 11:49:21 -0500 (EST) Received: (from mcr@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBFGlk423382; Mon, 15 Dec 2003 11:47:46 -0500 (EST) Date: Mon, 15 Dec 2003 11:47:46 -0500 (EST) Message-Id: <200312151647.hBFGlk423382@lox.sandelman.ottawa.on.ca> From: mcr@sandelman.ottawa.on.ca Subject: [ipseckey] Monthly information file for ipseckey@sandelman.ottawa.on.ca To: ipseckey-archive@ietf.org WG/mailing list description IPSEC KEYing information resource record WG (ipseckey) Please see http://www.ietf.org/html.charters/ipseckey-charter.html for the official page. To unsubscribe, email to majordomo@sandelman.ca, body is: "unsubscribe ipseckey" You can always ask majordomo@sandelman.ottawa.on.ca to remove you from any list hosted by Sandelman Software This message sent to ipseckey-archive@lists.ietf.org From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Dec 15 15:29:30 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26061 for ; Mon, 15 Dec 2003 15:29:28 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFKNji06252 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 15 Dec 2003 15:23:49 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBFKOeh11384 for ipseckey-outgoing; Mon, 15 Dec 2003 15:24:40 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFKObT11376 for ; Mon, 15 Dec 2003 15:24:38 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFKKnk06236 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Mon, 15 Dec 2003 15:21:01 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBFKFtpK020575 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 15 Dec 2003 15:15:55 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBFKFoSZ020571; Mon, 15 Dec 2003 15:15:51 -0500 To: ipseckey@sandelman.ca cc: Samuel Weiler Subject: [IPSECKEY] new draft -08 Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 15 Dec 2003 15:15:50 -0500 Message-ID: <20570.1071519350@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- Hi, I posted my comments on Wednesday. They are at: http://www.sandelman.ottawa.on.ca/lists/html/ipseckey/msg00390.html http://www.sandelman.ottawa.on.ca/lists/html/ipseckey/msg00391.html I had to get the newest XML RFC bibliography to be able to format with the suggested updates to various RFCs. (They really are new) I would appreciate some feedback on this. http://www.sandelman.ca/SSW/ietf/ipsec/key/ has the -08 draft. Repeat of questions: IESG> say "unsigned"? also, why not just specify the semantics of the IESG> preference here, rather than pointing to a (rather unrelated) MX IESG> record RR? Hunting for the MX text in another document seems IESG> suboptimal (and results in an odd normative reference). Chairs? Copy and paste from 1035? We already reference 1035 for other reasons. IESG> > Gateways listed in IPSECKEY records with lower precedence are IESG> > to be IESG> > attempted first. Where there is a tie in precedence, the order IESG> > should be non-deterministic. IESG> IESG> Note: the above text seems out of place, given the previous paragraph IESG> which just points to MX. Can't you just specify the behavior here (in IESG> its entirety) and remove the normative dependency? We could do that. Chairs? IESG> Bert Wijnen: IESG> Bigger issue: IESG> IESG> - The examples use the reverse DNS records to convey IPSECKEY record. IESG> Does this have some unstated assumptions about the deployment of IESG> IPSECKEY (e.g., to be usable, the participating nodes should record IESG> the RRs in reverse records), or is this just a coincidence? IESG> I note that the document does not discuss the deployment at all, but IESG> that is probably intentional. IESG> IESG> If there is no connection to the reverse records, I'd suggest IESG> rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com IESG> IN IPSECKEY ..."; if there is a requirement for reverse records, this IESG> issue needs to be explicitly discussed.. DNS deployment folks might IESG> have something to say about that :-) Chairs. Reverse is clearly in scope here. Can you discuss with Bert? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP94WdYqHRg3pndX9AQFTuQP/cdslnnRDy0Pz++oR2F7rwTs9BPRTcwVL GF98nnR/k5y4dBbFeXXxB0LbOB529ZEeApiAUT7jFzinABZB6kbBRPAiGJF+iH+t RRCm/8RK+dBwFf03RuZoi3c64UivnivBVN5q7fqfDjG698KDWLoYn9EjERscn9N2 FFSJMBmtoRA= =jvH1 -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Mon Dec 15 16:24:54 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00807 for ; Mon, 15 Dec 2003 16:24:53 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFLLKi06559 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Mon, 15 Dec 2003 16:21:22 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBFLNEt15854 for ipseckey-outgoing; Mon, 15 Dec 2003 16:23:15 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFLNDT15848 for ; Mon, 15 Dec 2003 16:23:13 -0500 (EST) Received: from thrintun.hactrn.net ([2002:183d:15e5:0:250:daff:fe82:1c39]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBFLJai06509 for ; Mon, 15 Dec 2003 16:19:37 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E233E18EB for ; Mon, 15 Dec 2003 16:19:28 -0500 (EST) Date: Mon, 15 Dec 2003 16:19:28 -0500 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] new draft -08 In-Reply-To: <20570.1071519350@marajade.sandelman.ottawa.on.ca> References: <20570.1071519350@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031215211928.E233E18EB@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Mon, 15 Dec 2003 15:15:50 -0500, Michael Richardson wrote: > > IESG> Bert Wijnen: > > IESG> Bigger issue: > IESG> > IESG> - The examples use the reverse DNS records to convey IPSECKEY record. > IESG> Does this have some unstated assumptions about the deployment of > IESG> IPSECKEY (e.g., to be usable, the participating nodes should record > IESG> the RRs in reverse records), or is this just a coincidence? > IESG> I note that the document does not discuss the deployment at all, but > IESG> that is probably intentional. > IESG> > IESG> If there is no connection to the reverse records, I'd suggest > IESG> rewording at least 3 of the 5 examples to use e.g. "nodeX.example.com > IESG> IN IPSECKEY ..."; if there is a requirement for reverse records, this > IESG> issue needs to be explicitly discussed.. DNS deployment folks might > IESG> have something to say about that :-) > > Chairs. Reverse is clearly in scope here. > Can you discuss with Bert? See "if there is a requirement for reverse records, this issue needs to be explicitly discussed." The issue is not whether or not IPSECKEY belongs in the reverse tree (everyone on this list knows that it does, and Bert now knows too, because I told him). The issue is that the draft doesn't explain this, it just assumes that the reader is already an expert on opportunistic IPSEC and that this is therefore obvious. Given that the reverse tree is, in general, notorious for bad maintenance, Bert is correct that the doc should explain why stuffing IPSECKEY RRs into the reverse tree is the right thing to do anyway. - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 07:59:58 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13591 for ; Tue, 16 Dec 2003 07:59:58 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGCtEi10551 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 07:55:17 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBGCuwu24669 for ipseckey-outgoing; Tue, 16 Dec 2003 07:56:59 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGCuum24664 for ; Tue, 16 Dec 2003 07:56:57 -0500 (EST) Received: from herculanum.int-evry.fr (herculanum.int-evry.fr [157.159.11.15]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGCrIi10535 for ; Tue, 16 Dec 2003 07:53:18 -0500 (EST) Received: from sparte.int-evry.fr (spartebis.int-evry.fr [157.159.10.20]) by herculanum.int-evry.fr (Postfix) with ESMTP id 2262A345E0 for ; Tue, 16 Dec 2003 13:48:03 +0100 (CET) Received: from alpes.int-evry.fr (alpes.int-evry.fr [157.159.10.19]) by spartebis.int-evry.fr (Postfix) with SMTP id 55D383F468 for ; Tue, 16 Dec 2003 13:48:01 +0100 (CET) Received: from sparte.int-evry.fr ([157.159.10.11]) by alpes.int-evry.fr (SAVSMTP 3.0.0.44) with SMTP id M2003121613471713843 for ; Tue, 16 Dec 2003 13:47:17 +0100 Received: from localhost (ivan.int-evry.fr [157.159.100.48]) by sparte.int-evry.fr (Postfix) with ESMTP id 7E8423F47D for ; Tue, 16 Dec 2003 13:47:10 +0100 (CET) Received: from jjp by localhost with local id 1AWEb9-0005bU-00 for ; Tue, 16 Dec 2003 13:46:47 +0100 Date: Tue, 16 Dec 2003 13:46:47 +0100 From: Jean-Jacques Puig To: ipseckey@sandelman.ca Subject: [IPSECKEY] New draft -08- misc Message-ID: <20031216124647.GH13895@ivan.int-evry.fr> Mail-Followup-To: ipseckey@sandelman.ca Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Hi ! I've just reviewed -08 draft. Apart from the 'reverse' topic, there's little to nothing to add. - I have, however, a question related to terminology: when we refer to entries in the reverse tree, do we consider these as names (of the form x.y.z.t.in-addr.arpa. or ip6.arpa.) or as addresses when writing about them. An example would be, should we say: a) ipseckey RR is associated with a name (regardless of forward/reverse) or b) ipseckef RR is associated with a name or an address ? Para 1.1 and 1.2 are concerned by this terminology decision: 1.1 > that is to be associated with a Domain Name System (DNS) name for use 1.2 > It is expected that there will often be multiple IPSECKEY resource > records at the same name. I think a) is the correct one, but b) explicitly remind of the reverse aspect. - In the abstract: > This document describes a new resource record for DNS. This record > | may be used to store public keys for use in IPsec systems. The > | record also includes provisions for indicating what IP address (v4 or > | v6) should be contacted when establishing an IPsec tunnel with the > | entity in question. I suggest replacing 'what IP address (v4 or v6)' by 'which system'. Pb is gateway field may be a name and map to several IPs. - 2.5 > The gateway field indicates a gateway to which an IPsec tunnel may be > created in order to reach the entity named by this resource record. ^^^^^^^^ Can we say the end system is named by the resource record ?! I would replace 'named by' by 'owning'. - There's a lot of references to 1035, which looks perfectly OK for me, but I understood from comments that referring for short sentences that could have been inserted verbatim is not appreciated. I only point this because on the "wire-encoded" note, a new reference to 1035 has been added :). - In the security considerations: > In cases where the end-to-end integrity of > the IPSECKEY RR is suspect, the end client MUST restrict its use of > the IPSECKEY RR to cases where the RR owner name matches the content > of the gateway field. I would like to spawn a quick reflexion about what if the content of the gateway field is an address within the same subnet as the RR owner ? Would it make sense to use this information when end-to-end integrity of the record is suspect ? As there is a MUST here, the question may be consensual. - In the comments, T.Narten mentioned: > I.e., it's > not until halfway down the document that one figures out the RR could > identify a gateway one connects to to create an IPsec tunnel to a > particular site. The word 'identify' is troublemaker. Obviously this was not done on purpose, and most people would understand 'locate', because this is exactly what is meant in the record. However, I wonder if we had any discussion about how the RR relates to the identity used in ISAKMP/IKE. I think we do not want to get stuck on this topic in the draft and keep it for models specs referring to ipseckey, but may be an appropriate default practice should be mentioned. I also realized that adding an identity field in the RR might have made sense in some 'me tarzan - you jane' scenarii. Comments ? - Lastly, regarding xml2rfc, the following directives may suit some needs :) (available on 1.21 version): For symbolic references ([RFCnnnn] instead of [N]): Though people often favor symbolic references, note that there is still a lot of editorial work to do when moving from numeric to symbolic (look at that DNS mess). - Note: FI, IPR boilerplates are in 2026, section 10.4. -- Jean-Jacques Puig [homepage] http://www-lor.int-evry.fr/~puig/ - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 15:38:22 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02711 for ; Tue, 16 Dec 2003 15:38:22 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKWvi12694 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 15:32:59 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBGKYcJ01876 for ipseckey-outgoing; Tue, 16 Dec 2003 15:34:38 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKYa201871 for ; Tue, 16 Dec 2003 15:34:36 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKUri12677 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 16 Dec 2003 15:30:58 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBGKRNpK024567 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 16 Dec 2003 15:27:24 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBGKRKhN024563; Tue, 16 Dec 2003 15:27:20 -0500 To: ipseckey@sandelman.ca cc: Rob Austein Subject: Re: [IPSECKEY] new draft -08 In-reply-to: Your message of "Mon, 15 Dec 2003 16:19:28 EST." <20031215211928.E233E18EB@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Dec 2003 15:27:20 -0500 Message-ID: <24562.1071606440@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Austein writes: >> Chairs. Reverse is clearly in scope here. Can you discuss with Bert? Rob> See "if there is a requirement for reverse records, this issue needs Rob> to be explicitly discussed." Rob> The issue is not whether or not IPSECKEY belongs in the reverse tree Rob> (everyone on this list knows that it does, and Bert now knows too, Rob> because I told him). The issue is that the draft doesn't explain Rob> this, it just assumes that the reader is already an expert on Rob> opportunistic IPSEC and that this is therefore obvious. okay. so what question does some text have to answer? Is it: "where is the IPSECKEY RR found?" or: "is the reverse map the place to find IPSECKEY RR?" To me, the location of the record has a lot to do with the semantics of the record. You need to know what question was being asked of DNS to know if the record will be found there. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP99qpoqHRg3pndX9AQEoYAP+NwS9QQDbjrp7K8B79ExOYyLNNCCL0Gvq iwkj5aBZGMbPgm7MuQEqhchto6zROTWaUPkL6Gewunbjr5TezQGXhNgxIX5TuDuv AWyEoeQ2TS7nI5Luk3TEfPSqtDnfhrRgZoQKKSzP6INyZxSTuxdw6HeKubjnpzQd PrcPN7TMAwA= =CNd0 -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 15:58:53 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03831 for ; Tue, 16 Dec 2003 15:58:53 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKqKi12766 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 15:52:22 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBGKtLe03396 for ipseckey-outgoing; Tue, 16 Dec 2003 15:55:21 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKtJ203377 for ; Tue, 16 Dec 2003 15:55:19 -0500 (EST) Received: from thrintun.hactrn.net ([2002:183d:15e5:0:250:daff:fe82:1c39]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGKpfi12763 for ; Tue, 16 Dec 2003 15:51:41 -0500 (EST) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4619C18E4 for ; Tue, 16 Dec 2003 15:51:30 -0500 (EST) Date: Tue, 16 Dec 2003 15:51:30 -0500 From: Rob Austein To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] new draft -08 In-Reply-To: <24562.1071606440@marajade.sandelman.ottawa.on.ca> References: <20031215211928.E233E18EB@thrintun.hactrn.net> <24562.1071606440@marajade.sandelman.ottawa.on.ca> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20031216205130.4619C18E4@thrintun.hactrn.net> Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At Tue, 16 Dec 2003 15:27:20 -0500, Michael Richardson wrote: > > >>>>> "Rob" == Rob Austein writes: > >> Chairs. Reverse is clearly in scope here. Can you discuss with Bert? > > Rob> See "if there is a requirement for reverse records, this issue needs > Rob> to be explicitly discussed." > > Rob> The issue is not whether or not IPSECKEY belongs in the reverse tree > Rob> (everyone on this list knows that it does, and Bert now knows too, > Rob> because I told him). The issue is that the draft doesn't explain > Rob> this, it just assumes that the reader is already an expert on > Rob> opportunistic IPSEC and that this is therefore obvious. > > okay. > so what question does some text have to answer? > > Is it: > "where is the IPSECKEY RR found?" > > or: "is the reverse map the place to find IPSECKEY RR?" > > To me, the location of the record has a lot to do with the semantics of > the record. You need to know what question was being asked of DNS to know > if the record will be found there. "What is the usage model for the IPSECKEY RR, and why does this usage model imply that the reverse tree is where one would normally expect to find IPSECKEY RRs?" - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 16:05:56 2003 Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04658 for ; Tue, 16 Dec 2003 16:05:56 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGL2ui12813 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 16:02:59 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBGL5rQ04193 for ipseckey-outgoing; Tue, 16 Dec 2003 16:05:53 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGL5p204188 for ; Tue, 16 Dec 2003 16:05:51 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBGL2Di12807 for ; Tue, 16 Dec 2003 16:02:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04170; Tue, 16 Dec 2003 16:02:10 -0500 (EST) Message-Id: <200312162102.QAA04170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipseckey@sandelman.ca From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [IPSECKEY] I-D ACTION:draft-ietf-ipseckey-rr-08.txt Date: Tue, 16 Dec 2003 16:02:10 -0500 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPSEC KEYing information resource record Working Group of the IETF. Title : A method for storing IPsec keying material in DNS Author(s) : M. Richardson Filename : draft-ietf-ipseckey-rr-08.txt Pages : 16 Date : 2003-12-16 This document describes a new resource record for DNS. This record may be used to store public keys for use in IPsec systems. The record also includes provisions for indicating what IP address (v4 or v6) should be contacted when establishing an IPsec tunnel with the entity in question. This record replaces the functionality of the sub-type #1 of the KEY Resource Record, which has been obsoleted by RFC3445. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipseckey-rr-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipseckey-rr-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipseckey-rr-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-16154217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipseckey-rr-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipseckey-rr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-16154217.I-D@ietf.org> --OtherAccess-- --NextPart-- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 19:16:05 2003 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15821 for ; Tue, 16 Dec 2003 19:16:04 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBH0CNi13888 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 19:12:26 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBH0EdX18871 for ipseckey-outgoing; Tue, 16 Dec 2003 19:14:39 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [205.150.200.181]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBH0Ea218865 for ; Tue, 16 Dec 2003 19:14:36 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBH0Ari13863 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified FAIL) for ; Tue, 16 Dec 2003 19:10:59 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBH03jpK030560 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 16 Dec 2003 19:03:46 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hBH03jlB030556 for ; Tue, 16 Dec 2003 19:03:45 -0500 To: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] new draft -08 In-reply-to: Your message of "Tue, 16 Dec 2003 15:51:30 EST." <20031216205130.4619C18E4@thrintun.hactrn.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 16 Dec 2003 19:03:45 -0500 Message-ID: <30555.1071619425@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Rob" == Rob Austein writes: >> To me, the location of the record has a lot to do with the semantics >> of the record. You need to know what question was being asked of DNS >> to know if the record will be found there. Rob> "What is the usage model for the IPSECKEY RR, and why does this Rob> usage model imply that the reverse tree is where one would normally Rob> expect to find IPSECKEY RRs?" I don't see a way to answer that without writing down semantics. I thought we weren't going there. If we are, then this becomes the OE WG. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP9+dX4qHRg3pndX9AQH+zgQAtEQRt+BIn0+lMMwoTcwvMSFjtYmJazY2 EfR74ObFWjRktRAmqSAUCFxAkouLSMh0wRm165YbxXSzQb0/y/iaY1TzrSelxFEo WoF1F1AFRVIHw0jV3W6H0rxCN0xVWiNGrkcVk+Ipfw0jro26Tv3nYuBQ5POhOFF3 GdWvtawuCHc= =0QQQ -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed. From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Tue Dec 16 23:40:10 2003 Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24526 for ; Tue, 16 Dec 2003 23:40:05 -0500 (EST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBH4aVi15738 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified NO); Tue, 16 Dec 2003 23:36:34 -0500 (EST) Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) id hBH4cpE13330 for ipseckey-outgoing; Tue, 16 Dec 2003 23:38:51 -0500 (EST) Received: from fledge.watson.org (ak82hjs7hex92j@fledge.watson.org [204.156.12.50]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hBH4cm213324 for ; Tue, 16 Dec 2003 23:38:49 -0500 (EST) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id hBH4YgUd028197; Tue, 16 Dec 2003 23:34:42 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.12.10/8.12.10/Submit) with SMTP id hBH4YgLn028194; Tue, 16 Dec 2003 20:34:42 -0800 (PST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 16 Dec 2003 20:34:42 -0800 (PST) From: Sam Weiler To: Michael Richardson cc: ipseckey@sandelman.ca Subject: Re: [IPSECKEY] Re: ipseckey out of iesg In-Reply-To: <9564.1071096167@marajade.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca On Wed, 10 Dec 2003, Michael Richardson wrote: > > IESG> Thomas Narten: > > IESG> Intro (actually no part of the document) actually explains what this > IESG> RR is useful for. Consider a reader not familar with this effort who > IESG> would like to understand why this RR is needed, who uses it, and in > IESG> what situations its useful. For instance, it would be useful to > IESG> include an example of how the RR is expected to be used. I.e., it's > IESG> not until halfway down the document that one figures out the RR could > IESG> identify a gateway one connects to to create an IPsec tunnel to a > IESG> particular site. But the RR is keyed by an address. Why does one need > IESG> to map from the address to a gateay? I suspect 1 or 2 paragraphs > IESG> would to the trick. > IESG> > IESG> Specific comments: > IESG> > IESG> Abstract could be a lot better. Reading it, one doesn't really know > IESG> what this document is about or how the RR is used. > > Hmm. The purpose of this WG is to replace the functionality lost in the > RFC3445. 2535 doesn't say what the record is for either. So I feel that this > is really putting a higher standard on this record than there was in 2535. 2535 was also nearly unreadable. Perhaps we should hold ourselves to a higher standard. I don't think Thomas was asking us to codify anything -- he was asking for explanation. Let's give it to him. -- Sam - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.