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

Re: Bridging non-IP traffic over IPSec

I agree with Scott that L2TP on the client is overkill.

My understanding is that L2TP was intended to bundle many many
PPP sessions at a CO or POP and tunnel them over the Internet
to the terminating gateway. Initiating the L2TP session from the
client will put these long headers over the low-speed/low-mtu
dialup link resulting in fragmentation and poor performance,
especially if you require security and the additional IPSec headers.
The only benefit I can see is in the cable modem business because
dialin service will be so bad.

I believe the headers for a client initiated L2TP/IPSec tunneled
packet would be something like this:
    IP/ESP/IP/UDP/L2TP/PPP   - yikes!

I've been trying to figure out why we are not pursuing an IPSec
client solution for non-IP traffic, and the only answer I've found
is that L2TP will do the job.

A recent article from a leading analyst claims that L2TP will be
the short term client VPN solution because IPSec currently
doesn't handle non-IP traffic, private IP addresses across the
internet, and support for RADIUS and other PPP-based
authentication mechanisms.

The non-IP traffic problem isn't a big deal. We can easily bridge
non-IP over IPSec with a GRE tunnel or possibly directly as I
suggested in my previous email.

Private addresses across the Internet ARE supported simply
by using IPSec tunneling mode.

And finally, IKE does support RADIUS and I believe support for other
user authentication mechanisms are proposed. In fact, arguably the
ideal authentication, certificates (in software or on a smartcard) is
supported by IKE today and not PPP as far as I know.

/Eric Bomarsi


"Scott G. Kelly" wrote:

> John Shriver wrote:
> >
> > Well, GRE is an Informational RFC, so GRE is not likely to be part of
> > an IETF Proposed Standard solution.  But, if you do it, you sure will
> > be interoperable with Cisco...
> >
> > Certainly, it will work, and you can express GRE in the SPD.  But, the
> > SPD (and IKE negotiation) can't really negotiate what goes over the
> > GRE.  Is IP allowed over it?  IPX?  Transparent bridging?
> >
>
> This is a timely topic, I guess. I would say that what goes over GRE is
> a local policy issue, and probably not an ipsec issue per se. That is,
> it would be up to your GRE subsystem to determine what it is willing to
> encapsulate, and then up to you ipsec subsystem to determine if policy
> permits GRE to pass. On the other hand, I guess looking into a GRE
> packet to see what protocol is being encapsulated is not really that
> much different than looking into a tcp/udp packet to see what ports are
> involved, so maybe it's not such a far-fetched idea, at that.
>
> > One thing that is standards track, and people have been implementing,
> > is L2TP.  Put PPP over that, and then you have a place to run non-IP
> > traffic.
> >
> > Again, the SPD can't really control what goes over.  But, you can
> > express the L2TP UDP port in the SPD.
> >
> > As above, you will be interoperable with Cisco.
> >
>
> I guess the main problem I have with using l2tp in this case has to do
> with efficiency. Unless l2tp has radically changed in the last 2 years,
> I think it really is overkill for this particular use. Perhaps it's time
> to dust off the GRE RFC and rev it...
Follow-Ups: References: