[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Was Re: multiple payloads via "ID_LIST"


As a customer of VPN solutions, it appears what your talking about is
exactly one of the problems we are facing with "VPN" based leased line
replacement scenarios.

I think Shawn put it quite nicely, and we actually have this problem.
We've got this great big Class A network, which due to historical
oversight did not get allocated as blocks.  We have sites with dozens to
hundreds of subnets which are not completely contiguous.

So, now I've got this nice IPSec solution, but I have to define lists of
hundreds of networks on each side of the SA in order to get the thing to
work.  And I have to do this on each IPSec Router/Gateway on my network
being used as a leased line replacement.  No I can't use a wild card
selector because they may have firewall equipment beside the encryptor
to allow external controlled traffic into their network.

Yes we could renumber, but have you every tried renumbering 200K hosts ?
It's not much fun.  Oh and I didn't mention the hundreds of class C
networks, also not contiguous, we route internally and even some GASP
unrouteable (e.g. 10 - don't ask) networks and a couple of Class Bs we
have too, which are naturally split up geographically (though thankfully
as blocks).

Whomever delivers the best solution to this problem is probably going
to get the most business once everyone else, read the "mainstream"
networkers, figure out what a mess it is to configure a VPN in
a complex network.

Actually, all this talk of Meta-IDs sounds like a really good idea to
me, though I'll have to think on it a little more.  One of the things I
would like to see IPSecond work on is a standard "routing/exchange" like
method for IPSec.  Which either is based upon an existing routing
protocol, or can get information from an existing routing protocol.
This would ease configuration a lot in big networks.  This may be
orthogonal to security in some minds.

For example, wouldn't it be nice if we could make use of External BGP
for Encryption Gateways on the "RED"/Local/Trusted Side of a security
gateway to list all the networks on one side of a VPN and securely share
that information with the other side of the VPN link and vice versa.  So
now both gateways have a list of the networks on either side of the VPN,
which BTW they are also propagating with their respective local network
clouds.

And if the encryptor goes down the traffic can take a different path
rather than black hole the traffic due to the router interaction.

	Branch Site --- Encrypter --- Internet --- Encrypter --- Corporate
	Router

		    EBGP            SOME KIND OF              EBGP
				    ROUTER PROTOCOL

Now I have a lot less configuration to do.  And I've established
security for a group of networks on either side of the link.

Ah you say, well how do we get a link into a useable SPI then since
we're not using destination/source addressing ?  Well, it turns out
there's this little used but interesting field called "community" in
EBGP which could be used as a new selector.  Then perhaps we could
configure on the encryptor:

	Peer Gateway IP Address
	Authentication Required (PreShared/PK)
	Community
	
The Community would then be an index into what Encryption algorithm for
IPSec and even some basic Source/Dest Address filters and/or TCP/UDP
ports for the collective range of networks.  BTW, business partners
could be in this mix, but they could get their own set of SPIs based on
community string and route propagation and so wouldn't necessarily be
using the same tunnels.

So the idea a Meta-ID would be a way of exchanging this information
between IPSec devices, now we need a standard way of getting this
information in and out of the IPSec device in the first place and back
to a router at either end.  Of course if the IPSec device were
a router, this might already be done ;P

This idea isn't new, I think someone at cisco first proposed it.

 ___________________________________________________________________ 
| Bio-Routing:               | Electronic Connectivity:             |
|                            |                                      |
| Yan-Fa LI                  | Phone:    ( +1 ) - 650 236 3680      |
| Hewlett-Packard Company    | Fax:      ( +1 ) - 650 236 3632      |
| Mail Stop: 20CX            |                                      |
| 3000 Hanover Street,       | Telnet:   236 - 3680                 |
| Palo Alto, CA 94304        | Email:    yanfali@corp.hp.com        |
| USA                        |                                      |
|____________________________|______________________________________|