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

From: Ly Loi <[email-masked]>
Date: Tue, 30 May 2000 09:19:39 -0700

Skip, see comments below.

> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Saturday, May 27, 2000 1:30 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, 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. 
> 
> 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.

Well, the title of the draft encompasses the IPSEC tunnel case, so I
expected that scenario to be included. Since the draft is rather
implementation-specific, one has to remember that all of its proposals apply
only to IPSEC in transport mode when L2TP and IPSEC are located in the same
box. May be the title should be changed to "Securing L2TP Using IPSEC in
transport mode"? :-)

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

I believe the L2TP exponential backoff gives IPSEC plenty of time to
establish a phase1 and phase2 SAs. If you assume a L2TP retransmission count
of 5, as recommended by the L2TP RFC, you'd have 1+2+4+8+8 = 23 secs. If
IPSEC takes longer than 23 secs to come up, L2TP should time out. But
without the L2TP retransmission timer running, how is it going to time out?
Also, I'd like L2TP to be unaware of IPSEC as much as possible. L2TP should
run its retransmission timer regardless of whether IPSEC is
running/configured. If for any reason (ipsec, infra-structure, network, etc)
L2TP can't come up, L2TP should time out.

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

You hit the nail on the head. IPSEC doesn't refer to policies as inbound vs
outbound, only SAs. This draft however talks about inbound/outbound filters.
My interpretation of the draft is that if it's talking about the
configuration before the L2TP/IPSEC negotiations, the filters represent the
IPSEC policies, thus the term 'inbound/outbound filters' are
misleading/confusing. If it's talking about the configuration after the
L2TP/IPSEC negotiations, the filters represent the inbound/outbound SAs,
which is also confusing since previously, they represented IPSEC policies. 

To answer your question, if my interpretations of the draft (as stated in
the above paragraph) are correct, then 'yes', it's a semantics issue.

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

I understand. However, you are limiting the user to configuring an IPSEC
policy that's applicable only to L2TP. What if the user wants an IPSEC
policy that says for example "I want to encrypt all L2TP traffic and PPTP
traffic"? By implementing the draft, you would have removed the PPTP policy
or one has to be careful in not modifying the whole policy.
I'd like to suggest that the injection of new filters into the IPSEC policy
database be changed from a 'must' to a 'should' or 'may'. From an
implementation and user configuration's point of view, the vendor can always
offer a knob to the user to allow for automatic injection of policies in the
IPSEC policy database should the user desire such behavior; then internally
in the code, the injection could take effect. Otherwise, I don't think we
should make an assumption about what the user wants. What do you think?

Thanks,

- Ly

> 
> -Skip
> 
> > 
> > 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: Ly Loi <[email-masked]>
Date: Tue, 30 May 2000 10:21:27 -0700

Skip, my example below regarding configuring "I want to encrypt all L2TP
traffic and PPTP traffic" isn't allowed by IPSEC, so never mind this
example; sorry about that. But I still would like to see the injection not
be a requirement.

- Ly

> From: Ly Loi 
> Sent: Tuesday, May 30, 2000 9:20 AM
> To: 'Skip Booth'; Ly Loi
> Well, the title of the draft encompasses the IPSEC tunnel 
> case, so I expected that scenario to be included. Since the 
> draft is rather implementation-specific, one has to remember 
> that all of its proposals apply only to IPSEC in transport 
> mode when L2TP and IPSEC are located in the same box. May be 
> the title should be changed to "Securing L2TP Using IPSEC in 
> transport mode"? :-)
> 
> > 
> > > 
> > > A few more comments:
> > > 
> I believe the L2TP exponential backoff gives IPSEC plenty of 
> time to establish a phase1 and phase2 SAs. If you assume a 
> L2TP retransmission count of 5, as recommended by the L2TP 
> RFC, you'd have 1+2+4+8+8 = 23 secs. If IPSEC takes longer 
> than 23 secs to come up, L2TP should time out. But without 
> the L2TP retransmission timer running, how is it going to 
> time out? Also, I'd like L2TP to be unaware of IPSEC as much 
> as possible. L2TP should run its retransmission timer 
> regardless of whether IPSEC is running/configured. If for any 
> reason (ipsec, infra-structure, network, etc) L2TP can't come 
> up, L2TP should time out.
> 
> > 
> > > 
> You hit the nail on the head. IPSEC doesn't refer to policies 
> as inbound vs outbound, only SAs. This draft however talks 
> about inbound/outbound filters. My interpretation of the 
> draft is that if it's talking about the configuration before 
> the L2TP/IPSEC negotiations, the filters represent the IPSEC 
> policies, thus the term 'inbound/outbound filters' are 
> misleading/confusing. If it's talking about the configuration 
> after the L2TP/IPSEC negotiations, the filters represent the 
> inbound/outbound SAs, which is also confusing since 
> previously, they represented IPSEC policies. 
> 
> To answer your question, if my interpretations of the draft 
> (as stated in the above paragraph) are correct, then 'yes', 
> it's a semantics issue.
> 
> > 
> > > 
> I understand. However, you are limiting the user to 
> configuring an IPSEC policy that's applicable only to L2TP. 
> What if the user wants an IPSEC policy that says for example 
> "I want to encrypt all L2TP traffic and PPTP traffic"? By 
> implementing the draft, you would have removed the PPTP 
> policy or one has to be careful in not modifying the whole policy.
> I'd like to suggest that the injection of new filters into 
> the IPSEC policy database be changed from a 'must' to a 
> 'should' or 'may'. From an implementation and user 
> configuration's point of view, the vendor can always offer a 
> knob to the user to allow for automatic injection of policies 
> in the IPSEC policy database should the user desire such 
> behavior; then internally in the code, the injection could 
> take effect. Otherwise, I don't think we should make an 
> assumption about what the user wants. What do you think?
> 
> Thanks,
> 
> - Ly
> 
> > 
> > -Skip
> > 
> > > 
> > > Thanks,
> > > 
> > > - Ly
> > > 
> > > 
> > > 
> > > 
> > >