[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[IPSECKEY] draft -01 changes
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPq3L4YqHRg3pndX9AQGbtwP+NS/Htuzb56O+jtmgNSda/LvMjQwVQPzi
KLSlau/9Rdy6jKxhCZiHNsLPTkajoOpvF45TI6n8TqPuE0oqYtEDpKbmpPPpTYvR
CD2sfw+tuqMqOe9WjOO/p/ONALGSijNDAiUiH9shDP16kgs55cPS68P2XE6mILve
Lx9CSTVhCIM=
=34C9
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.