Re: l2tp as ipsra solution

["Bernard Aboba" <aboba@xxxxxxxxxxxxx>]

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

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.