Subject: [Fwd: RE: securing L2TP using IPSec (fwd)]

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 07 Jan 2000 09:31:04 -0500

Posting for Skip Booth, who might be having some majordomo troubles with
ipsec.org. This is in response to the thread that Bernard and William
began before the holidays.

- Mark

---------- Forwarded message ----------
Date: Thu, 6 Jan 2000 22:57:47 -0500 (EST)
From: Skip Booth <[email-masked]>
To: [email-masked]
Subject: RE: securing L2TP using IPSec (fwd)

I've been spending some time on this issue as of late and wanted to
share my
thoughts.  I would like to spend some time on this next week at the
bakeoff if
any cares to join me.  Certainly any comments on list are welcomed as
well.

-Skip Booth

L2TP-Security draft, comments on IKE negotiations and filtering
----------

Since L2TP allows for either the LAC or the LNS to choose their UDP port
a
combination of static and dynamic filters must be implemented.  The
static
and dynamic filters are described below followed by how they should be
implemented.

Cases:

1) LAC uses fixed port (1701) and the LNS uses fixed port (1701)
2) LAC uses dynamic port (ANY) and the LNS uses fixed port (1701)
3) LAC uses fixed port (1701) and the LNS uses dynamic port (ANY)
4) LAC uses dynamic port (ANY) and the LNS uses dynamic port (ANY)

The other part that may be dynamic is the LNS's IP Address.  There have 
been discussions recently of the L2TP mailing list about the ambiguity
of
in the L2TP RFC (2661) about whether the LNS is allowed to change their
IP
Address as well as their port number.  It has appears to be the
consensus
that most implementations of L2TP would allow for this behaviour.  It
has
been noted that this would be a useful feature for load-balancing at the
LNS.  As a result I have depicted the most general case for L2TP tunnel
establishment below:

SCCRQ (LAC-IPAddr,  LACPort   -> LNS-IPAddr,  1701)
SCCRP (LNS-IPAddr1, LNSPort1, -> LAC-IPAddr,  LACPort)
SCCCN (LAC-IPAddr,  LACPort,  -> LNS-IPAddr1, LNSPort1)

To this point, there have been two proposals about how to setup static
filters to protect L2TP traffic.  For a history lesson I will show these
below and talk about why they are not satisfactory:

Note: When ANY is mentioned in the Port then a 0 should be negotiated
for
the quick mode port.

1st Proposal (The one found in the l2tp-security draft):
------------
	    LAC Phase 2 Proxy		  LNS Phase 2 Proxy 
	    -----------------		  -----------------
	    Local	Remote            Local       Remote
	 +-----------------------+----+-------------------------+
Address  | LAC Addr  | LNS Addr  |    |  LNS Addr  |  ANY Addr  |
	 +-----------------------+    +-------------------------+
Protocol |          17		 |    |           17            |
	 +-----------------------+    +-------------------------+
Port     | ANY Port  |  1701     |    |   1701     |  ANY Port  |
	 +-----------------------+----+-------------------------+

Comments:
This proposal covers two of the (IMO most common) cases.  The first
case is when the LAC and LNS both stay of ports 1701 and the second case
when the LAC choses it's own port but the LNS stays on 1701.  It does
not
satisfy any of the cases where the LNS chooses a new port or a new
address.

2nd Proposal (Proposed by William Dixon):
------------
	    LAC Phase 2 Proxy		  LNS Phase 2 Proxy 
	    -----------------		  -----------------
	    Local	Remote            Local       Remote
	 +-----------------------+----+-------------------------+
Address  | LAC Addr  | LNS Addr  |    |  LNS Addr  |  Any Addr  |
	 +-----------------------+    +-------------------------+
Protocol |          17		 |    |           17            |
	 +-----------------------+    +-------------------------+
Port     |    1701   |  ANY Port |    |  ANY Port  |   1701     |
	 +-----------------------+----+-------------------------+

Comments:
This proposal covers two cases.  The first case is when the LAC and LNS
both stay on port 1701 and the second case is when the LNS chooses a new
port and the LAC stays on 1701.  I believe this set of filters exposes
the
security issues to the LNS.  Since the LNS filter definition must open
his
ports up to ANY, then non-L2TP traffic can be sent to the LNS and IPSec
would not protect against this.  The only thing that this proposal
insures
is that the LAC must originate the traffic on a source port of 1701, but
this does not necessary mean that it is L2TP traffic.  Clients are free
to
choose any port they want.  It opens the LNS up to receiving any UDP
traffic such as TFTP, SNMP, Routing updates via RIP, etc.  Although you
can
argue that for someone to do this, they have to be a) authenticated via
IKE
which implies a level of trust, b) savy and malicious enough to know how
to
send non L2TP traffic to the LNS with their source port set to 1701.
Although this is unlikely if there are better solutions present I don't
think this proposal should be our first choice.

Summary:
Neither Proposal 1 or 2 cover all of the cases.  IMO Proposal 1 covers
the
more common cases and has no security holes while proposal 2 does.  Thus
if
we want to define the simple, static filter case we should go with
proposal
1.  I would also like to consider the following proposal which covers
all
the cases at the expense of being somewhat more complex.

Proposal 3 (New and proposed by Me, although this follows closely what
Bernard
has proposed)
----------

Definitions:
LACPort == Port LAC chooses to originate/receive L2TP traffic on.  This
can
be a static port such as 1701 or a dynamic one assigned by the socket. 
In
either case only L2TP is registered on this port.

LNSPort ==  Port LNS chooses to originate/receive L2TP traffic on.  This
can be the IANA assigned L2TP port number 1701 or can move to a new port
number on the SCCRP.

LNSAddr1 == New IP Address the LNS chooses before sending the SCCRP. 
This
address should now be used by the LAC for all future traffic to the LNS.

ANY Port == Accept any port or a specific port during IKE negotiations.

Step 1:
-------
Protect the SCCRQ from the LAC to the LNS.  

LAC Implementation notes:
It is up to the implementation on whether the LAC filter needs to
be dynamically injected or defined statically.  Regardless the LAC MUST 
negotiate the specific port it has chosen for it's source port for L2TP.

LNS Implementation notes:
The LNS filter MAY be statically configured and MUST only be used to
respond to phase II quick mode negotiations.  Since the remote address
is
unknown this filter MUST NOT be used to initiate a phase II.

LAC: Initiator, LNS: Responder

	    LAC Phase 2 Proxy		  LNS Phase 2 Proxy
	    -----------------		  -----------------
	    Local	Remote            Local       Remote
	 +-----------------------+----+-------------------------+
Address  | LAC Addr  | LNS Addr  |    |  LNS Addr  |  Any Addr  |
	 +-----------------------+    +-------------------------+
Protocol |          17		 |    |           17            |
	 +-----------------------+    +-------------------------+
Port     | LACPort   |   1701    |    |    1701    |  ANY Port  |
	 +-----------------------+----+-------------------------+

A set of phase II SAs will exist once the quick mode negotiation
finishes
and the resulting dynamic filter would be present at the LNS:

Prot 17, LACAddr, LACPort --> LNS Addr, 1701
Prot 17, LNSAddr, 1701    --> LAC Addr, LACPort

Step 2: 
-------
Protect the SCCRP sent from the LNS to the LAC.  In this case a new
phase II might need to be negotiated (port change or LNS addr changes)
and
potentially a new phase 1 (if LNSAddr1 != LNSAddr).  If renegotiation
occurs
the LNS now becomes the initiator.  The original Phase II and Phase I
SHOULD NOT be deleted since they may still be reused for new L2TP
tunnels
between these peers.

LAC Implementation NOTES:

This should be a phase II responder only policy.  No phase II's should
be
initiated from via a match on this filter.  It also MUST have a lower
priority than the filter defined in step 1 for the LAC since it is more
generic.  If a LAC chooses a source port of 1701 (LACPort == 1701), then
this filter MAY be statically defined.

LNS Implementation NOTES:
If the LNS decides to move to a new LNSAddr1 or LNSPort then L2TP MUST
inject a new filter with the new information.  This would result in a
new
phase II being negotiated.  If LNSAddr1 != LNSAddr then a new phase 1
MUST
be negotiated with the LAC. If everything remains the same then the
phase
I and phase II established in step 1 will be used to protect the SCCRP. 
If
a new filter is injected this filter must have a higher priority than
the
filter defined in step 1 since it is more specific.

LAC: Responder, LNS: Initiator

	    LAC Phase 2 Proxy		  LNS Phase 2 Proxy 
	    -----------------		  -----------------
	    Local	Remote            Local       Remote
	 +-----------------------+----+-------------------------+
Address  | LAC Addr  | ANY Addr  |    |  LNSAddr1  |  LAC Addr  |
	 +-----------------------+    +-------------------------+
Protocol |          17		 |    |           17            |
	 +-----------------------+    +-------------------------+
Port     | LACPort   |   ANY     |    |   LNSPort  |  LACPort   |
	 +-----------------------+----+-------------------------+

If the LNS changes either their source address or their source port, a
new
set of phase II SAs will exist once the quick mode negotiation finishes
and the resulting dynamic filter would be present at the LNS:

Prot 17, LACAddr,  LACPort --> LNSAddr1, LNSPort
Prot 17, LNSAddr1, LNSPort --> LACAddr,  LACPort

NOTE: Any dynamically injected filters MUST be present until after L2TP
tears down the tunnel by sending a STOPCCN.  This is must be so to
handle
the occasional phase 1/phase 2 renegotiation IKE performs.

Examples using proposal 3 (Both LAC and LNS chose ports):

SCCRQ (10.0.0.1,  5000 -> 10.0.0.2, 1701)
SCCRP (10.0.0.2,  6000 -> 10.0.0.1, 5000)
SCCCN (10.0.0.1,  5000 -> 10.0.0.2, 6000)

1) LAC send SCCRQ to LNS.  Matches outbound filter on LAC. Packet queued
or dropped by IPSec Engine and Phase 1 and 2 request are started.  L2TP
on
the LAC installs a new filter into the IPSec filter database.  The
filter
will allow IPSec to respond to quick mode negotiations to the LAC IP
address, with UDP packets sent to port 5000.

2) Phase 1 establishes between 10.0.0.1 and 10.0.0.2
3) Phase 2 is initiated from LAC to LNS with the proxy as follows:

	Local:	Addr = 10.0.0.1
		Prot = 17
		Port = 5000
	Remote: Addr = 10.0.0.2
		Prot = 17
		Port = 1701

This will be matched by the LNS and quick mode completes.

4) The SCCRQ is retransmitted from the LAC, protected by the SA
established
in step 3 and received by the LNS.  L2TP chooses a new port number of
6000
and injects a filter into the IPSec filter database.  

5) The SCCRP is sent out to the LAC.  This packet matches the new filter
injected in step 4 and the LNS initiates a new phase 2 to the LAC.  The
proxy would be as follows:

	Local:	Addr = 10.0.0.2
		Prot = 17
		Port = 6000

	Remote: Addr = 10.0.0.1
		Prot = 17
		Port = 5000

This phase 2 exchange would match the newly injected filter which the
LAC
install in step 1.  The phase 2 would complete successfully and all UDP
traffic
between 10.0.0.1/5000 and 10.0.0.2/6000 would be protected by ipsec.

On Thu, 25 Nov 1999, Bernard Aboba wrote:

> a. The LNS IKE MM policy will look like: "accept MM from any IP addr".
> b. The LNS IKE QM policy will look like:
> 
> LNS Filters (static):
> 
> From <Any IP> to <LNS IP>, protocol UDP, source port Any, dest port 1701
> 
> Then, when the LNS completes the IKE MM negotiation, receives the first
> packet from the LAC, and chooses the port to reply on, but before sending
> the reply, it can plumb the following dynamic policy:
> 
> LNS Filters (dynamic):
> 
> From <LNS IP> to <LAC IP>, protocol UDP, source port <chosen>, dest port
> <chosen>
> 
> To avoid a race condition, the dynamic policy MUST be effective before the
> LNS sends its reply. Otherwise, the reply might not be IPSEC protected. It
> is possible that this could take so long that the LAC could time out and
> retransmit.
> 
> 
> 
> -----Original Message-----
> From: William Dixon [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 5:29 PM
> To: [email-masked]'; [email-masked]; [email-masked]
> Subject: RE: securing L2TP using IPSec
> 
> 
> Yes in the dynamic case the LAC can plumb filters based on it's chosen port.
> But the LAC then initiates IKE to the LNS (before sending any L2TP traffic).
> How will the LNS know to agree to this chosen source port?  Normally it
> can't.  The LNS policy would have to say:
>    From LAC IP, to LNS IP, Any source, Any dest port
> 
> You could configure each LAC with a source port range, so LNS policy is
> specific to the LAC IP for that range, or just specific to a source port
> range.
> 
> When many LACs are involved, inbound policy on the LNS just agrees to secure
> all UDP to/from any IP address.  Now for dedicated boxes, this might be ok.
> But the IPSec policy on the LNS would interfere with other IKE requests to
> secure different UDP traffic.
> 
> I should have also said that the solution presented dealt only with using
> IKE MM/QM.  Because the vendors at that discusion had all implemented MM/QM.
> Having multiple uses of IPSec to secure different UDP port applications
> brings up the issue that there is already a conflict with this approach -
> namely that IKE main mode policy can at best be IP address specific, not
> port specific.  The configuration presented has one main mode policy used to
> reply to all LACs.  There's nothing we can do about this in the RFC2401
> series documents with Main Mode & Quick Mode, except not to use those modes,
> instead use Aggressive Mode.
> 
> I'll have to go back to check, but I didn't think Aggressive Mode allowed
> the use of Certificate Request Payloads, just allows a cert to be presented.
> So this may work, but none of us had experience with this configuration.
> 
> Has anyone on the list used an Aggressive Mode configuration to secure L2TP?
> For the purpose of allowing other UDP services to be protected differently ?
> 
> Wm
> 
> ---------------
> >From <LAC IP> to <LNS IP>, protocol UDP, source port <chosen>, dest port
> Any
> >From <LNS IP> to <LAC IP>, protocol UDP, source port Any, dest port
> <chosen>
> 
> This will cover the case where the LNS and LAC *both* do dynamic port
> assignment.
> 
> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, November 24, 1999 12:16 AM
> To: [email-masked]; [email-masked]
> Subject: RE: securing L2TP using IPSec
> 
> 
> >How is it done?
> 
> Here's are some rough thoughts on how this might work:
> 
> LAC Filters (static):
> 
> >From <LAC IP> to <LNS IP>, protocol UDP, source port Any, dest port 1701
> >From <LNS IP> to <LAC IP>, protocol UDP, source port 1701, dest port Any
> 
> These filters will cause IKE to be kicked off when the LAC initiates
> L2TP to the LNS, and will also protect the return traffic if the LNS
> is also using static port assignment.
> 
> Prior to sending the first packet, the LAC can also plumb dynamic
> filter policy once it knows what port it will be sending on:
> 
> LAC Filters (dynamic):
> 
> >From <LAC IP> to <LNS IP>, protocol UDP, source port <chosen>, dest port
> Any
> >From <LNS IP> to <LAC IP>, protocol UDP, source port Any, dest port
> <chosen>
> 
> This will cover the case where the LNS and LAC *both* do dynamic port
> assignment.
> 
> Note that to avoid race conditions it is safest if the dynamic filter policy
> takes effect before the initial L2TP packet is sent by the LAC.
> This will ensure that after the initial IKE negotiation completes setting
> up the first IPSEC SA and the LNS responds, thereby kicking of a QM
> negotiation for the additional (dynamic) SA, that the LAC will be
> prepared for it. Otherwise, the second QM negotiation could fail.
> 
> 
>