Subject: TED discussion at SLC IETF, and future directions

From: Scott Fluhrer <[email-masked]>
Date: Sat, 26 Jan 2002 17:47:15 -0800

Hi,

  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
proceed.

  The general sense of the working group was they were interested
in this approach, however they preferred to make changes in the
exact protocol.

  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
  cleanly.

  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.

-- 
scott

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jan 2002 00:47:01 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Scott" == Scott Fluhrer <[email-masked]> writes:
    Scott>   However, before I make any specific changes, I would like to
    Scott> assert two criteria:

    Scott> - This is a protocol that is actually working in the field.
    Scott>   Therefore, I would prefer not to make any gratuitous changes --
    Scott>   that is, any change to the protocol would be to achieve some
    Scott>   distinct improvement in the protocol.

  In that case, please submit your draft as an Informational RFC on the
protocol and then let's go on with discussing the requirements.

    Scott> - I would prefer to rule out drastic changes.  TED is, for
    Scott>   example, an entirely distributed approach, with no central
    Scott>   controllers.  While the idea of a central controller may have
    Scott>   merit, if the working group decide to pursue that, I would
    Scott>   prefer it be recognized as a different protocol.

  I agree with you here.

    Scott> And, in keeping in line with the first criteria, before I make
    Scott> any changes in the protocol, I would need to know what in the
    Scott> existing protocol needs improvement.  Here are several
    Scott> mentioned at the IETF, along with my initial comments:
  
  In other words, we need a requirement draft.

  please see draft-ietf-ipsp-requirements-00.txt (expired in May 2001,
recently resubmitted as 01, also at:
	 http://www.sandelman.ottawa.on.ca/SSW/ietf/ipsp/)

  This should, I think, be the major topic of discussion at Minneapolis.

    Scott> - TED ought not design its own protocol for doing discovery, but
    Scott>   reuse an existing protocol (such as RSVP).

    Scott>   Comments: possibly.  I do not know enough about RSVP to say
    Scott>   anything intelligent about it.  However, if people think this
    Scott>   is important, I can look into it.

  You need to at least read the RFCs on RSVP.

{Luis, if you can, get us a 1 hour slot on Tuesday or Wednesday. Monday
evening is really tough after a long day. If we need time for PIB stuff, do
it seperately.}

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Eric Vyncke <[email-masked]>
Date: Mon, 28 Jan 2002 11:54:01 +0100

At 17:47 26/01/2002 -0800, Scott Fluhrer wrote:

..%<......%<.......

>   is important, I can look into it.

My understanding of RSVP is that it is mandatory for all routers in the 
path of RSVP packets to process the RSVP packets.

Which is of course quite normal for QoS (which is enforced on all routers 
in the path) but not the expected behavior for IPSec (which is end to end).

Also, we could expect some ISP to simply drop all RSVP packets because they 
do not want their customers either using RSVP for QoS or running a DoS 
attack by sending thousands of RSVP packets that will be processed by the 
router (processing a RSVP packet will take much more time than switching a 
simple IP packet).

So, while I do not say 'do not use RSVP for TED', I really wonder whether 
it is the best approach.

Just my 0.01 EUR

-eric

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jan 2002 12:12:36 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Eric" == Eric Vyncke <[email-masked]> writes:
    Eric> At 17:47 26/01/2002 -0800, Scott Fluhrer wrote:

    Eric> ..%<......%<.......

    >> is important, I can look into it.

    Eric> My understanding of RSVP is that it is mandatory for all routers in the 
    Eric> path of RSVP packets to process the RSVP packets.

  No. If the router doesn't do QoS, then the router doesn't do QoS. You may
not get end-to-end QoS guarantees if you don't have end-to-end RSVP capable
routers, but to do anything else would require a flag day!

    Eric> Which is of course quite normal for QoS (which is enforced on all routers 
    Eric> in the path) but not the expected behavior for IPSec (which is end to end).

    Eric> Also, we could expect some ISP to simply drop all RSVP packets because they 
    Eric> do not want their customers either using RSVP for QoS or running a DoS 
    Eric> attack by sending thousands of RSVP packets that will be processed by the 
    Eric> router (processing a RSVP packet will take much more time than switching a 
    Eric> simple IP packet).

  I'd really like to see an ISP that has enough core routers that are RSVP
capable for this to be real. Please - you should have the data. If that is
really the case, then you should trivially be able to find out about this
situation from your customer support people.

  I think that otherwise, RSVP has gotten a very bad FUD experience.

  RSVP doesn't scale because teach IOS how to do SET (so that each ISP can
collect from my credit card) was a total loss. The forwarding plane issues
were solved *long* ago.

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Mon, 28 Jan 2002 15:59:56 -0500

Scott,

If i recall correctly the idea/suggestion behind following the "RSVP 
model" of operation for discovery and path selection was to provide 
embedded security gateway discovery  in TED. TED seems to assume a SG to 
SG scenario only which is fine for that scenario. However, it would be 
nice to enhance the protocol to support discovery of multiple security 
gateways. For example, assume a scenario where a large enterprise (foo) 
may isolate both their engineering and marketing organizations from the 
larger organization using a security gateway for each organization, SG2 
and SG3 respectively. Further assume that both security gateways are 
behind the security gateway of the larger organization (SG1). The idea 
would be for the TED probe received at SG1 to flow through the network 
to SG2 assuming the the SA was intended between some host1 and some 
host2  in the engineering organization and, that the security policy of 
the site **requires** SG2 and perhaps SG1 to be involved in the end2end 
secure communication.

host1 -------------------SG1-----SG2----host2

SG2 may want to (at least) authenticate host1 just like SG1 and host2 
would like to. Also, TED queries and replies should be authentic. 
Signatures may be the way to go here using cert payloads too.  I believe 
the ipsp requirements document may include these design preferences. thanks,

-luis

---

From: Melinda Shore <[email-masked]>
Date: Tue, 29 Jan 2002 09:28:08 -0500

At 03:59 PM 1/28/02 -0500, Luis A. Sanchez wrote:
>If i recall correctly the idea/suggestion behind following the "RSVP model" of operation for discovery and path selection was to provide embedded security gateway discovery  in TED. TED seems to assume a SG to SG scenario only which is fine for that scenario. However, it would be nice to enhance the protocol to support discovery of multiple security gateways. 

It also has the advantage of being able to cope with
topological complexity - I've proposed this model for
firewall/NAT discovery and traversal in the draft
http://search.ietf.org/internet-drafts/draft-shore-friendly-midcom-00.txt

Melinda

---

From: "Hilarie Orman, Purple Streak Development" <[email-masked]>
Date: Wed, 30 Jan 2002 14:18:17 -0700

I think this is a very good high-level description of what is needed and why.
If we replace the NAT discussion with Security Associations, it seems to
be an IPSP model.

Hilarie