From owner-ipseckey-outgoing@lox.sandelman.ottawa.on.ca Fri Jan 17 10:35:39 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id KAA17783 for ipseckey-outgoing; Fri, 17 Jan 2003 10:35:39 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id KAA17778 for ; Fri, 17 Jan 2003 10:35:38 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0HFUPQ16159 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 17 Jan 2003 10:30:31 -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 -4) with ESMTP id h0HFUJJP009711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 17 Jan 2003 10:30:20 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0HFUIWW009707 for ; Fri, 17 Jan 2003 10:30:18 -0500 Message-Id: <200301171530.h0HFUIWW009707@marajade.sandelman.ottawa.on.ca> To: ipseckey@lox.sandelman.ottawa.on.ca Subject: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Fri, 17 Jan 2003 14:37:34 +0100." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jan 2003 10:30:18 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jakob" == Jakob Schlyter writes: Jakob> On Fri, 17 Jan 2003 Internet-Drafts@ietf.org wrote: >> Title : A method for storing IPsec keying material in DNS >> Author(s) : M. Richardson >> Filename : draft-richardson-ipsec-rr-01.txt >> Pages : 6 >> Date : 2003-1-16 Jakob> may I suggest that IPSECKEY requests type 45 as SSHFP requests type 44. Jakob> I'm not saying that we should do IANAs work, but some syncronization could Jakob> be useful. Sure, I'll put that in -02. I was told that it is easiest if you "suggest" a value. Jakob> the file representation could be simplier. I propose that we use a integer Jakob> value for the public key algorithm instead of the literal 'RSA:'. other Jakob> than that, I like the RDATA format - it's simple and clean. I'm not crazy about magic numbers. The KEY presentation format's hex sub-type was already pretty obscure. Certainly, I would agree that use of an integer should be legal - you can't add new algorithm types easily otherwise. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPighiIqHRg3pndX9AQHuNAQAjfEtQ6gLfO3M1HVjuRJyjUVvS0bCjpgO rt6rY8w8KJi61yj14hryb7VLayfJVysWr8J97jTIj5o3vc3bzG3zj5PfdIp0DvcM kdS0AlmJwJtWMfCcM7hbyt3iVvtv3R0tS23rONGTMjiDtHX60fKnwKkqKNceyIP7 qtTTNHm+KyI= =nlgo -----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 Jan 21 14:50:43 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id OAA13226 for ipseckey-outgoing; Tue, 21 Jan 2003 14:50:43 -0500 (EST) Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id OAA13221 for ; Tue, 21 Jan 2003 14:50:41 -0500 (EST) Received: from ENGILL.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0LJfQW8028687 for ; Tue, 21 Jan 2003 14:41:28 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030121132048.0245da00@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 21 Jan 2003 14:44:53 -0500 To: ipseckey@lox.sandelman.ottawa.on.ca From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca This is the latest proposal, any comments. We do not have formal working group yet, but hopefully soon. Olafur >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-richardson-ipsec-rr-01.txt >Date: Fri, 17 Jan 2003 07:23:51 -0500 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : A method for storing IPsec keying material in DNS > Author(s) : M. Richardson > Filename : draft-richardson-ipsec-rr-01.txt > Pages : 6 > Date : 2003-1-16 > >This document describes a new resource record for DNS. This record >may be used to store public keys for use in IPsec systems. >This record replaces the functionality of the sub-type #1 of the KEY >Resource Record, which has been proposed to be obsoleted by [1]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-richardson-ipsec-rr-01.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-richardson-ipsec-rr-01.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-richardson-ipsec-rr-01.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. >Content-Type: text/plain >Content-ID: <2003-1-16141713.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-richardson-ipsec-rr-01.txt > > - 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 Jan 21 16:27:02 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id QAA14574 for ipseckey-outgoing; Tue, 21 Jan 2003 16:27:02 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id QAA14569 for ; Tue, 21 Jan 2003 16:27:01 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0LLLiQ15445 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 21 Jan 2003 16:21:50 -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 -4) with ESMTP id h0LLLclX003651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 21 Jan 2003 16:21:39 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0LLLcQN003648 for ; Tue, 21 Jan 2003 16:21:38 -0500 Message-Id: <200301212121.h0LLLcQN003648@marajade.sandelman.ottawa.on.ca> To: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Tue, 21 Jan 2003 14:44:53 EST." <5.1.1.6.2.20030121132048.0245da00@localhost> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Jan 2003 16:21:37 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- major change is that the field list are unmoveable: 3. IPSECKEY RDATA format The RDATA for an IPSECKEY RR consists of a precedence value, a public key (and algorithm type), and an optional gateway address. 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | gtype | algo | precedence | public key length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / public key / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| ~ gateway ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1 RDATA format - gateway type The gateway type ("gtype") field indicates the format of the gateway field. The gateway field may be absent. 0 No gateway field is present 1 A 32-bit IPv4 address is present in the gateway field, in section 2 A 128-bit IPv6 address is present in the gateway field. The data portion is an IPv6 address as described in section 3.2 of [4]. This is a 128-bit number in network byte order. 3 A fully qualified domain name is present in the gateway field. The name a %lt;domain-name%gt; encoded as described in section 3.3 of [4]. This field occupies the space until the end of the RDATA. 3.2 RDATA format - algo type The algorithm type ("algo") field indicates the type of key that is present in the public key field. Valid values are: 0 No key is present. 1 A RSA key is present, in the format defined in 2 A DSA key is present, in the format defined in 3.3 RDATA format - precedence This is an 8-bit precedence for this record. This is interpreted in a similar way to the PREFERENCE field described in section 3.3.9 of [3]. .. plus the key. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi253YqHRg3pndX9AQEzIQP/W705k684GPOFNYqvnOmSW1gU21gowXm0 jOV4PtJX4OgjLJ5E2fjVloxy+dWh0a2xrgOTAymwtyKckeL1Xe70gty6/dxDDEgK NAzmEUEkHkRodu+rin8CuVkrIJWJt7E2tjB47U7iJQ3c/bf/whZ+oEqLDVSf6/3F DHONpkeorEk= =ZO49 -----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 Jan 21 17:08:08 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id RAA15176 for ipseckey-outgoing; Tue, 21 Jan 2003 17:08:08 -0500 (EST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id RAA15171 for ; Tue, 21 Jan 2003 17:08:06 -0500 (EST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0LM2jEN092721 for ; Wed, 22 Jan 2003 09:02:47 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200301212202.h0LM2jEN092721@drugs.dv.isc.org> To: ipseckey@lox.sandelman.ottawa.on.ca From: Mark.Andrews@isc.org Subject: Re: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Tue, 21 Jan 2003 14:44:53 CDT." <5.1.1.6.2.20030121132048.0245da00@localhost> Date: Wed, 22 Jan 2003 09:02:45 +1100 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca There is no formal identifation of the gateway type in the master file format. This is bad as it could lead to the gateway field be misinterpreted. Is 1.2 a IP address or a unqualified domain name? As for IP addresses you should restrict them to dotted decimal quad (this implies no leading zeros). Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org - 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 Jan 21 18:52:43 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id SAA16397 for ipseckey-outgoing; Tue, 21 Jan 2003 18:52:43 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id SAA16391 for ; Tue, 21 Jan 2003 18:52:41 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0LNlOQ16006 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 21 Jan 2003 18:47:30 -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 -4) with ESMTP id h0LNlKlX007210 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 21 Jan 2003 18:47:21 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0LNlKcI007207 for ; Tue, 21 Jan 2003 18:47:20 -0500 Message-Id: <200301212347.h0LNlKcI007207@marajade.sandelman.ottawa.on.ca> To: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Wed, 22 Jan 2003 09:02:45 +1100." <200301212202.h0LM2jEN092721@drugs.dv.isc.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 21 Jan 2003 18:47:19 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Mark" == Mark Andrews writes: Mark> There is no formal identifation of the gateway type in the Mark> master file format. This is bad as it could lead to the Mark> gateway field be misinterpreted. You mean, for instance, that I could write: 192.139.46.38, meaning the a subdomain of this newly created ICANN TLD of ".38"? Or that it could somehow get confused into thinking that I really meant the IPv6 address ::192.139.46.38. I'm certainly open to additional syntax - do you have a suggestion? I'm also open to a more formal grammar for the presentation format. Oops, I thought that I actually used that wording. I think that I should, based upon other documents... oh wait, it says it one line up, but the document formatting of the draft is a little screwy there. Mark> Is 1.2 a IP address or a unqualified domain name? oh, took me a bit. I thought you meant section 1.2, and that this was a new question. I think that only fully qualified domain names should be given: 3 A fully qualified domain name is present in the gateway field. The name a %lt;domain-name%gt; encoded as described in section 3.3 of [4]. This field occupies the space until the end of the RDATA. In the presentation format, I can see that maybe it is reasonable to let the program reading it qualify it... do you have a suggestion on how we can distinguish things? Mark> As for IP addresses you should restrict them to dotted decimal Mark> quad (this implies no leading zeros). Sure. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi3b7oqHRg3pndX9AQGmuQQAjHjPsFCkUL2eR+ywdUR2QU4saNREmDE9 iX9Hx2Pf7VspATKXcMYzzFxdgy9ojnnvMa1KTEnCZky3b1+2k/7urBm2sGcDaBXj CDt4SjOnu95RleZhbXRubqJ1uvXvE4Dh9Eeh6QgetZ+nlgijPnlodOzGqF2ukikp sZcR5k9qMQM= =qDkx - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPi3cAoqHRg3pndX9AQFHUwP/TUGb6Hj5XsWcat2Hdk81+bqOu/2PNY0Y +/2TNpfnzmDikVGocqIiabhwcto/lw//EDGfgR8OqPGCSrUkppQApeGoUMFl8YZi nk7PtWUUfYNRLX4pSrDXVZwVVaf0G/z8IjI4gT/Ir+a8U7J2xkQr0M041eCRFmv9 S1rkYaHCr/c= =I3S9 -----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 Jan 21 19:28:36 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id TAA16942 for ipseckey-outgoing; Tue, 21 Jan 2003 19:28:36 -0500 (EST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id TAA16937 for ; Tue, 21 Jan 2003 19:28:32 -0500 (EST) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.12.6/8.12.6) with ESMTP id h0M0N7EN093413 for ; Wed, 22 Jan 2003 11:23:08 +1100 (EST) (envelope-from marka@drugs.dv.isc.org) Message-Id: <200301220023.h0M0N7EN093413@drugs.dv.isc.org> To: ipseckey@lox.sandelman.ottawa.on.ca From: Mark.Andrews@isc.org Subject: Re: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Tue, 21 Jan 2003 18:47:19 CDT." <200301212347.h0LNlKcI007207@marajade.sandelman.ottawa.on.ca> Date: Wed, 22 Jan 2003 11:23:07 +1100 Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Mark" == Mark Andrews writes: > Mark> There is no formal identifation of the gateway type in the > Mark> master file format. This is bad as it could lead to the > Mark> gateway field be misinterpreted. > > You mean, for instance, that I could write: 192.139.46.38, meaning the a > subdomain of this newly created ICANN TLD of ".38"? If the current $ORIGIN is example.net is "192.139.46.38" IPv4 address 192.139.46.38 or hostname 192.139.46.38.example.net? > Or that it could somehow get confused into thinking that I really meant the > IPv6 address ::192.139.46.38. You can't confuse IPv6 and IPv4 address literal with each other. However is ::192.139.46.38 the IPv6 address ::192.139.46.38 or ::192.139.46.38.example.net? > I'm certainly open to additional syntax - do you have a suggestion? > > I'm also open to a more formal grammar for the presentation format. Oops, I > thought that I actually used that wording. I think that I should, based upon > other documents... oh wait, it says it one line up, but the document > formatting of the draft is a little screwy there. > > Mark> Is 1.2 a IP address or a unqualified domain name? > > oh, took me a bit. I thought you meant section 1.2, and that this was a new > question. > I think that only fully qualified domain names should be given: > > 3 A fully qualified domain name is present in the gateway field. > The name a %lt;domain-name%gt; encoded as described in section 3.3 > of [4]. This field occupies the space until the end of the RDATA. > > In the presentation format, I can see that maybe it is reasonable to let > the program reading it qualify it... do you have a suggestion on how we can > distinguish things? No. "1.2" is a example of a IPv4 address, 1.2 is 1.0.0.2 when expressed as a dotted decimal quad. I was just after a example that would inject as much confusion as possible and succeeded. Actually after thinking about the unknown RR the domainname in the gateway field MUST always be *treated* as fully qualified and case MUST be preserved othewise the signatures will be wrong. This is a unknown RR for those serves that implement unknown RRs. Saying that the field is to be treated as fully qualified should result in the case being preserved but it doesn't hurt to reiterate the point. This still leave confusion with respect to tlds so there still needs to be flag word identifying the field. * -/D/A? (let the parser work out the address type) * -/D/A/AAAA? (tell the parser the address type) I would also prefer the fields in the presentation form to be in the same order is the wire form. Less confusion. Mark > Mark> As for IP addresses you should restrict them to dotted decimal > Mark> quad (this implies no leading zeros). > > Sure. > > ] ON HUMILITY: to err is human. To moo, bovine. | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architec > t[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive > r[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); > [ > - -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPi3b7oqHRg3pndX9AQGmuQQAjHjPsFCkUL2eR+ywdUR2QU4saNREmDE9 > iX9Hx2Pf7VspATKXcMYzzFxdgy9ojnnvMa1KTEnCZky3b1+2k/7urBm2sGcDaBXj > CDt4SjOnu95RleZhbXRubqJ1uvXvE4Dh9Eeh6QgetZ+nlgijPnlodOzGqF2ukikp > sZcR5k9qMQM= > =qDkx > - -----END PGP SIGNATURE----- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPi3cAoqHRg3pndX9AQFHUwP/TUGb6Hj5XsWcat2Hdk81+bqOu/2PNY0Y > +/2TNpfnzmDikVGocqIiabhwcto/lw//EDGfgR8OqPGCSrUkppQApeGoUMFl8YZi > nk7PtWUUfYNRLX4pSrDXVZwVVaf0G/z8IjI4gT/Ir+a8U7J2xkQr0M041eCRFmv9 > S1rkYaHCr/c= > =I3S9 > -----END PGP SIGNATURE----- > - > This is the IPSECKEY@sandelman.ca list. > Email to ipseckey-request@sandelman.ca to be removed. -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org - 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 Jan 22 11:34:49 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id LAA23327 for ipseckey-outgoing; Wed, 22 Jan 2003 11:34:49 -0500 (EST) Received: from ogud.com (pcp816081pcs.nrockv01.md.comcast.net [68.49.60.118]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id LAA23316 for ; Wed, 22 Jan 2003 11:34:48 -0500 (EST) Received: from ENGILL.ogud.com (gatt.dc.ogud.com [10.20.30.6]) by ogud.com (8.12.3/8.12.3) with ESMTP id h0MGPFW8031930; Wed, 22 Jan 2003 11:25:15 -0500 (EST) (envelope-from ogud@ogud.com) Message-Id: <5.1.1.6.2.20030122111815.01675e48@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 22 Jan 2003 11:29:00 -0500 To: Michael Richardson , ipseckey@lox.sandelman.ottawa.on.ca From: =?iso-8859-1?Q?=D3lafur?= =?iso-8859-1?Q?_Gu=F0mundsson?= Subject: Re: [IPSECKEY] Fwd: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-Reply-To: <200301212121.h0LLLcQN003648@marajade.sandelman.ottawa.on.c a> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca At 16:21 2003-01-21, Michael Richardson wrote: >-----BEGIN PGP SIGNED MESSAGE----- > > >major change is that the field list are unmoveable: > >3. IPSECKEY RDATA format > > The RDATA for an IPSECKEY RR consists of a precedence value, a public > key (and algorithm type), and an optional gateway address. > > 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | gtype | algo | precedence | public key length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | / > / public key > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > ~ gateway ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >3.1 RDATA format - gateway type > > The gateway type ("gtype") field indicates the format of the gateway > field. The gateway field may be absent. > > 0 No gateway field is present > > 1 A 32-bit IPv4 address is present in the gateway field, in section > > 2 A 128-bit IPv6 address is present in the gateway field. The data > portion is an IPv6 address as described in section 3.2 of [4]. > This is a 128-bit number in network byte order. > > 3 A fully qualified domain name is present in the gateway field. > The name a %lt;domain-name%gt; encoded as described in section 3.3 > of [4]. This field occupies the space until the end of the RDATA. This is much better, than the old versions but I think we can address both your wishes for extendibility and the wishes of DNS people to have a single "simple" format. How about express the gateway field always as a domain name, following are valid domain names. foo.bar. ; regular Domain name 123.12.1.10.in-addr.arpa ; IPv4 address 1.2.3.4.5.6.7.8.9.0.a.b.c.d.e.f.f.e.d.c.b.a.0.9.8.7.6.5.4.3.2.1.ip6.arpa. ; IPv6 address . ; No gateway The application needs to know extract the IPv4 and IPv6 addresses from these domain name. This is not a problem for new address types as they will fail in name lookup. This eliminates the gtype field and the presentation format only has to deal with a domain name. Olafur - 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 Fri Jan 31 01:01:19 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id BAA29378 for ipseckey-outgoing; Fri, 31 Jan 2003 01:01:19 -0500 (EST) Received: from ms0.nttdata.co.jp (ms0.nttdata.co.jp [163.135.193.231]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id BAA29373 for ; Fri, 31 Jan 2003 01:01:13 -0500 (EST) Received: from mail1.nttdata.co.jp ([163.135.10.21]) by ms0.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-01/14/03) with ESMTP id RAA10627; Fri, 31 Jan 2003 17:55:03 +0900 (JST) Received: from noanetmx0.noanet.nttdata.co.jp (localhost [127.0.0.1]) by mail1.nttdata.co.jp (8.9.3/3.7W-NTTDATA-TOP-11/07/02) with ESMTP id RAA09407; Fri, 31 Jan 2003 17:52:41 +0900 (JST) Received: from noanet01.noanet.nttdata.co.jp (noanet01.noanet.nttdata.co.jp [10.1.49.11]) by noanetmx0.noanet.nttdata.co.jp (8.9.3/3.7W) with ESMTP id RAA12443; Fri, 31 Jan 2003 17:54:06 +0900 (JST) Received: from nttdata.co.jp (10.8.131.50 [10.8.131.50]) by noanet01.noanet.nttdata.co.jp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DVMQ0C4N; Fri, 31 Jan 2003 17:55:02 +0900 Message-ID: <3E3A3A11.5080603@nttdata.co.jp> Date: Fri, 31 Jan 2003 17:55:45 +0900 From: Tatsuya Baba User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: ja MIME-Version: 1.0 To: Michael Richardson CC: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt References: <200301171530.h0HFUIWW009707@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca Hi, Just to clarify. In case both public key and gateway field in IPSECKEY RR exist, how should I interpret it? If the gateway field is the same as the owner name of RR, it should be considered as a security gateway. for example, owner name: "Security Gateway 1" public key: "bar" gateway : "Security Gateway 1" If both the public key and the gateway field exist, and the gateway name is not the same as the owner name of RR, should I consider that there will be nested SAs like following? Host 1 -------- Internet ----------- Security --- Host 2 | | Gateway1 | | | | | | -------Security Association 1---------- | | | ----------------Security Association 2--------------- owner name: "Host 2" public key: "foo" gateway : "Security Gateway 1" owner name: "Security Gateway 1" public key: "bar" gateway : "Security Gateway 1" (or none?) Regards. -- Tatsuya BABA babatt@nttdata.co.jp R&D Headquarters, NTT DATA CORPORATION - 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 Fri Jan 31 08:44:34 2003 Received: (from majordom@localhost) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) id IAA28742 for ipseckey-outgoing; Fri, 31 Jan 2003 08:41:44 -0500 (EST) Received: from noxmail.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [192.139.46.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id IAA28724 for ; Fri, 31 Jan 2003 08:41:37 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h0VGZUP16899 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 31 Jan 2003 11:35:37 -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 -4) with ESMTP id h0VGDvRQ003849 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 31 Jan 2003 11:13:58 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h0VGDurs003846; Fri, 31 Jan 2003 11:13:57 -0500 Message-Id: <200301311613.h0VGDurs003846@marajade.sandelman.ottawa.on.ca> To: Tatsuya Baba cc: ipseckey@lox.sandelman.ottawa.on.ca Subject: Re: [IPSECKEY] Re: I-D ACTION:draft-richardson-ipsec-rr-01.txt In-reply-to: Your message of "Fri, 31 Jan 2003 17:55:45 +0900." <3E3A3A11.5080603@nttdata.co.jp> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 31 Jan 2003 11:13:55 -0500 From: Michael Richardson Sender: owner-ipseckey@sandelman.ottawa.on.ca Precedence: bulk X-List: ipseckey@sandelman.ottawa.on.ca -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tatsuya" == Tatsuya Baba writes: Tatsuya> Hi, Tatsuya> Just to clarify. Tatsuya> In case both public key and gateway field in IPSECKEY RR exist, Tatsuya> how should I interpret it? The public key that is provided is the public key of the gateway. They appear in the same resource record to avoid a second round trip. If it does not appear, then a second round trip is necessary. This scenario may be useful when the public key has to change very frequently and updating all of the "client" records is too difficult. (to put it another way, this is intentionally not 3rd-normal form) Tatsuya> If the gateway field is the same as the owner name of RR, Tatsuya> it should be considered as a security gateway. Yes, in this case, the host is acting as its own gateway. Tatsuya> for example, Tatsuya> owner name: "Security Gateway 1" Tatsuya> public key: "bar" Tatsuya> gateway : "Security Gateway 1" Tatsuya> If both the public key and the gateway field exist, and the Tatsuya> gateway name is not the same as the owner name of RR, should Tatsuya> I consider that there will be nested SAs like following? Tatsuya> Host 1 -------- Internet ----------- Security --- Host 2 Tatsuya> | | Gateway1 | Tatsuya> | | | | Tatsuya> | -------Security Association 1---------- | Tatsuya> | | Tatsuya> ----------------Security Association 2--------------- There is no clear way for host-1 to set this up on its own. It would occur under this circumstance, assuming that the IPSECKEY RR is deployed in the reverse map as specified in OE. (It may get deployed elsewhere with different rules) Data: 1) owner-name: "Host 1" gateway: "Host 1" public-key: Host-1-key precedence: N/A 2) owner-name: "SG 1" gateway: "SG 1" pubic-key: SG-1-key 3) owner-name: "Host 2" gateway: "SG 1" public-key: SG-1-key precedence: 100 4) owner-name: "Host 2" gateway: "Host 2" public-key: Host-2-key precedence: 10 Host 1 looks up Host 2, finds records 3 and 4. It sees that #4 has the lowest precedence. Host-1 -------- Internet ----------- Security --- Host-2 -----------------------IKE---------------------> <--IKE---- At this point, SG1, would look up Host-1, see record #1, and init on its own: <----------------------IKE-------- (omitting pieces of phase 1 and 2) Host-1 then looks up the record the ID presented in phase 1, sees record #2, and uses the public key portion. Note that if SG-1 didn't want to act for itself, it would leave the gateway field empty. This doesn't matter for the moment. Host-1 can then authenticate SG1. Host-1 then sees the ID presented in phase 2, looks up records 3/4, sees that Host-2 has authorized SG-1 to act for it by record #3. The Host-1/SG-1 tunnel is setup. Host-1/Host-2 eventually retransmit their IKE packets. Depending upon how the IKE-bypass policy on Host-1 is done, the packet may go through the tunnel to SG-1 or not. The reply should definitely be in the tunnel. A second tunnel is setup from Host-1 to Host-2. It ought to be coaxial, resulting in the situation that you drew above. Let me draw it again: Host-1 -------- Internet ----------- Security --- Host-2 -----------------------IKE---------------------> <--IKE---- <----------------------IKE-------- -----------------------IKE-------> =======================IKE============>--------> <=====================================<--IKE---- *************************IP***********>==IP====> <************************IP***********<==IP===== (- clear. = one tunnel. * two tunnels) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPjqgvIqHRg3pndX9AQEk/QP/VWgt+sl90OwqHFz66im4OPuWgAYQs2yg 1zHOg9msvqRTvh9KAo5GKNendMI87gzF1rySt9Ih3cXLkRziAeTFeFDQVjjbSOBA wKKDh19F+QYYUyaTX3u16/bhtmikpYHwl2E8+03vgl3Ccp06BzEIcCzv8LPwUULn JEfqCHj1Wxo= =gC/q -----END PGP SIGNATURE----- - This is the IPSECKEY@sandelman.ca list. Email to ipseckey-request@sandelman.ca to be removed.