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

Re: IPSec Complexity

  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"

  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: