destination node.  S2 is another node on the same subnet as S.  D2 is
   another node on the same subnet as D.  R1 and R2 are IPsec-capable
   routers.  The path from S to D goes via first R1 and later R2.  The
   return path from D to S goes via first R2 and later R1.

   IETF-standard IP Security uses unidirectional Security Associations
   [RFC-1825].  Therefore, a typical IP session will use a pair of
   related Security Associations, one in each direction.  The examples
   below talk about how to setup an example Security Association, but in
   practice a pair of matched Security Associations will normally be




 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   used.

2.1.1 Subnet-to-Subnet Example

   If neither S nor D implements IPsec, security can still be provided
   between R1 and R2 by building a secure tunnel.  This can use either
   AH or ESP.

       S ---+                                          +----D
            |                                          |
            +- R1 -----[zero or more routers]-------R2-+
            |                                          |
       S2---+                                          +----D2

       Figure 1:  Network Diagram for Subnet-to-Subnet Example

   In this example, R1 makes the policy decision to provide the IPsec
   service for traffic from R1 destined for R2.  Once R1 has decided
   that the packet from S to D should be protected, it performs a secure
   DNS lookup for the records associated with domain D.  If R1 only
   knows the IP address for D, then a secure reverse DNS lookup will be
   necessary to determine the domain D, before that forward secure DNS
   lookup for records associated with domain D.  If these DNS records of
   domain D include a KX record for the IPsec service, then R1 knows
   which set of nodes are authorised key exchanger nodes for the
   destination D.

   In this example, let there be at least one KX record for D and let
   the most preferred KX record for D point at R2.  R1 then selects a
   key exchanger (in this example, R2) for D from the list obtained from
   the secure DNS.  Then R1 initiates a key management session with that
   key exchanger (in this example, R2) to setup an IPsec Security
   Association between R1 and D.  In this example, R1 knows (either by
   seeing an outbound packet arriving from S destined to D or via other
   methods) that S will be sending traffic to D.  In this example R1's
   policy requires that traffic from S to D should be segregated at
   least on a host-to-host basis, so R1 desires an IPsec Security
   Association with source identity that dominates S, proxy identity
   that dominates R1, and destination identity that dominates R2.

   In turn, R2 is able to authenticate the delegation of Key Exchanger
   authorisation for target S to R1 by making an authenticated forward
   DNS lookup for KX records associated with S and verifying that at
   least one such record points to R1.  The identity S is typically
   given to R2 as part of the key management process between R1 and R2.







 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   If D initially only knows the IP address of S, then it will need to
   perform a secure reverse DNS lookup to obtain the fully-qualified
   domain name for S prior to that secure forward DNS lookup.

   If R2 does not receive an authenticated DNS response indicating that
   R1 is an authorised key exchanger for S, then D will not accept the
   SA negotiation from R1 on behalf of identity S.

   If the proposed IPsec Security Association is acceptable to both R1
   and R2, each of which might have separate policies, then they create
   that IPsec Security Association via Key Management.

   Note that for unicast traffic, Key Management will typically also
   setup a separate (but related) IPsec Security Association for the
   return traffic.  That return IPsec Security Association will have
   equivalent identities.  In this example, that return IPsec Security
   Association will have a source identity that dominates D, a proxy
   identity that dominates R2, and a destination identity that dominates
   R1.

   Once the IPsec Security Association has been created, then R1 uses it
   to protect traffic from S destined for D via a secure tunnel that
   originates at R1 and terminates at R2.  For the case of unicast, R2
   will use the return IPsec Security Association to protect traffic
   from D destined for S via a secure tunnel that originates at R2 and
   terminates at R1.