Subject: [IPSECKEY] draft -01 changes

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Apr 2003 20:48:36 -0400

-----BEGIN PGP SIGNED MESSAGE-----

The CVS diff -u of the XML is attached below. 
I have asked the ID editor to publish the version that has change bars
as -01. http://www.sandelman.ca/SSW/ietf/ipsec/key/ if you can't
wait.

Summary of changes:
	1) added gateway-type field again.
	2) changed gateway field to have 3 formats: 4-byte IPv4,
	   16-byte IPv6, and wire-encode format.

	3) fixed examples
	4) added IPv6 example.

The IPv6 example had me stumped for awhile on formatting.... the
ip6.arpa. string is 73 characters long. How can I make this look nice.
I hope that my method of using $ORIGIN is meets with people's approval.

I used the 3ffe: address for www.kame.net until I can figure out if
there is an "example" space that I should really use.

=== cd /corp/projects/freeswan/sandbox-main/doc/src/
=== /usr/bin/cvs diff -u draft-richardson-ipsec-rr.xml

Index: draft-richardson-ipsec-rr.xml
===================================================================
RCS file: /freeswan/MASTER/freeswan/doc/src/draft-richardson-ipsec-rr.xml,v
retrieving revision 1.7
diff -u -r1.7 draft-richardson-ipsec-rr.xml
- --- draft-richardson-ipsec-rr.xml	30 Mar 2003 17:00:29 -0000	1.7
+++ draft-richardson-ipsec-rr.xml	29 Apr 2003 00:40:49 -0000
@@ -2,7 +2,7 @@
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 <?rfc toc="yes"?>
 
- -<rfc ipr="full2026" docName="draft-ipseckey-rr-00.txt">
+<rfc ipr="full2026" docName="draft-ietf-ipseckey-rr-01.txt">
 
 <front>
   <area>Security</area>
@@ -26,7 +26,7 @@
     </address>
   </author>
 
- -  <date month="March" year="2003" />
+  <date month="April" year="2003" />
 
 <abstract>
   <t>
@@ -36,7 +36,7 @@
 
 <t>
 This record replaces the functionality of the sub-type #1 of the KEY Resource
- -Record, which has been proposed to be obsoleted by
+Record, which has been proposed to be obsoleted by RFC3445
 <xref target="RFC3445" />.
 </t>
 </abstract>
@@ -59,7 +59,7 @@
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
       "OPTIONAL" in this document are to be interpreted as described in
- -      <xref target="RFC2119" />.
+      RFC2119 <xref target="RFC2119" />.
 </t>
 
 <t>
@@ -96,8 +96,8 @@
     0                   1                   2                   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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- -   |  precedence   |  algorithm    |         gateway               |
- -   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+   |  precedence   | gateway type  |  algorithm  |     gateway     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
    ~                            gateway                            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               /
@@ -111,16 +111,16 @@
 <t>
 This is an 8-bit precedence for this record. This is interpreted in
 the same way as the PREFERENCE field described in section
- -3.3.9 of <xref target="RFC1035" />. 
+3.3.9 of RFC1035 <xref target="RFC1035" />. 
 </t>
 </section>
 
 <section title="RDATA format - algorithm type">
 <t>
- -aThe algorithm type field indicates the type of key that is
+The algorithm field indicates the type of key that is
 present in the public key field. A positive number, larger than 0 identifies
 an algorithm type. The following values, which have been previously
- -defined by IANA are useful (<xref target="RFC2535" />).
+defined by IANA are useful (see RFC2535 <xref target="RFC2535" />).
 </t>
 <t>
 A value of 0 indicates that no key is present.
@@ -129,8 +129,27 @@
 <t>
 The following values defined by IANA are useful:
   <list style="hanging">
- -  <t hangText="3">A DSA key is present, in the format defined in <xref target="RFC2536" /></t>
- -  <t hangText="5">A RSA key is present, in the format defined in <xref target="RFC3110" /></t>
+  <t hangText="3">A DSA key is present, in the format defined in RFC2536 <xref target="RFC2536" /></t>
+  <t hangText="5">A RSA key is present, in the format defined in RFC3110 <xref target="RFC3110" /></t>
+  </list>
+</t>
+
+</section>
+
+<section title="RDATA format - gateway type">
+<t>
+The gateway type field indicates the format of the gateway that
+is stored in the gateway field.
+</t>
+
+<t>
+The following values are defined:
+  <list style="hanging">
+  <t hangText="0">No gateway is present</t>
+  <t hangText="1">A 4-byte IPv4 address is present</t>
+  <t hangText="2">A 16-byte IPv6 address is present</t>
+  <t hangText="3">A wire-encoded domain-name is present. The wire-encoded
+format is self-describing, so the length is implicit. </t>
   </list>
 </t>
 
@@ -140,22 +159,24 @@
 <t>
 The gateway field indicates a gateway to which an IPsec tunnel may be
 created in order to reach the entity holding this resource record.
- -The gateway field is a normal wire-encoded domain name (section 3.3 of
- -<xref target="RFC1035" />).
 </t>
 <t>
- -If no gateway is to be represented, then a null domain name MUST be present.
+There are three formats:
 </t>
 
 <t>
- -It is a simple fully qualified domain name (FQDN).
- -IP version 4 and IP version 6 addresses may be represented using the reverse
- -name format, from in-addr.arpa. and ip6.arpa.  
+A 32-bit IPv4 address is present in the gateway field, as defined in section 3.4.1 of
+<xref target="RFC1035">RFC1035</xref>.  This is a 32-bit number in network byte order.
+</t>
+
+<t>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
+<xref target="RFC1886">RFC1886</xref>. This is a 128-bit number in network byte order.
 </t>
 
 <t>
- -For instance, the IP version 4 address 192.0.1.2 is represented as the
- -domain name 2.1.0.192.in-addr.arpa.
+The gateway field is a normal wire-encoded domain name (section 3.3 of
+RFC1035 <xref target="RFC1035" />).
 </t>
 
 </section>
@@ -164,7 +185,7 @@
 <t>
 If the algorithm type has the value 5 then public key portion contains an
 RSA public key, encoded as described in secion 2 of
- -<xref target="RFC3110" />. 
+RFC3110 <xref target="RFC3110" />. 
 </t>
 
 <t>
@@ -190,7 +211,7 @@
 <section title="RDATA format - DSA public key">
 <t>
 If the algorithm type has the value 3, then public key portion contains an
- -DSA public key, encoded as described in <xref target="RFC2536"/>.
+DSA public key, encoded as described in RFC2536 <xref target="RFC2536"/>.
 </t>
 
 </section>
@@ -204,12 +225,16 @@
 <section title="Representation of IPSECKEY RRs">
 <t>
    IPSECKEY RRs may appear as lines in a zone data master file.
- -   The precedence, algorithm and gateway fields are REQUIRED. There
- -   base64 encoded public key block is OPTIONAL.
+   The precedence, gateway type and algorithm and gateway fields are REQUIRED.
+   There base64 encoded public key block is OPTIONAL.
 </t>
 <t>
    If no gateway is to be indicated, then the root (".") SHOULD be used. 
 </t>
+<artwork><![CDATA[
+IN     IPSECKEY ( precedence gateway-type algorithm
+                  gateway base64-encoded-public-key )
+]]></artwork>
 </section>
 
 <section title="Examples">
@@ -217,8 +242,8 @@
 An example of a node 192.2.0.38 that will accept IPsec tunnels on its
 own behalf.
 <artwork><![CDATA[
- -38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
- -                 38.0.2.192.in-addr.arpa.
+38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5 1
+                 192.2.0.38
                  AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
                  Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 
                  9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 
@@ -232,7 +257,7 @@
 <t> 
 An example of a node, 192.2.0.38 that has published its key only.
 <artwork><![CDATA[
- -38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 5
                  .
                  AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
                  Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 
@@ -248,8 +273,8 @@
 An example of a node, 192.2.0.38 that has delegated authority to the node
 192.2.3.5.
 <artwork><![CDATA[
- -38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
- -                 5.3.2.192.in-addr.arpa.
+38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5 1
+                 192.2.3.5
                  AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
                  Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 
                  9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 
@@ -264,7 +289,7 @@
 An example of a node, 192.1.0.38 that has delegated authority to the node
 with the identity "mygateway.example.com".
 <artwork><![CDATA[
- -38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 5
                  mygateway.example.com.
                  AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
                  Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 
@@ -276,11 +301,45 @@
 ]]></artwork>
 </t>
 
+<t> 
+An example of a node, 3ffe:501:4819:2000:210:f3ff:fe03:4d0 that has
+delegated authority to the node 
+<artwork><![CDATA[
+$ORIGIN 0.0.0.2.9.1.8.4.1.0.5.0.e.f.f.3.ip6.int.
+0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 5
+                 2001:200:0:8002::2000:1
+                 AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+                 Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La 
+                 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 
+                 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC 
+                 MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 
+                 cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 
+                 fejrfi1H )
+]]></artwork>
+</t>
+
 </section>
 </section>
 
 <section title="Security Considerations">
 <t>
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC2407)
+   <xref target="RFC2407" />.
+</t>
+
+<t>
+   Implementations of DNS servers and resolvers SHOULD take care to make
+   sure that the keying material is delivered intact to the end application.
+   The use of DNSSEC to provide end-to-end integrity protection is strongly
+   encouraged.  
+</t>
+
+<t>
+   The semantics of this record is outside of the scope of this document,
+   so no advice for users of this information is provided. Any user of this
+   resource record MUST carefully document their trust model, and why the 
+   trust model of DNSSEC is appropriate.
 </t>
 </section>
 
@@ -298,9 +357,9 @@
 
 <section title="Acknowledgments">
 <t>
- -<!-- Paul will review document.
- -     Olafur will write code.
- --->
+My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig,
+and Ólafur Guðmundsson who reviewed this document carefully.
+Additional thanks to Ólafur Guðmundsson for a reference implementation.
 </t>
 </section>
 
@@ -316,7 +375,9 @@
 </references>
 
 <references title="Non-normative references">
+<?rfc include="reference.RFC.1886" ?>
 <?rfc include="reference.RFC.2119" ?>
+<?rfc include="reference.RFC.2407" ?>
 <?rfc include="reference.RFC.2535" ?>
 <?rfc include="reference.RFC.2536" ?>
 <?rfc include="reference.RFC.3110" ?>
=== Exit status: 1
-
This is the [email-masked] list.
Email to [email-masked] to be removed.