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