Re: l2tp as ipsra solution

[Skip Booth <ebooth@xxxxxxxxx>]

On Wed, 14 Jun 2000, Scott G. Kelly wrote:

> Hi Skip,
> 
> Skip Booth wrote:
> > 
> > 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.
> 
> This misses the point, i.e. while header compression may or may may not
> affect the throughput of a given l2tp/ppp implementation, it will
> certainly affect the throughput of a native ipsec implementation which
> now has to add the l2tp/ppp code.

Can you explain why you believe this is so?  If you said that your code size was
going to grow I would say OK, but to say your throughput is going to diminish
seems inaccurate to me.

For inbound packet processing (coming out of the tunnel), the packet must be
passed to L2TP/PPP for decapsulation and the packets is now treated as if it
arrived on the virtual PPP interface.  This step, in an optimized solution
should be a simple index into a table with the L2TP session id. IPsec tunnel
mode must have the outer header processed and stripped, so there should be an
equivalent type of decapsulation tradeoff here.

For outbound packet processing (going into the tunnel), the packet must have a
L2TP/PPP header applied applied.  This work should be similar to the work which
must be done for IPsec tunnel mode.

My main point, is that this seems to be fairly close to be a nit, and
should not be used to evaluate a protocol at this point in the game.

> 
> <some text trimmed...>
> 
> > 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).
> 
> If there are specific accounting requirements, then I suppose these
> should be in the ipsra requirements draft. Please elaborate on these
> requirements.

I definititely am concerned about when you should send the stop accounting
message to the AAA server, on the phase 2 delete, phase 1 delete, yet to be
defined idle-timeout, yet to be defined keepalive mechanism, etc.  Ultimately
this will somewhat depend on the combination of protocols we choose but in the
requirements draft, it should discuss requirements for points in time to send
start and stop accounting records as well as mechanisms to detect dead peers.
Information similar to what is in RFC 2809 may need to be defined.

Additionally, I am concerned about how we map various accounting/authorization
information from legacy dial solutions to a remote access VPN.  For instance,
the acct-terminate-cause attribute defined for RADIUS accounting needs to be
defined for the remote vpn space.  The current definitions are very NAS
specific.  Additionally, the value to be used for service-type should be defined
for a remote-access vpn.  PPP has always used the service-type = framed.  If
IPsec is to do the same thing, then it seems that we need to define a new value
for the Framed-Protocol value.  NAS-Port-type is another attribute which is used
in the access-request.  The currently defined values don't seem to make much
sense for a remote-access vpn, unless you use virtual.  

Link speed is also a traditional accounting attribute.  Again, this seems like a
worthwhile attribute to account for, however for a remote access vpn, the speed
which is interesting is the connection speed from the client to the internet.  
AFAIK, IKE has no mechanism for reporting this type of information from the
client to the security gateway.

To this end, I would prefer that the ipsra requirements document state that
whatever protocol is chosen that it have the ability to send link information
for the connection to the internet from the client to the security gateway.

Examples of authorization attributes which need to be spelled out for a remote
access VPN are session-timeout, filter-id (if you recieve filtering information
from your AAA server, should this filter set be negotiated in phase 2 for
instance?), idle-timeout.

In looking at draft-ietf-radius-tunnel-auth-09.txt, I believe that there should
be a mapping for some of these attributes, even though this is not a RFC.

Most of this work has already been done by L2TP/PPP and would be transparent to
IPsec.  Oops, I said I wasn't going to talk protocols yet :)

-Skip

> 
> Scott
> 
>