

Network Working Group                                      M. Richardson
Internet-Draft                                                       SSW
Expires: April 1, 2002                                     D. Redelmeier
                                                                  Mimosa
                                                              H. Spencer
                                                              SP Systems
                                                            October 2001


          A method for doing opportunistic encryption with IKE
              draft-richardson-ipsec-opportunistic-03.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 1, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.














Richardson, et al.        Expires April 1, 2002                 [Page 1]

Internet-Draft                opportunistic                 October 2001


Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   5
   1.1    Types of network traffic . . . . . . . . . . . . . . . . .   5
   1.2    Authentication of Opportunistic Encryption . . . . . . . .   6
   2.     Terminology and Reference diagrams . . . . . . . . . . . .   8
   2.1    Reference diagram  . . . . . . . . . . . . . . . . . . . .   8
   2.2    Terminology  . . . . . . . . . . . . . . . . . . . . . . .   8
   3.     Brief overview of method used  . . . . . . . . . . . . . .  10
   3.1    Plain-text usage (permit policy) . . . . . . . . . . . . .  10
   3.2    Opportunistic Encryption . . . . . . . . . . . . . . . . .  10
   4.     Detailed description of process  . . . . . . . . . . . . .  13
   4.1    (5) IPsec packet interception  . . . . . . . . . . . . . .  13
   4.2    (5B) DNS lookup for TXT record . . . . . . . . . . . . . .  13
   4.3    (5C) DNS returns TXT record(s) . . . . . . . . . . . . . .  13
   4.4    (5D) Initial IKE Main Mode Packet goes out . . . . . . . .  14
   4.5    (5E1) Message 2 of phase 1 exchange  . . . . . . . . . . .  14
   4.6    (5E2) Message 3 of phase 1 exchange  . . . . . . . . . . .  14
   4.7    (5E3) Message 4 of phase 1 exchange  . . . . . . . . . . .  14
   4.8    (5E4) Message 5 of phase 1 exchange  . . . . . . . . . . .  14
   4.9    (5F1) Responder lookup of initiator key  . . . . . . . . .  14
   4.10   (5F2) DNS replies with public key of initiator . . . . . .  14
   4.11   (5E5) Responder replies with ID and authentication . . . .  14
   4.12   (5G) IKE phase 2 . . . . . . . . . . . . . . . . . . . . .  14
   4.12.1 (5G1) Initiator proposes tunnel  . . . . . . . . . . . . .  15
   4.12.2 (5G2) Responder determines initiator's authority . . . . .  15
   4.12.3 (5G3) DNS replies with TXT record  . . . . . . . . . . . .  15
   4.12.4 (5G4) Responder agrees to proposal . . . . . . . . . . . .  15
   4.13   (6) IPsec succeeds, sets up tunnel for communication
          between Alice and Bob  . . . . . . . . . . . . . . . . . .  15
   4.14   (9) SG-B already has tunnel up with G1, uses it  . . . . .  15
   5.     Renewal and Teardown . . . . . . . . . . . . . . . . . . .  16
   5.1    Aging  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   5.2    Teardown and Cleanup . . . . . . . . . . . . . . . . . . .  17
   6.     Impacts on IKE . . . . . . . . . . . . . . . . . . . . . .  18
   6.1    ISAKMP/IKE protocol  . . . . . . . . . . . . . . . . . . .  18
   6.2    Gateway discovery process  . . . . . . . . . . . . . . . .  18
   6.3    Self identification  . . . . . . . . . . . . . . . . . . .  18
   6.4    Public key Retrieval process . . . . . . . . . . . . . . .  19
   6.5    Interactions with DNSSEC . . . . . . . . . . . . . . . . .  19
   6.6    Recommended proposal types . . . . . . . . . . . . . . . .  19
   6.6.1  Phase 1 IDs  . . . . . . . . . . . . . . . . . . . . . . .  19
   6.6.2  Phase 2 IDs  . . . . . . . . . . . . . . . . . . . . . . .  19
   7.     DNS issues . . . . . . . . . . . . . . . . . . . . . . . .  21
   7.1    Use of KEY record  . . . . . . . . . . . . . . . . . . . .  21
   7.2    Use of TXT delegation record . . . . . . . . . . . . . . .  21
   7.2.1  Choice of TXT record . . . . . . . . . . . . . . . . . . .  22
   7.3    Use of FQDN IDs  . . . . . . . . . . . . . . . . . . . . .  23



Richardson, et al.        Expires April 1, 2002                 [Page 2]

Internet-Draft                opportunistic                 October 2001


   8.     Network Address Translation interaction  . . . . . . . . .  24
   8.1    Colocated NAT/NAPT . . . . . . . . . . . . . . . . . . . .  24
   8.2    SG-A behind NAT/NAPT . . . . . . . . . . . . . . . . . . .  24
   8.3    Bob is behind a NAT/NAPT . . . . . . . . . . . . . . . . .  24
   9.     Host implementations . . . . . . . . . . . . . . . . . . .  26
   10.    Multihoming  . . . . . . . . . . . . . . . . . . . . . . .  27
   11.    Failure modes  . . . . . . . . . . . . . . . . . . . . . .  29
   11.1   DNS failures . . . . . . . . . . . . . . . . . . . . . . .  29
   11.2   DNS configured, IKE failures . . . . . . . . . . . . . . .  29
   11.3   System reboots . . . . . . . . . . . . . . . . . . . . . .  29
   12.    Unresolved issues  . . . . . . . . . . . . . . . . . . . .  31
   12.1   Control of reverse DNS . . . . . . . . . . . . . . . . . .  31
   13.    Security Considerations  . . . . . . . . . . . . . . . . .  32
   13.1   Configured vs Opportunistic Tunnels  . . . . . . . . . . .  32
   13.2   Firewalls vs Opportunistic Tunnels . . . . . . . . . . . .  32
   13.3   Denial of Service  . . . . . . . . . . . . . . . . . . . .  33
   14.    IANA Considerations  . . . . . . . . . . . . . . . . . . .  34
          References . . . . . . . . . . . . . . . . . . . . . . . .  35
          Authors' Addresses . . . . . . . . . . . . . . . . . . . .  35
          Full Copyright Statement . . . . . . . . . . . . . . . . .  37































Richardson, et al.        Expires April 1, 2002                 [Page 3]

Internet-Draft                opportunistic                 October 2001


Abstract

   This document discusses a method used by the Linux FreeS/WAN project
   to opportunistically encrypt traffic between peers without specific
   pre-arrangement.  It describes the infrastructure necessary to
   support this configuration.  Opportunistic Encryption (OE) provides
   major simplifications of typical configurations, as it scales
   linearly rather than quadratically in the number of systems involved.

   There are naturally some risks, which are described.

   This document is offered up as an Informational RFC.







































Richardson, et al.        Expires April 1, 2002                 [Page 4]

Internet-Draft                opportunistic                 October 2001


1. Introduction

   The Linux FreeS/WAN project started in 1996.  Its goal was to secure
   5% of the Internet traffic against passive wire-tapping, increasing
   over time to 80%.

   The Internet Architecture Board (IAB) and Internet Engineering
   Steering Group have taken a strong  stand  that the Internet should
   use powerful encryption to provide security and privacy.  This
   project attempts to put this policy into practice by providing
   practical means to implement them.

   This idea does not originate with this project; lots of people have
   been working on it for years.  The encryption protocols for these
   boxes are called IPsec (IP Security).  They have been developed by
   the IP Security Working Group of the Internet Engineering Task Force,
   and became a standard in 1999.  See RFC 2401 [3].

   The project believes that these protocols are the best chance to do
   that, because they can be deployed very easily, without changing
   hardware or software or retraining of users.

   The use of "opportunistic encryption" offers the "fax effect".  As
   each person installs one for their own use, it becomes more valuable
   for their neighbors to install one too, because there's one more
   person to use it with.  The software automatically notices each newly
   installed box, and doesn't require a network administrator to
   reconfigure it.

   This document describes the infrastructure needed to support this
   effort.

   The term S/WAN is a trademark of RSA Data Systems, and is used with
   permission by this project.

1.1 Types of network traffic

   To aid in understand the relationship between security processing and
   IPsec we divide network traffic into four categories:

   deny networks to which traffic is always forbidden

   permit networks to which traffic in the clear is desired

   opportunistic tunnel networks to which encryption should be done if
      possible, but sent in the clear otherwise

   configured tunnel networks to which encryption must be done, and



Richardson, et al.        Expires April 1, 2002                 [Page 5]

Internet-Draft                opportunistic                 October 2001


      never sent in the clear

   This document describes the third category.  The first two categories
   are provided by traditional firewall devices.  The fourth category is
   presently the offering of many Virtual Private Network (VPN) devices.

   Category one, denied traffic by IP address, requires no
   authentication.

   Category two, permitted traffic by IP address, requires no
   authentication.  This is the normal default on the Internet.

   Category four, encrypt traffic or drop it, requires authentication of
   the end points.  As the number of end points is typically bound and
   is typically under the authority of a single authority, arranging for
   exchange of authentication material, while difficult, does not
   require any new technology.  The mechanism described here provide an
   additional way to provide the authentication materials, notably a
   public key method that does not require deployment of an X.509 based
   infrastructure.

1.2 Authentication of Opportunistic Encryption

   Opportunistic encryption involves creating tunnels with other nodes
   with are essentially strangers.  This is done without any prior
   bilateral arrangement.  There is therefore the difficult question of
   how does one know who one is talking to.

   One answer is that one does not know who one is talking to.  No
   useful authentication can be done, so do not even try.  This mode of
   operation has been given the name "anonymous encryption".

   Although a useful mode, it is not the goal of this project.  It is a
   useful starting point, but the system should permit additional layers
   of trust to be built upon this system.  In the described system, the
   anonymous encryption case is what results without DNSSEC.  Were
   anonymous encryption the end goal, simpler methods are available to
   achieve this goal.

   However, an essential premise of building private connections with
   strangers is that packets received through these opportunist tunnels
   packets are no more special than packets that arrived in the clear.

   Unlike in a VPN scenario, these packets should not be given any
   special exceptions when it comes to auditing, further authentication
   or firewalling.

   On the outbound side, when initiating opportunistic encryption, it



Richardson, et al.        Expires April 1, 2002                 [Page 6]

Internet-Draft                opportunistic                 October 2001


   becomes a local matter what to do if one fails to setup a tunnel.  It
   may be that the packet goes out in the clear, or it may be dropped.
   This is a local configuration matter.

   In sum, we gain wider privacy (for the Internet at large) at minimal
   cost: the cost is the need to reassess assumptions about the
   relationship between IPsec authentication and further local access
   control.

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [2]







































Richardson, et al.        Expires April 1, 2002                 [Page 7]

Internet-Draft                opportunistic                 October 2001


2. Terminology and Reference diagrams

2.1 Reference diagram

   The following network diagram is used in the rest of this document as
   the canonical diagram

                         [Q]  [R]          AS2
                          .    .
     [A]----+----[SG-A]...+....+....[SG-B]-------[B]
        AS1 |             . PI .
     [D]----+----[SG-D]...+    +....[C]    AS3



   In this diagram, there are four end-nodes: A, B, C and D.  There are
   three gateways, SG-A, SG-B, SG-D.  A, D, SG-A and SG-D are part of
   the same administrative authority.  SG-A and SG-D are on two
   different exit paths from organization 1.  SG-B/B is an independent
   organizations.  Nodes Q and R are nodes that are on the Internet.  PI
   is the Public Internet ("The Wild").

2.2 Terminology

   The following terminology is used in this document:

   security gateway: a system that performs IPsec tunnel mode
      encapsulation/decapsulation.  [Gx] in the diagram

   Alice: node [A] in the diagram.  When an IP address is needed, this
      is 192.1.0.65.

   Bob: node [B] in the diagram.  When an IP address is needed, this is
      192.2.0.66.

   Carol: node [C] in the diagram.  When an IP address is needed, this
      is 192.1.1.67.

   Dave: node [D] in the diagram.  When an IP address is needed, this is
      192.3.0.68

   SG-A Alice's security gateway.  Internally it is 192.1.0.1,
      externally it is 192.1.1.4.

   SG-B Bob's security gateway.  Internally it is 192.1.2.1, externally
      it is 192.1.1.5.

   SG-D Dave's security gateway.  Also Alice's backup security gateway.



Richardson, et al.        Expires April 1, 2002                 [Page 8]

Internet-Draft                opportunistic                 October 2001


      Internally it is 192.3.0.1, externally it is 192.1.1.6.

   - a single dash represents clear-text packets

   = an equals sign represents phase 2 (IPsec) cipher-text packets

   # a hash sign represents phase 1 (IKE) cipher-text packets

   .  a period represents an untrusted network of unknown type

   configured tunnel: Contrast with opportunistic tunnel.  A tunnel that
      is directly/deliberately/hand configured on participating
      gateways.  Configured tunnel are typically given a higher level of
      trust than opportunistic tunnels.

   road warrior tunnel: a configured tunnel connecting one node with a
      fixed IP address and one node with a variable IP address.  A road
      warrior (RW) connection must be initiated by the variable node,
      since the fixed node does not know what the address for the "road
      warrior" currently is.

   phase 1 SA an ISAKMP/IKE security association

   phase 2 SA an IPsec security association

   tunnel another term for a set of phase 2 SA

   NAT Network Address Translation (see [11])

   NAPT Network Address and Port Translation (see [11])

   anonymous encryption: The process of encrypting a session without any
      knowledge of who the receiving party is.  That is, no
      authentication of identities is done.

   opportunistic encryption: The process of encrypting a session with
      knowledge of who the receiving party is.

   lifetime: The negotiated period in seconds (bytes or packets) which a
      security association will remain alive before needing to be
      rekeyed.

    The effective time which a security association remains useful.  A
      security association with a lifespan shorter than its lifetime
      would be removed when no longer needed.  A security association
      with a lifespan longer than its lifetime would need to be rekeyed
      one or more times.




Richardson, et al.        Expires April 1, 2002                 [Page 9]

Internet-Draft                opportunistic                 October 2001


3. Brief overview of method used

3.1 Plain-text usage (permit policy)

     Alice         Gate1      DNS      Gate2           Bob
      (1)
       ------(2)-------------->
       <-----(3)---------------
      (4)----(5)----->----------(6)------>------(7)----->
       <----(10)-----<----------(9)------<------(8)------
      (11)----------->----------(12)----->-------------->
       <-------------<-------------------<---------------

   Alice wants to send a packet to Bob, say a ping packet.  Without the
   presence of opportunistic encryptors, the following events occur:

   (1) Human or application 'clicks' with a name

   (2) Application looks up name in DNS to get IP address

   (3) Resolver returns A record to application

   (4) Application starts a TCP session or UDP session, OS sends packet

   (5) Packet is seen at first gateway from Alice  (SG-A)

   (6) Packet is seen at last gateway before Bob   (SG-B)

   (7) First packet from Alice is seen by Bob

   (8) First return packet is sent by Bob

   (9) Packet is seen at Bob's gateway

   (10) Packet is seen at Alice's gateway

   (11) OS hands packet to application, Alice sends another packet

   (12) a second packet traverses the Internet


3.2 Opportunistic Encryption

   In the presence of properly configured opportunistic encryptors, the
   event list is extended.






Richardson, et al.        Expires April 1, 2002                [Page 10]

Internet-Draft                opportunistic                 October 2001


     Alice         SGate1     DNS      SGate2          Bob
      (1)
       ------(2)-------------->
       <-----(3)---------------
      (4)----(5)----->+
                     ----(5B)->
                     <---(5C)--
                     -------------(5D)--->
                     <------------(5E1)---
                     #############(5E2)##>
                     <############(5E3)###
                     #############(5E4)##>
                     <############(5E5)###
                              <----(5F1)--
                              -----(5F2)->
                     #############(5G1)##>
                              <----(5G2)--
                              -----(5G3)->
                     <############(5G4)###
                      ============(6)====>------(7)----->
       <-----(10)----<==========(9)======<------(8)------
      (11)----------->==========(12)=====>-------------->
       <-------------<===================<---------------

   (1) Human or application clicks with a name

   (2) Application initiates DNS mapping.

   (3) resolver returns A record to application

   (4) Application starts a TCP session or UDP

   (5) SG (host or SG) sees packet to target, buffers it.

   (5B) SG asks the DNS for TXT record

   (5C) DNS returns TXT record(s)

   (5D) Initial IKE Main Mode Packet goes out

   (5E) IKE ISAKMP phase 1 succeeds

   (5F) SG-B asks the DNS for TXT record to prove SG-A agent for Alice

   (5G) IKE phase 2 negotiation

   (5H) IPsec succeeds, sets up tunnel for communication between Alice
      and Bob



Richardson, et al.        Expires April 1, 2002                [Page 11]

Internet-Draft                opportunistic                 October 2001


   (6) buffered packet is sent by SG-A

   (7) packet is received by SG-B, and decrypted, sent to Bob

   (8) Bob replies, packet is seen by SG-B

   (9) SG-B already has tunnel up with SG-A, uses it

   (10) SG-A decrypts packet and give it to Alice

   (11) Alice receives packet.  Sends new packet to Bob

   (12) SG-A gets second packet, sees that tunnel is up, uses it






































Richardson, et al.        Expires April 1, 2002                [Page 12]

Internet-Draft                opportunistic                 October 2001


4. Detailed description of process

   For the purposes of this section, we will describe on the changes
   that occur between Figure 2 and Figure 3.  This means time points 5,
   6, 7, 9 and 10.

4.1 (5) IPsec packet interception

   At point (5), the Security Gateway intercepts the packet, as it would
   with any configured tunnel.  The packet is buffered.  If there is
   already a buffered packet that matches the same selectors, the new
   packet is dropped.  There are no differences from regular IPsec
   processing here.

   At the IPsec SPD level, opportunistic encryption may be considered as
   being simply a per-host keyed (see [3] section 4.4.1) tunnel to
   0.0.0.0/0.

   Should the prospective responder not have OE configured (or: not
   respond to attempts to establish a phase 1 SA), the initiator MAY
   create an SPD entry to permit clear-text packets to this machine.
   This is a local policy decision.  In the configured tunnel situation
   the packet would never be sent in the clear.

4.2 (5B) DNS lookup for TXT record

   The IKE daemon, having been informed of the need for a tunnel between
   Alice and Bob performs a DNS lookup.  This DNS lookup serves two
   purposes:

   1.  to find the public key of the responding gateway (SG-B)

   2.  to find out the IP address of this gateway (SG-B)

   A reverse lookup is done on the IP address of Bob, mapped into the
   in-addr.arpa in the usual way.

   The lookup requests TXT records.  These are interpreted as described
   in Section 7.2.

4.3 (5C) DNS returns TXT record(s)

   Given the IP address of the gateway information, SG-A is now in a
   position to create a phase 1 SA with SG-B.

   For the example above, the returned record might contain:

   X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==



Richardson, et al.        Expires April 1, 2002                [Page 13]

Internet-Draft                opportunistic                 October 2001


    with SG-B's IP address and public key listed.

4.4 (5D) Initial IKE Main Mode Packet goes out

   SG-A sends the initial ISAKMP message, with proposals, see Section
   6.6.1.

4.5 (5E1) Message 2 of phase 1 exchange

   SG-B receives the message and responds with its choice of proposals
   for the phase 1 SA.

4.6 (5E2) Message 3 of phase 1 exchange

   SG-A sends a Diffie-Hellman exponent.

4.7 (5E3) Message 4 of phase 1 exchange

   SG-B responds with a Diffie-Hellman exponent.

4.8 (5E4) Message 5 of phase 1 exchange

   SG-A uses the phase 1 SA to send its identity under encryption.  The
   choice of identity is discussed in Section 6.6.1.

4.9 (5F1) Responder lookup of initiator key

   Security Gateway 2 asks DNS for the public key of the initiator.
   This is done by asking for a KEY record by IP address in the reverse
   map.  That is, a KEY resource record is queried for 4.1.1.192.in-
   addr.arpa (recall that SG-A's external address is 192.1.1.4) The
   resulting public key is used to authenticate the initiator.  See
   Section 7.1 for further details.

4.10 (5F2) DNS replies with public key of initiator

   The format of the KEY record is described in Section 7.1.

   The format of the TXT record that is returned is described in Section
   7.2.

4.11 (5E5) Responder replies with ID and authentication

   SG-B sends its ID along with authentication material.

4.12 (5G) IKE phase 2





Richardson, et al.        Expires April 1, 2002                [Page 14]

Internet-Draft                opportunistic                 October 2001


4.12.1 (5G1) Initiator proposes tunnel

   Having established mutually agreeable authentications (via KEY) and
   authorizations (via TXT), SG-A proposes to create an IPsec tunnel for
   packets transiting from Alice to Bob.  This tunnel is established for
   only the A/B combination, not for any subnets that may be behind SG-A
   and SG-B.

4.12.2 (5G2) Responder determines initiator's authority

   While the identity of the SG-A has been established, its authority to
   speak for Alice has not yet been confirmed.  This is done by doing a
   reverse lookup on A's address for a TXT record.  \

4.12.3 (5G3) DNS replies with TXT record

   The returned key and IP address should match that of SG-A.

4.12.4 (5G4) Responder agrees to proposal

   Should additional communication occur between, for instance, D and B
   via SG-A and SG-B, a new tunnel (phase 2 SA) would be established.
   The phase 1 SA may be reusable.

4.13 (6) IPsec succeeds, sets up tunnel for communication between Alice
     and Bob

   The packet which was saved at step (5) is sent through the newly
   created tunnel to SG-B.  Bob receives it at (7) and replies at (8).

4.14 (9) SG-B already has tunnel up with G1, uses it

   At (9), SG-B has already established an SPD entry mapping Bob->Alice
   via a tunnel, so this tunnel is simply applied.  The packet is
   encrypted to SG-A, decrypted by SG-A and passed to Alice at (10).
















Richardson, et al.        Expires April 1, 2002                [Page 15]

Internet-Draft                opportunistic                 October 2001


5. Renewal and Teardown

5.1 Aging

   When to tear tunnels down is a bit problematic, but as an a
   potentially unbounded number of them may be created,  a mechanism to
   remove them is required.

   There are two methods in which the tunnel may be removed: by expiring
   or with explicit deletion.

   Explicit deletion is done with an IKE Delete message.  To do this
   requires that both ends maintain the phase 1 ISAKMP SA, as the
   deletes must be authenticated.  An implementation which refuses to
   maintain this SA will be unable to use this method.

   In the expiry method, the tunnel is simply allowed by the IKE daemon
   to expire rather than rekeying it.

   Regardless of which method is used, a method is required to determine
   if the tunnel is still in use.  This is a local matter, but the
   following criteria are what is used by the FreeSWAN project.  This
   criteria is currently implemented in the key management daemon, but
   could also be implemented at the SPD layer using an idle timer.

   + a short initial (soft) lifespan of 1 minute is set.  This is done
      since many net flows in fact last only a few seconds.

   + upon expiry, a check is made to see if the tunnel was used by
      traffic in either direction during the last half of this period.
      If so, assign a longer tentative lifespan, of 20 minutes, after
      which, look again.  If the tunnel is not in use then close the
      tunnel.

   The tentative lifespan is independent of rekeying; it is just the
   time when the  tunnel's future is next considered.  (The term
   lifespan is used here rather than lifetime for this reason.) This
   should happen reasonably frequently,  unlike  rekeying,  which  is
   costly  and shouldn't  be  too frequent.

   Multi-step backoff algorithms were cosnidered but are not worth the
   trouble; connections are considered to be either very short lived, or
   long lived.  A poll every 20 minutes is not considered a problem.

   If the security gateway and the client host are one and the same,
   tunnel teardown decisions might wish to pay  attention to  TCP
   connection  status,  as  reported  by the local TCP layer.  A still-
   open TCP connection is  almost  a  guarantee that  more  traffic  is



Richardson, et al.        Expires April 1, 2002                [Page 16]

Internet-Draft                opportunistic                 October 2001


   coming, while the demise of the only TCP connection through a tunnel
   is a strong hint  that no more traffic will transit.

5.2 Teardown and Cleanup

   Teardown  should  always  be coordinated with the other end.  This
   means interpreting and sending Delete notifications.

   On receiving a Delete for the outbound SAs of a  tunnel  (or some
   subset  of  them), tear down the inbound ones too, and notify the
   other end with a Delete.  Tunnels need to be considered as
   bidirectional entities, even though the low-level protocols don't
   think of them that way.

   When the deletion is initiated locally,  rather  than  as  a response
   to  a received Delete, send a Delete for (all) the inbound SAs  of  a
   tunnel.   If  no  responding  Delete  is received  for  the outbound
   SAs, try re-sending the original Delete.  Three tries spaced 10s
   apart  seems  a  reasonable level  of effort.  A failure for the
   other end to respond at this point likely indicates that no further
   communication will be possible in anycase.

   After rekeying, transmission should switch to using the  new SAs
   (ISAKMP or IPsec) immediately, and the old leftover SAs should be
   cleared out promptly  (and  Deletes  sent)  rather than  waiting  for
   them to expire.  This reduces clutter and minimizes confusion.

   Since there  is  only  one  keying  channel  per  remote  IP address,
   the  question of whether a Delete notification has appeared on a
   ``suitable'' keying channel does not arise.





















Richardson, et al.        Expires April 1, 2002                [Page 17]

Internet-Draft                opportunistic                 October 2001


6. Impacts on IKE

6.1 ISAKMP/IKE protocol

   The IKE wire protocol needs no modifications.  The major changes are
   implementation issues relating to how the proposals are interpreted,
   and from whom they may come.

   As Opportunistic Encryption is designed to be useful between peers
   without prior operator configuration, an IKE daemon must be prepared
   to negotiate phase 1 SAs with any node.  This may require a large
   amount of resources to maintain cookie state, as well as large
   amounts of entropy to for nonces, cookies, etc.

   The major changes to support Opportunistic Encryption are at the IKE
   daemon level.  These changes relate to handling of key acquisition
   requests, lookup of public keys and TXT records, and interactions
   with firewalls and other security facilities that may be coresident
   on the same gateway.

6.2 Gateway discovery process

   In a typical configured tunnel situation, the address of SG-B is
   provided via configuration.  Furthermore, the mapping of SPD entry to
   gateway is typically a 1:1 mapping.  When the 0.0.0.0/0 SPD entry
   technique is used, then the mapping to a gateway is determined by the
   reverse DNS records.

   The need to do a DNS lookup and wait for a reply will typically
   introduce a new state and a new event source (DNS replies) to IKE.
   Although a synchronous DNS request can be done for proof of concept,
   this will not scale very well.

   Use of an asychronous DNS lookup will also permit overlap of DNS
   lookups with protocol steps.

6.3 Self identification

   SG-A will have to establish its identity.  This is done by use of an
   IPv4 ID in phase 1.

   There are many situations where the administrator of SG-A may not be
   able to control their reverse DNS.  Typical situations include dialup
   connections and most residential-type broadband Internet access
   (ADSL, cable-modem).  In these situations, a fully qualified domain
   name which is under the control of SG-A's administrator may be used.
   The FQDN ID should be used in phase 1.  See Section 7.3 for more
   details and restrictions.



Richardson, et al.        Expires April 1, 2002                [Page 18]

Internet-Draft                opportunistic                 October 2001


6.4 Public key Retrieval process

   Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID,
   or an FQDN ID, an IKE daemon will need to examine local caches and
   configuration files to determine if this is part of a configured
   tunnel.  If none is found, then the implementation should attempt to
   retrieve a KEY record from the reverse DNS (in the case of an
   IPv4/IPv6 ID), or from the forward DNS in the case of FQDN ID.

   It is reasonable that if other non-local sources of policy are used
   (COPS, LDAP, ...) that they be consulted concurrently, but that some
   clear ordering of policy be provided.  Note that due to variances in
   latency, one must wait for positive or negative replies from all
   sources of policy before making any decisions.

6.5 Interactions with DNSSEC

   The present implementation does not use DNSSEC to explicitly verify
   the authenticity of zone information, or use the NXT records to
   provide authentication of the absence of a TXT or KEY record.  These
   are important considerations for practical use.

   In practice the verification of the DNSSEC SIG and NXT records will
   typically be done by a trusted DNS server.  This process may be co-
   located, or reachable via a trusted path.

6.6 Recommended proposal types

6.6.1 Phase 1 IDs

   Main mode SHOULD be used.

   Support for the second oakley group (1024 bit group) is a MUST.
   Implementations SHOULD support for group five (1536 bit group).

   For Phase 1, a proposal of 3DES-CBC with MD5 authentication SHOULD be
   used.

   SG-A SHOULD use an ID_IPV4_ADDR, of the external interface of SG-A
   for phase 1.  (There is an exception, see Section 7.3) The
   authentication method should be RSA public key signatures.

   The RSA key for SG-A SHOULD be placed into a DNS KEY record in the
   reverse space of SG-A.  (i.e.  using in-addr.arpa.)

6.6.2 Phase 2 IDs

   SG-A SHOULD propose a tunnel between Alice and Bob, using 3DES-CBC



Richardson, et al.        Expires April 1, 2002                [Page 19]

Internet-Draft                opportunistic                 October 2001


   mode, MD5 or SHA1 authentication.  Perfect Forward Secrecy SHOULD be
   specified.

   Authorization for SG-A to act on Alice's behalf is determined by
   looking for a TXT record in the reverse map at Alice's address.














































Richardson, et al.        Expires April 1, 2002                [Page 20]

Internet-Draft                opportunistic                 October 2001


7. DNS issues

7.1 Use of KEY record

   In order to establish its own identity, SG-A and SG-B must publish
   their public keys in their reverse DNS.  This is just done via
   DNSSEC's KEY record.  See section 3 of RFC 2535 [7].

   For example:

   KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8

   0x4200 The flag bits, indicating that this key is prohibited for use
      confidentiality (it authenticates the peer only, DH is used for
      confidentiality), and that this key is associated with the non-
      zone entity whose name is the RR owner name.  No other flags are
      set.

   4 This indicates that this key is for use by IPsec

   1 An RSA key is present

   AQNJjkKlIk9...nYyUkKK8 the public key of the host as described in [8]


7.2 Use of TXT delegation record

   A TXT record is published by Alice (Bob) to provide authorization for
   SG-A (SG-B) to act on their behalf.  This record is located in the
   reverse DNS (in-addr.arpa) for them.  The reverse DNS SHOULD be
   secured by DNSSEC, when it is deployed.  DNSSEC is required to defend
   against active attacks.

   The mechanism described here provides a new way to change the routing
   of IP packets other than the routing system.  As a matter of local
   policy, an implementation MAY ignore these records unless it is
   certain that they have been signed with DNSSEC.

   If Alice's address is P.Q.R.S, then she can authorize another node to
   act on her behalf by publishing records at:

   S.R.Q.P.in-addr.arpa

   The resource record is expected to include a record that follows the
   following syntax, as suggested in [6]:

   X-IPsec-Server(P)=A.B.C.D KEY




Richardson, et al.        Expires April 1, 2002                [Page 21]

Internet-Draft                opportunistic                 October 2001


   P: the P specifies a precedence for this record.  This is similar to
      MX record preferences.  Lower numbers have stronger preference.

   A.B.C.D: specifies the IP address of the Security Gateway for this
      client machine.

   KEY: is the encoded RSA Public key of the Security Gateway.  This is
      provided here to avoid a second DNS lookup.

   In the case where Alice is located at a public address behind a
   security gateway that has no fixed address (or no control over its
   reverse map), then Alice may delegate to a public key by domain name:

   X-IPsec-Server(P)=@FQDN KEY

   P: is as above.

   FQDN specifies the FQDN that the Security Gateway will identify
      itself with.

   KEY: is the encoded RSA Public key of the Security Gateway.

   If there is more than one such TXT record with strongest (lowest
   numbered) precedence, one Security Gateway is picked arbitrarily from
   those specified in the strongest-preference records.  All keys for
   that all listed Security Gateways are made available as candidates
   for signature checking.  This mechanism is required to permit
   rollover of signature keys in a seamless fashion.

7.2.1 Choice of TXT record

   It has been suggested to use the OPT, CERT or KEY records instead of
   a TXT record.

   They KEY RR has a Protocol field which could be used to indicate use
   for a new protocol, and an Algorithm field which could be used to
   indicate different contents in the key data.  However, the KEY record
   is not clearly indended for storing what are really authorizations,
   it is just for identities.  Other uses have been discouraged.

   OPT resource records, as defined in [5] are not intended to be used
   for storage of information.  They are not to be loaded, cached or
   forwarded.  They are therefore inappropriate for use here.

   CERT records [9] can encode almost any set of information.  A custom
   Type code would be used permitting any suitable encoding to be
   stored, not just X.509.  The certificate according to the RFC, are
   signed internally, which may add undesireable and unnecessary bulk.



Richardson, et al.        Expires April 1, 2002                [Page 22]

Internet-Draft                opportunistic                 October 2001


   Larger DNS records may require TCP transfers instead of UDP ones.

   At the time of protocol design, the CERT RR was not widely deployed
   and could not be counted upon.  Use of CERT records will be
   investigated in a future version of the specification.

7.3 Use of FQDN IDs

   Unfortunately, not every administrator has control over the contents
   of the reverse-map.  The only case where we can work around this is
   where the initiator (SG-A) has no suitable reverse map.  In this
   case, the authorization record present in the reverse map of Alice
   may refer to a FQDN instead of an IP address.

   In this case, the client's TXT record gives the fully qualified
   domain name (FQDN) in place of its security gateway's IP address.
   The initiator should use the ID_FQDN ID-payload in phase 1.  A
   forward lookup for a KEY record on the FQDN must yield the
   initiator's public key.

   This method can also be used when the external address of SG-A is
   dynamic.

   If SG-A is acting on behalf of Alice, then Alice must still delegate
   authority for SG-A to do so in her reverse map.  When Alice is SG-A
   (i.e.  Alice is acting as an end-node) then there is no need for
   this.  See Figure 6
























Richardson, et al.        Expires April 1, 2002                [Page 23]

Internet-Draft                opportunistic                 October 2001


8. Network Address Translation interaction

   There are no fundamentally new issues for getting opportunistic
   encryption to work in the presence of network address translation.
   Rather there are just the regular IPsec issues with NAT traversal.

   There are several situations to consider for NAT:

8.1 Colocated NAT/NAPT

   If SG-A is also performing Network Address Translation on behalf of
   Alice, then the packet should be translated prior to being subjected
   to opportunistic encryption.  This is in contrast to typical
   configured tunnel which often exist to bridge islands of private
   network address space.  SG-A will use the translated source address
   for phase 2, and so SG-B will look that address up to confirm SG-A's
   authorization.

   In the case of NAT (1:1), the address space into which the
   translation is done MUST be globally unique, and so control over the
   reverse map is assumed to be a given.  Placing of TXT records is
   possible.

   In the case of NAPT (m:1), the address will be SG-A.  The ability to
   get KEY and TXT records in place will again depend upon whether or
   not there is administrative control over the reverse map.  This is
   identical situations involving a single host acting on behalf of
   itself.  FQDN style can be used to get around a lack of a reverse map
   for initiators only.

8.2 SG-A behind NAT/NAPT

   If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec
   NAT traversal rules would apply.  In addition to the transport
   problem which can be solved via proposals like [4], there is the
   issue of what phase 1 and phase 2 IDs to use.  While FQDN could be
   used during phase 1 for SG-A.  An appropriate ID for phase 2 permits
   SG-B to determine that SG-A was in fact authorized to speak for
   Alice.

   This is only possible if Alice actually has a public IP.  It is a
   somewhat unusual case where a public network exists behind SG-A,
   while SG-A itself is behind a NAPT.  This may occur with mobile
   networks of various kinds that occasionally wind up behind a NAPT.

8.3 Bob is behind a NAT/NAPT

   If Bob is behind a NAT (perhaps SG-B), then there is in fact no way



Richardson, et al.        Expires April 1, 2002                [Page 24]

Internet-Draft                opportunistic                 October 2001


   for Alice to address a packet to Bob.  Not only is opportunistic
   encryption impossible, but it is also impossible for Alice to
   initiate any communication to Bob.  It may be possible for Bob to
   initiate in such a situation.















































Richardson, et al.        Expires April 1, 2002                [Page 25]

Internet-Draft                opportunistic                 October 2001


9. Host implementations

   When Alice and SG-A are components of the same system, then this is
   considered to be a host implementation.  The scenario remains
   unchanged with respect to packet sequence.

   Components marked Alice are simply the upper layers (TCP, UDP, the
   application), and SG-A is the IP layer.

   Note that tunnel mode is still recommended.

   As Alice/SG-A are acting on behalf of themselves, no TXT based
   delegation record is necessary for Alice.  She can rely on a FQDN in
   a forward map.





































Richardson, et al.        Expires April 1, 2002                [Page 26]

Internet-Draft                opportunistic                 October 2001


10. Multihoming

   If there are multiple paths between Alice and Bob (such as
   illustrated in the diagram with SG-D) then additional DNS records are
   required to establish authorization.

   In the diagram in Figure 1, Alice has two ways to exit her network:
   SG-A and SG-D.  Previously SG-D has been ignored.  Postulate that
   there are routers between Alice and her set of security gateways
   (denoted by the + signs and the marking of an autonomous system
   number for Alice's network).  Packets may therefore travel to either
   SG-A or SG-D en route to Bob.

   As long as all network connections are in good order it does not
   matter how packets exit Alice's network.  When they reach either
   security gateway, the security gateway will find the TXT delegation
   record in Bob's reverse map, and establish an SA with SG-B.

   SG-B has no problem establishing that either of SG-A or SG-D may
   speak for Alice, as Alice has published two equally weighted TXT
   delegation records:

   X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q==
   X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9==

   Alice's routers can now happily do any kind of load sharing that they
   might wish to do.  SG-A and SG-D will both send packets addressed to
   Bob through their tunnel to SG-B.

   If Alice wishes to prefer one gateway over another, then Bob should,
   upon finding that it has connections to two gateways en route to
   Alice, prefer the one with the lower precedence.

   If the precendences are the same, then SG-B has a more difficult
   time.  It must decide which of the two tunnels to use.  SG-B has no
   information about which link is less loaded, nor which security
   gateway has more cryptographic resources available.  SG-B in fact has
   no knowledge of whether both gateways are even reachable.

   The Public Internet's default free zone may well know a good route to
   Alice, but the packets that SG-B creates must be addressed to either
   SG-A or SG-D; they can not be addressed to Alice directly.

   There are a number of choices which SG-B may do:

   1.  It can ignore the problem and round robin among the tunnels it
       has.  This will cause losses during times when one or the other
       security gateway is unreachable.  If this worries Alice, she can



Richardson, et al.        Expires April 1, 2002                [Page 27]

Internet-Draft                opportunistic                 October 2001


       change the weights in her TXT delegation records.

   2.  It can always send to the gateway that it most recently received
       from.  This assumes that routing and reachability is symmetrical.

   3.  It can listen to BGP information from the Internet to decide
       which system is currently up.  This is clearly a much more
       complicated thing to do, but if SG-B is already doing this
       because it is participating in the BGP peering system to announce
       Bob, the results data may already be available to it.

   4.  It can refuse to negotiate the second tunnel.

   5.  It can silently replace the first tunnel with the second one,
       while still being willing to accept packets from either SG-A or
       SG-D.

   These are decisions left to local mattes.  Note that even if SG-B has
   perfect knowledge about reachability of SG-A and SG-D, Alice may not
   be reachable from one or other of these security gateways due to
   internal reachability issues.

   FreeS/WAN implements option 5, but plans to implement option 2 in the
   future.



























Richardson, et al.        Expires April 1, 2002                [Page 28]

Internet-Draft                opportunistic                 October 2001


11. Failure modes

11.1 DNS failures

   If a DNS server fails to respond, then it is a local policy decision
   whether or not to permit communication in the clear.  It should clear
   that mounting a denial of service attack on the DNS server
   responsible for a particular network's reverse map is an easy thing
   to do.  Such an attack may cause all communication with that network
   to go in the clear.  Please note that this is an active attack.

   At the same time, there are still a very large number of networks
   that do not have properly configured reverse maps.  Further, the
   effect of the above denial of service attack, if the policy is not to
   communicate, is that the target network becomes isolated.  This is
   why this decision MUST be a matter of local policy.

11.2 DNS configured, IKE failures

   In this situation, DNS records claim that opportunistic encryption
   should occur, but the target gateway either does not respond on port
   500, or refuses the proposal.  This may be due to a crash/reboot, due
   to misconfiguration, a firewall filtering port 500.

   The receipt of ICMP port, host or network unreachable messages should
   be taken as a sign that there is a potential problem, but MUST NOT
   cause communication to fail immediately.

   It is recommended that in these situations that a clear log be
   produced about the problem.  A local policy should dictate if
   communication is then permitted in the clear at this point.

11.3 System reboots

   Tunnels sometimes go down because the other end crashes,  or
   disconnects,  or  has  a network link break, and there is no notice
   of this in the general case.  (Even in the event of a crash  and
   successful reboot, other SGs don't hear about it unless the rebooted
   SG has specific reason to talk  to  them immediately.)  Over-quick
   response to temporary network out- ages is undesirable...  but note
   that a tunnel can  be  torn down and then re-established without any
   user-visible effect except a pause in traffic, whereas if one end
   does  reboot, the  other  end  can't  get packets to it at all
   (except via IKE) until the situation is noticed.  So a bias toward
   quick response  is  appropriate,  even  at  the cost of occasional
   false alarms.

   A mechanism for recover after reboot is not specified in this



Richardson, et al.        Expires April 1, 2002                [Page 29]

Internet-Draft                opportunistic                 October 2001


   document, as it is a topic of current research.

   A deliberate shutdown should include an attempt to notify all  other
   SGs currently  connected by keying channels, using Deletes, that
   communication is about to fail.  (Again, these will be taken as
   teardowns;  attempts  by  the other SGs to negotiate new tunnels as
   replacements should be ignored  at  this  point.) And   when
   possible,   SGs   should  attempt  to  preserve information about
   currently-connected  SGs  in  non-volatile storage,  so  that  after
   a crash, an Initial-Contact can be sent to previous partners to
   indicate  loss  of  all  previ- ously-established connections.








































Richardson, et al.        Expires April 1, 2002                [Page 30]

Internet-Draft                opportunistic                 October 2001


12. Unresolved issues

12.1 Control of reverse DNS

   The method of obtaining information is by reverse DNS lookup causes
   problems for people who can not control their reverse DNS bindings.
   This is an unresolved problem in this version, and is out of scope.












































Richardson, et al.        Expires April 1, 2002                [Page 31]

Internet-Draft                opportunistic                 October 2001


13. Security Considerations

13.1 Configured vs Opportunistic Tunnels

   Configured tunnels are those which are setup using bilateral
   mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared
   secrets, or by referencing keys that are in known places
   (distinguished name from LDAP, DNS).  These keys are then used to
   configure a specific tunnel.

   A pre-configured tunnel may be on all the time, or may be keyed only
   when needed.  The end points of the tunnel are not necessarily
   static: many mobile applications ("road warrior") are considered to
   be configured tunnels.

   The key consideration is that configured tunnels are assigned
   specific security properties.  They may be trusted in different ways.
   This is usually related to exceptions to firewall rules, exceptions
   to NAT processing, and to bandwidth or other quality of service
   restrictions.

   Opportunistic tunnels are not inheirently trusted in anyway.  They
   are created without prior arrangement.  As the two parties are
   strangers, there MUST be no confusion of packets that arrive from
   opportunistic peers and those that arrive from configured tunnels.  A
   security gateway MUST take care that an opportunistic peer can not
   impersonate a configured peer.

   It is recommended that an implementation SHOULD prevent opportunistic
   peer from impersonating another opportunistic peer.  This is
   equivalent to inforcing ingress filtering of source addresses.

   An implementation suggestion is to logically treat opportunistically
   tunnel packets as if they arrive on a distinct logical interface from
   other configured tunnels.  As the number of opportunistic tunnels
   that may be created automatically on a system is potentially very
   high, careful attention to scaling should be taken into account.

13.2 Firewalls vs Opportunistic Tunnels

   Typical usage of per-packet access control lists is to implement
   various kinds of security gateways.  These are typically called
   "firewalls".

   Typical usage of virtual private network (VPN) within a firewall is
   to bypass all or part of the access controls between two networks.
   Additional trust (as outlined in the previous section) is given to
   packets that arrive in the VPN.



Richardson, et al.        Expires April 1, 2002                [Page 32]

Internet-Draft                opportunistic                 October 2001


   Packets that arrive via opportunistically configured tunnels MUST not
   be trusted.  Any security policy that would apply to a packet
   arriving in the clear SHOULD also be applied to packets arriving
   opportunistically.

13.3 Denial of Service

   There are several different forms of denial of service which an
   implementor should concern themselves with.  Most of these problems
   are shared with security gateways that have large numbers of mobile
   peers (road warriors).

   The design of ISAKMP/IKE, and its use of cookies defend against many
   kinds of denial of service.  There is an assumption that if the phase
   1 (ISAKMP) SA is authenticated, that it was worthwhile creating.
   Opportunism changes this assumption.  As the gateway will communicate
   with anyone, it is possible to form phase 1 SAs with any machine on
   the Internet.

































Richardson, et al.        Expires April 1, 2002                [Page 33]

Internet-Draft                opportunistic                 October 2001


14. IANA Considerations

   There are no known numbers which IANA will need to manage.
















































Richardson, et al.        Expires April 1, 2002                [Page 34]

Internet-Draft                opportunistic                 October 2001


References

   [1]   Redelmeier, D. and H. Spencer, "Opportunistic Encryption",
         paper http://www.freeswan.org/freeswan_trees/freeswan-
         1.91/doc/opportunism.spec, May 2001.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [4]   Huttunen, A. and W. Dixon, "UDP Encapsulation of IPsec
         Packets", ID internet-draft (draft-ietf-ipsec-udp-encaps-00),
         June 2001.

   [5]   Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
         August 1999.

   [6]   Rosenbaum, R., "Using the Domain Name System To Store Arbitrary
         String Attributes", RFC 1464, May 1993.

   [7]   Eastlake, D., "Domain Name System Security Extensions", RFC
         2535, March 1999.

   [8]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System
         (DNS)", RFC 2537, March 1999.

   [9]   Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
         Domain Name System (DNS)", RFC 2538, March 1999.

   [10]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
         Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
         2748, January 2000.

   [11]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
         (NAT) Terminology and Considerations", RFC 2663, August 1999.














Richardson, et al.        Expires April 1, 2002                [Page 35]

Internet-Draft                opportunistic                 October 2001


Authors' Addresses

   Michael C. Richardson
   Sandelman Software Works
   470 Dawson Avenue
   Ottawa, ON  K1Z 5V7
   CA

   EMail: mcr@sandelman.ottawa.on.ca
   URI:   http://www.sandelman.ottawa.on.ca/


   D. Hugh Redelmeier
   Mimosa
   Toronto, ON
   CA

   EMail: hugh@mimosa.com


   Henry Spencer
   SP Systems
   Box 280 Station A
   Toronto, ON  M5W 1B2
   Canada

   EMail: henry@spsystems.net
























Richardson, et al.        Expires April 1, 2002                [Page 36]

Internet-Draft                opportunistic                 October 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Richardson, et al.        Expires April 1, 2002                [Page 37]

