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

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.

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.

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.

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.

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.

/Eric Bomarsi

"Scott G. Kelly" wrote:

> John Shriver wrote:
> >
> > Well, there is NO need for an inner IP header when you use GRE.  You
> > can do either:
> >
> > 1. Use ESP in transport mode, with next header value of GRE.
> > 2. Use ESP in tunnel mode, with next header value of GRE.  (Maybe this
> > is illegal, and tunnel mode requires the next header to be IP?  I
> > don't remember.)

>

>
>
> I think (2) is technically illegal, although an argument exists for
> special treatment. Presumably, you want to do ESP/GRE at a gateway, and
> not on a host. If you *are* doing it on a host for some reason, then you
> can just use transport mode, as in (1). However, RFC2401 requires that
> security gateways communicate using tunnel mode unless the sgw is
> terminating the connection. Now, it could be argued that the sgw *is*
> terminating the GRE connection, in which case transport mode between the
> GRE endpoints would be acceptable. Not bad, I guess.

>
>
> >
> > The advantage of GRE in this case is that it is an IP-level protocol,
> > not a UDP-level protocol.  You don't need an IP/UDP header to navigate
> > there.
>
> It's been quite a while since I looked at the L2TP draft, but I'm under
> the strong impression that it's not a UDP protocol. There may be a UDP
> control channel associated with it, but I think the protocol itself
> operates at layer 2. I know we have at least a few l2tp experts lurking
> here - perhaps they will enlighten us.
>
> > But, let's remember, the "client" (by the time we cut any more
> > standards) will be whatever Microsoft has already decided to ship in
> > Windows 2000.  If that is PPTP, that WILL be how you talk IPX over
> > IPsec to Windows.  (Whether that's where you want to go today or not.)
> > The NDIS WAN universe is so hairy that once Microsoft ships IPsec (in
> > Windows 2000), nobody will be willing to install a different IPsec in
> > it.  (Who loads an alternate TCP/IP stack into Windows 95, 98, or NT
> > these days?  Same will apply to IPsec in Windows 2000.)
>
> I don't think this is necessarily true. Given that PPTP has been shown
> to be very broken (by Schneier, et al), and given that ultimately,
> putting a bunch of extra bits on already overtaxed network wires is
> frowned upon by most realists, even m$ may have difficulty convincing
> everyone that their way is the only way, especially if someone comes up
> with a GRE shim that interoperates with the rest of the world.
Follow-Ups: References: