2.1.2 Subnet-to-Host Example

   Consider the case where D and R1 implement IPsec, but S does not
   implement IPsec, which is an interesting variation on the previous
   example.  This example is shown in Figure 2 below.

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

       Figure 2:  Network Diagram for Subnet-to-Host Example

   In this example, R1 makes the policy decision that IP Security is
   needed for the packet travelling from S to D.  Then, R1 performs the
   secure DNS lookup for D and determines that D is its own key
   exchanger, either from the existence of a KX record for D pointing to
   D or from an authenticated DNS response indicating that no KX record
   exists for D.  If R1 does not initially know the domain name of D,
   then prior to the above forward secure DNS lookup, R1 performs a




 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   secure reverse DNS lookup on the IP address of D to determine the
   fully-qualified domain name for that IP address.  R1 then initiates
   key management with D to create an IPsec Security Association on
   behalf of S.

   In turn, D can verify that R1 is authorised to create an IPsec
   Security Association on behalf of S by performing a DNS KX record
   lookup for target S.  R1 usually provides identity S to D via key
   management.  If D only has the IP address of S, then D will need to
   perform a secure reverse lookup on the IP address of S to determine
   domain name S prior to the secure forward DNS lookup on S to locate
   the KX records for S.

   If D 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 IPsec Security Association is successfully established between
   R1 and D, that IPsec Security Association has a source identity that
   dominates S's IP address, a proxy identity that dominates R1's IP
   address, and a destination identity that dominates D's IP address.

   Finally, R1 begins providing the security service for packets from S
   that transit R1 destined for D.  When D receives such packets, D
   examines the SA information during IPsec input processing and sees
   that R1's address is listed as valid proxy address for that SA and
   that S is the source address for that SA.  Hence, D knows at input
   processing time that R1 is authorised to provide security on behalf
   of S.  Therefore packets coming from R1 with valid IP security that
   claim to be from S are trusted by D to have really come from S.

2.1.3 Host to Subnet Example

   Now consider the above case from D's perspective (i.e. where D is
   sending IP packets to S).  This variant is sometimes known as the
   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
   the details are covered here in hope of improved clarity.

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

       Figure 3:  Network Diagram for Host-to-Subnet Example







 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   In this example, D makes the policy decision that IP Security is
   needed for the packets from D to S.  Then D performs the secure DNS
   lookup for S and discovers that a KX record for S exists and points
   at R1.  If D only has the IP address of S, then it performs a secure
   reverse DNS lookup on the IP address of S prior to the forward secure
   DNS lookup for S.

   D then initiates key management with R1, where R1 is acting on behalf
   of S, to create an appropriate Security Association.  Because D is
   acting as its own key exchanger, R1 does not need to perform a secure
   DNS lookup for KX records associated with D.

   D and R1 then create an appropriate IPsec Security Security
   Association.  This IPsec Security Association is setup as a secure