tunnel with a source identity that dominates D's IP Address and a
   destination identity that dominates R1's IP Address.  Because D
   performs IPsec for itself, no proxy identity is needed in this IPsec
   Security Association.  If the proxy identity is non-null in this
   situation, then the proxy identity must dominate D's IP Address.

   Finally, D sends secured IP packets to R1.  R1 receives those
   packets, provides IPsec input processing (including appropriate
   inner/outer IP address validation), and forwards valid packets along
   to S.

2.2 Other Examples

   This mechanism can be extended for use with other services as well.
   To give some insight into other possible uses, this section discusses
   use of KX records in environments using a Key Distribution Center
   (KDC), such as Kerberos [KN93], and a possible use of KX records in
   conjunction with mobile nodes accessing the network via a dialup
   service.

2.2.1 KDC Examples

   This example considers the situation of a destination node
   implementing IPsec that can only obtain its Security Association
   information from a Key Distribution Center (KDC).  Let the KDC
   implement both the KDC protocol and also a non-KDC key management
   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
   might have its own KX record pointing at the KDC so that nodes not
   implementing the KDC protocol can still create Security Associations
   with each of the client nodes of the KDC.

   In the event the session initiator were not using the KDC but the
   session target was an IPsec node that only used the KDC, the
   initiator would find the KX record for the target pointing at the




 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
   be between the initiator and the KDC.  Then the KDC would distribute
   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
   traffic itself could travel directly between the initiator and the
   destination node.

   In the event the initiator node could only use the KDC and the target
   were not using the KDC, the initiator would send its request for a
   key to the KDC.  The KDC would then initiate an external key
   management exchange (e.g. ISAKMP) with a node that the target's KX
   record(s) pointed to, on behalf of the initiator node.

   The target node could verify that the KDC were allowed to proxy for
   the initiator node by looking up the KX records for the initiator
   node and finding a KX record for the initiator that listed the KDC.

   Then the external key exchange would be performed between the KDC and
   the target node.  Then the KDC would distribute the resulting IPsec
   Security Association to the initiator.  Again, IPsec traffic itself
   could travel directly between the initiator and the destination.

2.2.2 Dial-Up Host Example

   This example outlines a possible use of KX records with mobile hosts
   that dial into the network via PPP and are dynamically assigned an IP
   address and domain-name at dial-in time.

   Consider the situation where each mobile node is dynamically assigned
   both a domain name and an IP address at the time that node dials into
   the network.  Let the policy require that each mobile node act as its
   own Key Exchanger.  In this case, it is important that dial-in nodes
   use addresses from one or more well known IP subnets or address pools
   dedicated to dial-in access.  If that is true, then no KX record or
   other action is needed to ensure that each node will act as its own
   Key Exchanger because lack of a KX record indicates that the node is
   its own Key Exchanger.

   Consider the situation where the mobile node's domain name remains
   constant but its IP address changes.  Let the policy require that
   each mobile node act as its own Key Exchanger.  In this case, there
   might be operational problems when another node attempts to perform a
   secure reverse DNS lookup on the IP address to determine the
   corresponding domain name.  The authenticated DNS binding (in the
   form of a PTR record) between the mobile node's currently assigned IP
   address and its permanent domain name will need to be securely
   updated each time the node is assigned a new IP address.  There are
   no mechanisms for accomplishing this that are both IETF-standard and
   widely deployed as of the time this note was written.  Use of Dynamic




 
RFC 2230           DNS Key Exchange Delegation Record      November 1997


   DNS Update without authentication is a significant security risk and
   hence is not recommended for this situation.