[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.

FYI, PPP's Extensible Authentication Protocol (EAP) supports certificates.

PatC
> 
> /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...
>
References: