[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSec Complexity





On Fri, 18 Feb 2000, Dan Harkins wrote:

>   It's not just deciding whether to protect a certain flow with 3DES and
> SHA and the other with DES and MD5 (your example). A selector can also
> specify an action of "drop". If you tunnel something through UDP and 
> do IPSec protection on the UDP traffic then you're opening up your entire 
> network to whatever the peer decides to put in the tunnel. 
> 
>   You're right that most people won't really care that much whether FTP
> and telnet have different algorithms applied to protect them but they
> would probably care if putting a protect selector for L2TP, e.g.
> 	       "10.10.10.1 udp <---> 172.16.2.1 udp 1701 protect"
> would implicitly make a bypass selector for everything, e.g.
> 	       "any <--> any allow"

The default filter in the SPD MUST be discard. So I don't think you are talking
about the non-L2TP traffic since unless there are explicit pass statements in
the SPD for the non-L2TP traffic the packets will be dropped.

I assume you are talking about the traffic within the L2TP+IPSEC tunnel.  You
are right that without additional filters on the PPP interfaces associated with
the secure tunnel, all traffic is permitted as long as it arrived on the SA
bundle protecting L2TP.  On the other hand, if only FTP and Telnet traffic is
permitted to servers X, Y, and Z, these filters could be defined on the PPP
interface.  This configuration moves very transparently in this case, since in
many cases you are essentially replacing a leased/dialup line running PPP with a
virtual PPP interface running on top of secure IP.

-Skip

> 
>   Dan.
> 
> On Fri, 18 Feb 2000 10:36:17 EST you wrote
> > 
> > On Fri, 18 Feb 2000, Stephen Kent wrote:
> > 
> > > Skip,
> > > 
> > > Unfortunately, IPsec over L2TP looses many of the access control 
> > > features of IPsec, because the receiver no longer examines the inner 
> > > IP header to see if it matches the selectors for the SA via which the 
> > > packet arrived.  Since the SA binding is lost as soon as the packet 
> > > leaves the IPsec processing, no later filtering can provide the same 
> > > sort of checks.
> > 
> > This argument has been made many at time so I doubt I am going to shed very m
> >uch
> > new information on it.  However, my perception is that the only loss incurred
> > is
> > the ability to provide different levels of security for different traffic
> > between two peers.  For instance the ability to say, FTP traffic gets 3DES an
> >d
> > SHA with lifetimes of 10 min and Telnet gets DES and MD5 with as lifetime of 
> >15
> > minutes.  Since the traffic is hidden underneath the PPP header for L2TP you
> > lose this ability.
> > 
> > In terms of pure access control, the filters can be applied to the PPP interf
> >ace
> > and achieve the same result as if they were applied to the IPSEC tunnel.  Aga
> >in
> > the only loss is that the PPP interface can not tell which SA the packet arri
> >ved
> > on, but it does know that they packet was at least secured with the appropria
> >te
> > L2TP security policy.
> > 
> > I am not sure how many customers are really going to worry whether there FTP
> > traffic has different security parameters than their telnet traffic.  I think
> > for the most part, they will have one security policy for their VPN, and in t
> >his
> > case, L2TP should do just fine.  The simplicity argument will most likely
> > prevail in this case.
> > 
> > -Skip
> > 
> > > 
> > > Steve
> > > 
> > > 
> > 
> 
> 



Follow-Ups: References: