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

RE: l2tp as ipsra solution




On Wed, 14 Jun 2000, Moshe Litvin wrote:

> Bernard,
> 
> I agree with Scott that bytes-on-the-wire is only part of the overhead.
> 
> The problem is that you are comparing raw IPsec (optimized for simplicity
> and speed) with compressed (optimized for size) L2TP. You are not comparing
> apples to apples.

We have had this overhead discussion on the IPsec mailing list previously.  I
have argued and will continue to argue that the L2TP HC and PPP AFC/PFC should
not impact the pps throughput of and L2TP/PPP implementation.  In fact since
L2TP HC runs directly on top of IP this is potentially a slight optimization
since you only have to look inside 2 headers (IP/L2TP) instead of 3
(IP/UDP/L2TP).  I can tell you for a fact that PPP PFC/AFC do not have any
impact on our switching performance.

I think the real argument here might be the fact that the industry is seeing
more and more hardware offload of IPsec which allows not only the crypto
portions of IPsec to be offloaded but the filtering/conformancy checks as well.  
I am not aware of any of these hardware offload designs which support L2TP
natively so you could argue some performance penalty there.  But this really
shouldn't be a point of debate for this working group since this is really just
an implementation detail which can be easily overcome.  So IMO, if the bits on
the wire overhead is the same (which it is, as Bernard pointed) then we should
just quit bringing up this point.

I really think the most productive way to arrive at a solution for ipsra is to
continue to work on a list of requirements before we even try to propose a
solution.  If we keep getting bogged down in L2TP vs CRACK vs XAUTH/MODE Config
vs DHCP, vs whatever we really will have a hard time making progress.  Each of
them appears to have some merit by themselves, but I am not sure that anyone of
them by themselves solves the entire remote access VPN problem.

Along these lines, I would like to make sure that we adequately address not only
the legacy authentication requirements but also the legacy authorization and
accounting requirements.  This includes how/when start and stop accounting
records should be sent, what should be included in the accounting records and
the mapping of this information to whatever protocol is being used.  
Additionally, there is a plethora of authorization attributes which need to be
mapped to a remote access VPN.  There are many which don't make sense for a
remote-access vpn because there we defined for a direct dial environment.

So one of the questions I would ask Scott, should this mapping to a AAA server
be included in the requirements doc or should there be separate drafts written
that describe this mapping (one for radius, one for tacacs, etc).

-Skip

> 
> Moshe
> 
> > -----Original Message-----
> > From: scott@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> > [mailto:scott@xxxxxxxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Scott G. Kelly
> > Sent: Tuesday, June 13, 2000 8:44 PM
> > To: Bernard Aboba
> > Cc: Moshe Litvin; 'Sara Bitan'; 'IPSRA list'
> > Subject: Re: l2tp as ipsra solution
> >
> >
> > Hi Bernard,
> >
> > Bernard Aboba wrote:
> > >
> > > > As for tunneling, IPsec tunnel mode is more efficient
> > than L2TP+IPsec
> > > > transport mode.
> > >
> > > The overhead argument is a red herring.
> > >
> > >
> > http://www.ietf.org/internet-drafts/draft-aboba-ipsra-req-00.t
> > xt discusses
> > > the issue in detail. When L2TP header compression is applied
> > > to L2TP, this results in only one additional octet of
> > overhead compared
> > > with IPSEC tunnel mode. And when PPP mux is used, the overhead
> > > for L2TP is actually much *less* than for IPSEC tunnel mode.
> >
> > I don't agree. The bytes-on-the-wire overhead problem is mitigated by
> > header compression schemes, but this is not the only
> > overhead. You must
> > also consider the additional processing overhead.
> >
> > Scott
> >
> 
> 
>