Re: l2tp as ipsra solution

["W. Mark Townsley" <townsley@xxxxxxxxx>]

Bernard Aboba wrote:
> 
> > 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.
> 
> The biggest single issue would be the checksum check in L2TP if this is
> enabled.
> If you want high performance, then this needs to be disabled. Assuming that
> it
> is, the performance discrepancy should narrow considerably.

I assume you mean the UDP checksum. L2TP does not have its own checksum.

The RFC dictates that the UDP checksum presence MUST be configurable.
Most implementations I have seen have it off by default.

With l2tphc, the UDP checksum does not exist as it runs directly over
IP.

> 
> My understanding is that at the highest speeds, we are moving towards
> designs
> with cryptographic co-processors as well as classification co-processors. In
> the most recent chipsets, the crypto functions are still considerably slower
> than
> classification, which can now run at 1+ Gbps line rate. So as far as I know,
> filtering/conformancy should not be the bottleneck in most cases.
> 
> > 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).
> 
> I would vote for including it since everyone seems to think that AAA
> compatibility is
> so important. Since as you point out most of the AAA attributes don't make
> sense
> for IPSEC tunnel mode, we really do have to at least have
> NAS-Port-Type=ISPEC tunnel mode to have this work.