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

Re: Out of Sync Security Policies - Design Flaw



----- Original Message ----- 
From: Andrew Krywaniuk <andrew.krywaniuk@alcatel.com>
To: 'Kim Edwards' <kimed@nortelnetworks.com>; 'ipsec' <ipsec@lists.tislabs.com>
Sent: Wednesday, November 08, 2000 9:25 PM
Subject: RE: Out of Sync Security Policies - Design Flaw


> I've said this before and I'll say it again.
> 
> The reason these issues occur is because IKE is (among other things) a
> policy enforcement protocol which some people want to use as a policy
> discovery protocol.
> 
> The same types of issues come up with the cert request payload and, to a
> lesser extent, exploded SA proposals.
> 
> Selectors shouldn't need to be negotiated. They should either be known to
> both peers or they should be discovered independently by each peer (by
> taking the intersection of two policy rule sets) and then the resulting
> policy should be enforced by each peer.
> 
> The purpose of the negotiation phase is merely to confirm that both sides
> arrived independently at the same result. That is the only sane way to do

Andrew,

if you were right, then what is the purpose of multiple SA proposals in IKE?
One proposal would be enough.

The fact is that IKE *has* some kind of policy negotiation capabilities,
but they are limited.

Regards,
Valery.

> it.
> 
> Andrew
> --------------------------------------
> Beauty with out truth is insubstantial.
> Truth without beauty is unbearable.
> 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kim Edwards
> > Sent: Tuesday, November 07, 2000 11:44 AM
> > To: ipsec
> > Subject: Re: Out of Sync Security Policies - Design Flaw
> >
> >
> > Markku,
> >
> > I cannot see how your solution will prevent the scenario I
> > mentioned in
> > my first posting to the mailing list. The problem lies with the fact
> > that we are not negotiating policy selectors. Therefore, the responder
> > SA has different policy selectors than the initiator's SA
> > which leads to
> > my initial problem of not negotiating a new IPsec SA for ICMP traffic.
> > The initiator will attempt to pass the ICMP traffic across
> > the first SA
> > it negotiated, but the responder will discard this protected ICMP
> > traffic as the policy selectors in its SA are for TCP traffic only.
> >
> > Markku Savela wrote:
> >
> > > > From: EXT Kim Edwards [mailto:kimed@nortelnetworks.com]
> > > >> I believe that a third Id payload would be required:
> > > >
> > > > - Id payload for Initiator's security policy selectors
> > > > - Id payload for Responder's security policy selectors
> > > > - Id payload for Initiator's packet selectors
> > >
> > > Another solution is totally disable policy checking from IKE.
> > >
> > > Kernel has to do it anyway for each packet as described in RFC-2401.
> >
> > Kim
> >
> 
> 



Follow-Ups: References: