Subject: RE: Comments/questions to l2tp over ipsec draft

From: Ly Loi <[email-masked]>
Date: Fri, 26 May 2000 19:13:10 -0700

Skip, security between the client and the LAC isn't what I was referring to.
In my scenario, the PPP and the LAC can reside on the box, or different
boxes. However, the LAC doesn't reside on the same box as the IPSEC tunnel
initiator.
To be more specific, what I have in mind is a group of LACs sharing 1 IPSEC
SA. This IPSEC SA is between the gateway and the LNS.
                     
LAC1---------gateway------------ipsec_tunnel--------------LNS
LAC2-----------|
LAC3-----------|

Unlike the cases covered by the draft where each L2TP tunnel is mapped to an
IPSEC SA, here, multiple L2TP tunnels map to one IPSEC SA. If the draft
could also cover this case, it'd be more complete. 

A few more comments:

1. Could you not require that L2TP start the retransmission timer only after
the IPSEC SA has come up (section 9.2.2)? I stated the reason in my original
email. In addition, in the above scenario, this requirement wouldn't be
applicable.

2. The draft lists the IPSEC filters as if they represent both the IPSEC
policies and the IPSEC SAs, which is rather confusing since IPSEC SAs are
derived from IPSEC policies. If you could decouple them in your examples,
it'd be great.

3. I don't know how others feel about having an external entity (e.g. L2TP)
injecting some filters into the IPSEC policy database, but this appears to
me to be a local implementation issue. Also, this wouldn't be feasible for
the above scenario. I however appreciate the problems the draft is trying to
solve.

Thanks,

- Ly

> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Friday, May 26, 2000 12:36 PM
> To: Ly Loi
> Cc: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Comments/questions to l2tp over ipsec draft
> 
> 
> 
> 
> On Fri, 26 May 2000, Ly Loi wrote:
> 
> > Skip, I was referring to the case where the LAC and the ipsec tunnel
> > initiator didn't reside on the same device:
> > LAC---gateway(ipsec tunnel initiator)---------------LNS(ipsec tunnel
> > terminator)
> > 
> > Is the draft supposed to cover this case too? This case 
> would be considered
> > compulsory tunneling, ipsec tunneling :-)
> 
> The draft discusses security concerns in the compulsory 
> model.  Specifically, it
> talks about how the link between the client and the LAC is 
> potentially not
> secure and that clients may require end to end security.  If 
> the client is
> running end to end security than potentially no encryption is 
> required for L2TP
> data packets between the LAC and LNS, but authentication may 
> be.  As you noted
> however, currently there is no way standardized method for IPsec to
> differentiate between L2TP data and control packets.
> 
> Does the draft need to go into more detail in this area?  If 
> so what more would
> you like to be discussed?
> 
> > If L2TP and IPSEC reside on the same device, then yes, we 
> all agree IPSEC
> > would run in transport mode and I trust this will be stated 
> in a future
> > version of the draft, thanks.
> 
> Yes.
> 
> -Skip
> 
> > 
> > - Ly
> > 
> 
> [rest of text snipped]
>

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 27 May 2000 11:16:29 -0700

> LAC1---------gateway------------ipsec_tunnel--------------LNS

It appears that you are missing a "security gateway" at the LNS end.

> could also cover this case, it'd be more complete.

I don't think that the point of the draft is to present an exhaustive list
of every method (no  matter how lame) that can be used to "secure" L2TP
tunnels.

---

From: Skip Booth <[email-masked]>
Date: Sat, 27 May 2000 16:29:38 -0400 (EDT)

> could also cover this case, it'd be more complete. 

I have to agree with Glen here.  To me this is really outside the scope of the
L2TP security draft.  This seems to fall into every other IPsec tunnel mode
case here and it doesn't seem to have any specific requirements of L2TP.  If you
think otherwise, then please feel free to specify what we are missing and the
group can decide whether these need to be added to the draft.

> email. In addition, in the above scenario, this requirement wouldn't be

Again, I think the draft specifically addresses an implementation where IPsec
and L2TP exist on the same device.  In this case, the text in section 9.2.2
seems to make sense to me.  We can change this to a MAY just to lesson the
requirements of implementations which do not want to have this type of
mechanism.  However, given the amount of time it can take to establish the phase
1/2 SAs, implementations should consider this as a design objective for their
retransmit timers.  Otherwise, with the exponential backoff that is designed
into L2TP, we could be into the 2 to 4 second retransmit period.  In some
extreme situations, even 8 seconds.  That was the reason I added the text on
when to send the SCCRQ.  I would like to hear some feedback from other on
whether this should be a SHOULD or a MAY before we make the change.

> derived from IPSEC policies. If you could decouple them in your examples,

Is this just a semantics issue for you?  In reality they are filters and we just
like to call them policies.  Every implementation I have ever looked at
specifies this as filters and then associates the filters with a security
policy.  I would prefer to keep the semantics as filters since that allows us to
talk about inbound and outbound filters vs inbound and outbound policies which
doesn't seem to make as much sense to me.  Again I certainly am willing to make
this change however I would like to see some consensus by the group on whether
this actually makes the draft more or less readable/accurate.

> the above scenario. I however appreciate the problems the draft is trying to

If you are a LNS only and you only support connections on port 1701 then you do
not have to worry about injecting filters.  However if you are a LAC then you
MUST be able to do this to handle the ability for the LNS to float it's port
(Port floating is defined in the L2TP RFC). We went through this in much detail
and could not arrive at a solution which allowed the L2TP engine not to inject
filters without either 1) opening up security holes, 2) decreasing
functionality.  The security holes dealt with the LAC or LNS having to open up
it's port range for all traffic vs just L2TP traffic.  The decrease in
functionality was not allowing L2TP security implementations from moving ports
or addresses.  The solution in the draft accomdates both of these and allows
only L2TP traffic to be sent through the IPsec SAs.

-Skip