Opportunistic Encryption using the Internet Key Exchange (IKE)
RFC 4322

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-richardson-ipsec-opportunistic-18.txt 

The IESG has no problem with the publication of 'Opportunistic Encryption 
using The Internet Key Exchange (IKE)' 
<draft-richardson-ipsec-opportunistic-18.txt> as an Informational RFC. 

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=7384&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Steve Bellovin.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-18.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Ballot Text

Technical Summary
 
 This document describes how the Linux FreeS/WAN project used DNS TXT and KEY 
records to perform opportunistic IPsec encryption.  "Opportunistic encryption" 
permits secrecy without prearrangement between the parties concerned.
 
Working Group Summary
 
 Future opportunistic encryption systems will use the IPSECKEY DNS record 
instead, in compliance with RFC 3445.  This document describes the historic 
usage.

RFC Editor Note:
Section 1, second paragraph:
Old text:
   Note that 2.01 and beyond implements RFC3445
   [RFC3445], in a backward compatible way. A future document will
   detail compliance to RFC3445. For project information, see http://
   www.freeswan.org.

New text:
   Note that 2.01 and beyond implements [RFC3445] in a
   backward compatible way. A future document [IPSECKEY] will describe a
   variation that complies with RFC3445. For project information, see
   http://www.freeswan.org.

Section 2.2:
Old text:
   Multiple networks
   are necessary to adequately explain examples.

New text:
   Because multiple 
   networks are necessary to adequately explain the examples, [RFC3330]
   addresses are not used.   

Add the following non-normative references:
   [IPSECKEY] 
              Richardson, M., "A Method for Storing IPsec Keying
              Material in DNS", July 2004.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330, September
              2002.

 
Protocol Quality
 
 Steve Bellovin has reviewed this document for the IESG.

RFC Editor Note