[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
TED discussion at SLC IETF, and future directions
My apologies for being *extremely* tardy with this -- I was out of
town the month after the IETF, and then, well, you can imagine...
In any case, the goal of this memo is to summarize the discussion
of TED at the Salt Lake City IETF, and to foster further discussions
as to its future directions. Of course, the author welcomes any and
all comments, corrections and rotten tomatoes.
I presented the Tunnel Endpoint Discovery (TED) protocol at Salt
Lake City, which is a protocol designed to allow different IPSec
peers to communicate with each other in a manner that avoids the
O(N^2) configuration problem, by finding remote peers in an
automatic fashion. It works by, when one security gateway needs to
establish an encrypted connection to protect a particular traffic
flow, it sends a probe to the flow's destination, which is
intercepted by the remote security gateway, which sends a reply
which supplies enough information to allow to IKE negotiation to
The general sense of the working group was they were interested
in this approach, however they preferred to make changes in the
However, before I make any specific changes, I would like to
assert two criteria:
- This is a protocol that is actually working in the field.
Therefore, I would prefer not to make any gratuitous changes --
that is, any change to the protocol would be to achieve some
distinct improvement in the protocol.
- I would prefer to rule out drastic changes. TED is, for
example, an entirely distributed approach, with no central
controllers. While the idea of a central controller may have
merit, if the working group decide to pursue that, I would
prefer it be recognized as a different protocol.
And, in keeping in line with the first criteria, before I make
any changes in the protocol, I would need to know what in the
existing protocol needs improvement. Here are several
mentioned at the IETF, along with my initial comments:
- TED works only if the protected addresses are publicly routable.
This means it is unusable in a number of common scenarios.
Comments: well, yes. This would be very nice to fix, however,
it would appear to be innate in the approach TED takes. If
anyone has any ideas, I'll be glad to listen.
- TED does not do load balancing with redundant remote peers
Comments: well, yes. One thing we've considered is having the
remote peers know about each other (since they are protecting
the same subnet, that is reasonable), and put the intelligence
in how they handle the TED probe (e.g. TED probes are forwarded
to the peer that has the lightest load). If the working group
considers this a concern, this can certainly be pursued.
- TED ought not design its own protocol for doing discovery, but
reuse an existing protocol (such as RSVP).
Comments: possibly. I do not know enough about RSVP to say
anything intelligent about it. However, if people think this
is important, I can look into it.