Subject: fate of directory based discovery

From: Juha Heinanen <[email-masked]>
Date: Fri, 22 Nov 2002 03:16:25 +0200

there was not enough support in atlanta meeting to make the dns
discovery i-d a working group document.  i guess it would be appropriate
to confirm that also on the mailing list, since not everyone who has
been working on the dns discovery was able to attend the meeting.

anyhow, i have always said that i don't care what the directory is as
long as the vpn solution is internet wide and doesn't use bgp.  some
people didn't like dns discovery, because (although simple) it overloads
dns with stuff that dns was not designed to do.  so there may still be
enough support left for a directory based solution if something "better"
than dns can be found.

i have been thinking for some time now that radius might be a another
possibility for implementing discovery.  it would go something like
this:

- radius is populated for each ce with information about the vpn that
  the ce participates in (if any)
- a ce authenticates to the pe using e.g. 802.1x (or the ce is manually
  configured in the pe)
- pe makes a radius query and gets as a response the id of the ce's vpn
  and a list of other pes that have members in the same vpn
- the vpn's pe list is kept up in the radius server either manually or
  based on radius accounting start/stop messages

this would be a very flexible and automated solution, since there in
case .1x is used, NOTHING ce related needs to be configured in the pe.

before spending more time on this, i would need to get an indication
from the working group if there is enough interest for ANY directory
based solution.

-- juha

---

From: "Brijesh Kumar" <[email-masked]>
Date: Thu, 21 Nov 2002 16:08:56 -0800

Juha,

Even though BGP was  stretched to do what it wasn't designed to do, but
people embraced it because of two reasons. First, VPNs are implemented by
routing teams, and routing engineers would any day like a solution based on
a routing protocol such as BGP than any thing like DNS. Secondly, a routing
protocol brings distributed fault tolerant environment which is hard to
match with any server based solution. I would think it would be very hard to
sell DNS based solutions to routing engineers.

About three years ago, we implemented LDAP based VPN discovery solution at a
(now-defunct) manufacturer of  first generation  VPN routers. It worked
pretty fine. LDAP has solid features for data sunchronization and storage.
I would still have the basic design document some where on my disk.

In my view, Radius server solution is far better than the DNS approach.  It
is easy to implement since it is simple to extend radius server attributes.
Radius Server/client code is easily available from multiple sources.
However, you would need to satisfy the need for relaibility by creating
secondary and tertiary radius servers (all synchronized) for back up. But,
these are already being done successfully for subscriber authentication and
other radius based policy configuration etc. So I dont't see that a major
issues. Therefore, I think, your radius proposal is likely to see much
larger support.

Cheers,

--brijesh

---

From: Sukanta ganguly <[email-masked]>
Date: Thu, 21 Nov 2002 16:31:25 -0800 (PST)

If I may add, the Directory based solution will also
provide you the availability based on how good a
distributed/replicated LDAP directory you deploy. The
distributed and replicated base nature allows you the
flexibility of what you want to do. Also, if the LDAP
implementation provides cache subsystem then it would
a very good fit for your idea. Finally, the flixible
schema model and the easy to extend object attributes
help to a great deal also. I have developed a cache
based directory subsystem and boosted the environment
through put significantly in one of my previous
endeavors. 
  I know many VPN's solutions which use LDAP/Directory
based approach for information persistence for VPN
connections/links.

My 2 cents.
SG

> > from the working group if there is enough interest

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 21 Nov 2002 22:15:28 -0500

Brijesh, Juha et al,

As I discussed with Juha earlier on,

> pe makes a radius query and gets as a response the id of the ce's vpn
the above could be generalized for both PE-based and CE-based VPN site
discovery.

Section 5.7 of the main body and Section 5.0 of the Appendix of
http://www.ietf.org/internet-drafts/draft-lee-ppvpn-ce-auto-config-02.txt (as
well as version 01) discusses the use an Authentication Server and RADIUS to
obtain VPN site information for CE-based VPNs.

Question for Juha, and other providers,  one issue I would like to understand is
how important is timeliness of VPN site information (e.g. updates, add, remove
site) ?

Is it important to be able to update PEs/CEs of VPN information changes or is it
sufficient to simply poll for VPN site information?
How about polling less frequently, but have simple
push/receive-trigger-then-pull mechanisms (which does not require keeping states
about PEs/CEs that cannot be updated yet)?

thanks,
cheng-yin

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 22 Nov 2002 15:23:16 +0200

> the above could be generalized for both PE-based and CE-based VPN site

sure. i would not expect the ces to run bgp and thus we definitely would
need a bgp-free solution for ce-ce discovery.

 > how important is timeliness of VPN site information (e.g. updates,
 > add, remove site) ?

timeliness should be within a range of few seconds after the change has
been administravely made so that the network manager can see the effects
of the change without having to have a coffee break.

 > sufficient to simply poll for VPN site information?

i don't like any solution that is based on polling.  that is why i
suggested that the change is always initiated by the network, not by the
radius server.

 > push/receive-trigger-then-pull mechanisms (which does not require
 > keeping states about PEs/CEs that cannot be updated yet)?

i don't like the idea of specifying any new protocol for discovery
purpose.

-- juha

---

From: Mark Duffy <[email-masked]>
Date: Fri, 22 Nov 2002 15:55:09 -0500

Hi Juha,

I am still interested in seeing a directory-based approach developed.  And,
radius seems like a reasonable approach.

--Mark

---

From: Matt Squire <[email-masked]>
Date: Wed, 27 Nov 2002 01:24:24 -0500

I think there's strong support for non-BGP solutions to the problem. 
There are many many situations where throwing BGP on the VPN device is
simply not an option.

- Matt

---

From: [email-masked]
Date: Wed, 27 Nov 2002 10:58:41 +0200

since there has been several emails on the list in favor of a directory
based solution and especially radius based, i'll write an i-d on using
radius for vpn discovery.  initial version is likely to only cover pe
based vpns, but obviously radius can also be applied to ce based vpns.

-- juha

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 27 Nov 2002 16:14:20 -0500

Juha,

> of the change without having to have a coffee break.

This is good feedback, thanks. I think you mean that the changes should be
effected on PE/CE within a few seconds, not just on the management system,
right?

> suggested that the change is always initiated by the network, not by the

When do PEs/CEs query for VPN information? A site may be removed without
removing or shutting down a CE.

> i don't like the idea of specifying any new protocol for discovery

 I'm not suggesting specifying new protocols either. We may be able to use
existing push or receive trigger and pull mechanisms in conjuction with a
pull mechanism. I agree it's simpler if the requirements are such that we
only need one mechanism.

thanks
cheng-yin

---

From: [email-masked]
Date: Thu, 28 Nov 2002 10:23:11 +0200

> effected on PE/CE within a few seconds, not just on the management system,

yes.

 > removing or shutting down a CE.

see my dns-l2tp draft.  there is no polling in it.  the same can
be achieved with radius.

-- juha