[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

IPSP Working Group                                            S. Fluhrer
INTERNET DRAFT                                             Cisco Systems
                                                         7 November 2001


                       Tunnel Endpoint Discovery
                        draft-fluhrer-ted-00.txt

Status of this Memo

   This document is an Internet Draft and is subject to all provisions
   of Section 10 of RFC2026. Internet Drafts are working documents of
   the Internet Engineering Task Force (IETF), its areas, and 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.

   Comments on this document should be sent to the IETF IPSP WG
   discussion list (ipsec-policy@vpnc.org).

Abstract

   The ISAKMP, IKE and IPSec DOI RFCs [RFC2408, RFC2409, RFC2407]
   specify how an IPSec tunnel is negotiated with an encrypting security
   gateway (peer), however, they do not specify how the initiator knows
   who the encrypting peer is. This document specifies a method where
   the initiator can find the appropriate peer, and also negotiate a
   mutually acceptable set of proxies.

Overview and Rational

   One of the difficulties with deploying ISAKMP/IPSec based networks is
   the problem of configuring each IPSec host or security gateway with
   the information required to associate what encrypted traffic should
   be forwarded to which peer.  It is especially important that adding a
   new encrypting host or gateway should not require the reconfiguration
   of all existing peers.  Tunnel Endpoint Discovery (TED) attempts to
   solve this problem by relying on routing to find the appropriate
   peer.

   Here is an overview of the TED protocol: if an IPSec host or security
   gateway needs to know the appropriate peer for a particular flow, it
   creates a "TED Probe", which is an ISAKMP packet with the source IP
   being the source IP of the flow, and the destination IP being the
   destination IP of the flow.  The TED probe packet will follow exactly
   the same path as an unencrypted packet would.  When that TED probe
   arrives at the encrypting peer, that peer recognizes it and absorbs
   it.  The peer then sends a "TED response" to the original IPSec host
   or security gateway, which will inform it as to the peer's identity,
   and allow it to create an appropriate set of proxies.  The original
   host can then either proceed with IKE Phase 1, or go immediately to
   IKE Phase 2 if it already happens to have an IKE SA with that
   particular peer.

TED Probe Format

   A TED Probe is an IKE packet (UDP with destination port 500, and with
   an ISAKMP header), with the source and destination IP addresses in
   the IP header being the source IP and the destination IP of the flow
   being queried, whose exchange type is 240, message ID zero, a unique
   cookie as the initiator cookie, zeros as the responder cookie, and is
   unencrypted.  The payloads in the probe MUST include an ID payload
   which is the IP address of the initiating IPSec host or security
   gateway (which MUST be the first ID payload within the probe).

Processing on Receiving a TED Probe

   Upon receiving a TED probe, the responder SHOULD examine its SPD to
   determine whether the source and destination within the IP header
   would be IPSec protected, and if so, what would an acceptable set of
   proxies for an IPSec SA that protects it (and if the responder does
   not examine its SPD, it MUST discard the packet).  If that packet
   type is protected, and if TED response is enabled for that SPD entry,
   then the reponder MUST make a best effort attempt to send a TED Reply
   based on that SPD entry.


TED Reply Format

   A TED Replay is an IKE packet, with the source IP being the IP
   address of the encrypting peer, and the destination IP address the IP
   address of the initiator, whose exchange type is 241, message ID
   zero, the initiator cookie from the TED Probe, a unique cookie as the
   responder cookie, and is unencrypted.  The payloads in the probe MUST
   include an ID payload which is the IP address of the responding IPSec
   host or security gateway (which MUST be the first ID payload within
   the response), and a second ID payload that represents the local
   portion of proxy entry within the SPD entry.

Processing on Receiving a TED Response

   Upon receiving a TED response, the initiator SHALL determine if it
   corresponds to a TED probe it has recently sent.  If it has, it SHALL
   examine its SPD to determine its acceptable set of proxies, and
   combine the local portion of its matching SPD entry, the half proxy
   listed within the second identity to form a provisional set of
   proxies.  The initiator SHOULD double-check that the provisional set
   of proxies are acceptable given the SPD, and that the original packet
   would fall within it.

   Then, the initiator MUST make a best effort attempt to intiate a
   quick mode to the responding peer using the provisional proxies
   (first initiating a phase 1 if required).

Usage Considerations

   For this to be an effective solution, the SPD should follow certain
   criteria:

   - The SPD entries should have everything other than the source
     IP address and the destination IP address wildcarded.
     This is suggested, because the responder selects an SPD
     entry given only those two entries, and having SPD entries
     that depend on other factors would allow the responder to
     select an incorrect entry.

Security Considerations

   The use of this protocol allows an outside observer to view two
   aspects of the policy:

   - By studying the contents of the TED probe and the TED response,
     an observer may be able to deduce the proxies that are protected
     by an IPSec SA that was created using the TED protocol.

   - An observer is able to obtain the proxies that a host or
     security gateway is configured to protect by sending TED probes
     to it, and observing the TED responses.

   If either of these is deemed to be unacceptable, the TED protocol
   MUST not be used.

Future Directions

   It has been suggested that the TED Probe and Response should have
   signature (and certificate) payloads to add additional security.
   However, there was insufficient time to fully consider this idea.

Acknowledgements

   This protocol is a minor modification of one designed by Dan Harkins.

   The suggestion to add signatures to the probes was made by Jan
   Vilhuber.

References

      [Bra97]  Bradner, S., "Key Words for use in RFCs to indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

      [Har98]  Harkins, D., Carrel, D. "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.

      [Mau98]  Maughan, D., Schertler, M., Schneider, M., Turner, J.,
               "Internet Security Association and Key Management
               Protocol (ISAKMP)", RFC 2408, November 1998.

      [Pip98]  Piper, D., "The Internet IP Security Domain of
               Interpretation for ISAKMP", RFC 2407, November 1998.

Author's Address

   Scott Fluhrer
   Cisco Systems
   10 West Tasman Drive
   San Jose, CA 95134

   Phone: (405) 525-5396

   EMail: sfluhrer@cisco.com


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/