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

Re: Bridging non-IP traffic over IPSec

   Date: Mon, 22 Feb 1999 08:42:27 -0500
   From: Eric Bomarsi <ebomarsi@xedia.com>
   To: "Scott G. Kelly" <skelly@redcreek.com>
   Cc: John Shriver <jas@shiva.com>, ipsec@tis.com
   Subject: Re: Bridging non-IP traffic over IPSec

   Use of ESP transport mode is for traffic destined to the end system
   and tunnel mode is for traffic to be forwarded by a gateway.

I think we've already sorted out that we can use transport mode.

   More importantly, it comes back to configuration and management.
   Look at it from your customer's persective.

   An ISP wants to configure, monitor and bill on an IPSec tunnel it
   has created for a company between 2 sites. It defines a security
   policy, specifies the routes to direct traffic into the tunnel, and
   configures a monitor to watch the tunnelled traffic between sites.

What exactly does it mean for the ISP to configure, monitor, and bill
an IPSec tunnel?  Will the tunnel start at their premises, not yours?
That doesn't protect the traffic on the link between you and the ISP,
if you want security, I presume that you want it _secure_.

Or will the ISP own the customer-premises router, and configure the
SPD for you there?

   Now there's a need to handle a small fraction of non-IP traffic
   so our answer is to configure another security policy, establish
   another IKE session, possibly burn more addresses with
   a GRE tunnel, configure another monitor and sum the traffic stats.

As I read sections 4.4.1 & 4.4.2 of RFC 2401, the SPD is (potentially)
very fine-grained.  They will have to add another policy to allow this
tunnel.

It will NOT be another IKE session.  Just another SA Bundle in the
existing IKE session that exists for the IP traffic.  Unless you're
using PFS, there isn't even another Diffie-Hellman.

   Yes, it is a solution, but the customers aren't going to buy it,
   and I don't blame them. Just put the bridged traffic through the
   existing tunnel.

I think that you average customer probably really does not want to
bridge the native windows NETBIOS networking between sites.  (How slow
do you want Network Neighborhood to be?)  Also, if you're paying for
QOS under your ESP header, you really don't want to fill up that
pricey bandwidth with the "noise" of bridging, such as NETBIOS
datagrams, which are all broadcasts on Ethernet...

It really doesn't matter whether the tunnel is bridged, routed, or
routed over a bridging encapsulation.  There simply is more
configuration for a multi-protocol bridge/router than for an IP-only
router.  This burden isn't any different when the connection is over
an IP tunnel, or when it's over a leased line.

   BTW, you do need the redundant IP header with GRE inside an
   IPSec tunnel. A standard GRE tunnel downlinks to IP and uplinks
   to a bridge, and knows nothing about IPSec and vice versa.
   Using ESP protocol of GRE would not work with existing GRE
   equipment.

GRE does not have such a restriction.  Both ends can be routers.  (Are
you possibly thinking of 3Com's old Boundary Routing?)

Since we're going to allow GRE over ESP in transport mode, no new IP
addresses are needed for the tunnel.

You still need a network number for IPX over GRE (in routing mode),
but that's something IPXWAN could address.  But you would also need a
network number for a leased line.  No difference!

Again, using L2TP instead of GRE allows PPP to automate a lot more of
the network-layer configuration.  There is more per-packet overhead,
however, no free lunch.

   /Eric Bomarsi
Follow-Ups: References: