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

Re: ipsec error protocol



so much my reading. sorry, I have been too quick.

Now, rereading, I still have a few remarks:

. you use a special SPI to carry the packet but you also have to carry the SPI being probed *in the clear* in the packet (so the remote side can possibly respond). Which means the packet also has to be authenticated (or the SPI could be tampered with). You then have to assume the SA you probe has keys for encrypting and authenticating while in practice, it could be an AH related SA or ESP with encryption only (solution ?)

. you need 3 packets and a number of timeouts before deleting the SA and only restarting some IKE negotiation (slow)

. you still can not decide if you restart just a phase 2 or also a phase 1 (e.g. If the phase 2 SA was administratively deleted on one host and the notification lost, we may still have a phase 1 available and phase 2 could be enough).

. last but not least, because you force the IPSec stack to send a deterministic response in exchange of something known, you offer cribbles to the attacker. This is something that we never see appearing anywhere else in IPSec, I believe. I think you introduce a weakness in IPSec, in particular on the DATA session key (again, cryptographers...).

(same in my case but I only weaken the phase 1 session key + the fact that IKE already offers *many* cribbles BUT (solution) you can protect the phase 2 session keys with PFS. You have no such solution).



(and sorry again for having misread).

regards,

	frederic


sankar ramamoorthi wrote:
> 
> Can u help me understand how you came to the conclusion that the series of
> steps
> I described is a keepalive mechanism. There are no keepalive or
> acknowledgement
> packets till the sender receives an error notification at which it can
> choose
> to follow the series of steps outlined to ensure the error message it
> received
> is genuine and react to it appropriately. How is this a keepalive mechanism?
> 
> -- sankar --
> 
> -----Original Message-----
> From: fdetienn@cisco.com [mailto:fdetienn@cisco.com]On Behalf Of
> Frederic Detienne
> Sent: Thursday, January 18, 2001 6:25 AM
> To: sankar ramamoorthi
> Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com
> Subject: Re: ipsec error protocol
> 
> So this is a keepalive mechanism. And I think we have seen a number of them
> already. But all keepalives have the same problems: they consume bandwidth
> and rely on timers (slow convergence). Acknowledgements are much more
> efficient in terms of bandwidth: the consume less than 1/2 bandwdith of
> keepalives (esp. in low traffic conditions).
> 
> I prefer notifications but I admit notifications can be lost and are subject
> to rate limiting.
> 
> So honestly, I'd still vote for a dual notification/acknowledgment system
> (with each piece configurable). NOT for any sort of keepalive mechanism; we
> have seen too many problems in the field.
> 
> regards,
> 
>         frederic detienne
> 
> sankar ramamoorthi wrote:
> >
> > Actually it works like this
> >
> > When a sending IPsec receives unknown spi error (let us say as
> > an ipsec control packet using the reserved spi) it can do the
> > following to ensure that is is a valid error message before asking
> > IKE to recreate the SA
> >
> >   check if the spi from the sender matches any of its ipsec sa.
> >   If not ignore the error message.
> >
> >   send an encrypted ping command for the sa in question and send
> >   it using the ipsec control packet. The payload of the control packet
> >   contains an encrypted ping encapsualted by an ESP header with the SPI
> >   of the SA in question. If the original error message
> >   is genuine the peer will not be able to decrypt it and silenty
> >   drop the packet (similiar to icmp, control packets do not generate
> >   more control packets). The sender after a number of retries can
> >   assure itself that the SA has gone stale for good and request IKE
> >   to recreate the ipsec SA.
> >
> >   On the other hand if the first error was a spurious one, the
> >   encrypted pings will be successfully decrypted by the receiver.
> >   The receiver will send the encrypted echo-replies in the ipsec control
> >   packet and the sender can now knows the SA is still valid.
> >   It can safely ignore the initial error message or go tracking
> >   the sender of the initial message.
> >
> > Thus DOS problem can be avoided.
> >
> > -- sankar --
> >
> > -----Original Message-----
> > From: goofy@cisco.com [mailto:goofy@cisco.com]On Behalf Of Frédéric
> > Detienne
> > Sent: Wednesday, January 17, 2001 10:09 PM
> > To: sankar ramamoorthi
> > Cc: sommerfeld@east.sun.com; Scott G. Kelly; ipsec@lists.tislabs.com
> > Subject: Re: ipsec error protocol
> >
> > Agree but let me reverse the argument: once IPSec has detected the
> problem,
> > what can it do on its own ? Little but asking IKE to fix it...
> >
> > Notice that I see your point: you'd let IPSec delete the offending SA and
> > the lack of SA on the sender side would trigger IKE as it exists today and
> > the tunnels would be recreated. But as I was telling you: you had the
> choice
> > of the transportation method and you chose a dedicated SA. But you do not
> > tell us what to do with it...
> >
> > Now, if you think of it: IPSec *does* detect the problem (unknown SPI
> > received). And it is simply asking IKE to do something about it. We just
> > give IKE the possibility to do something without opening a DoS door.
> >
> > It is not very different than the usual case: IPSec misses an outbound SA
> > and it asks IKE to fix it (and IKE negotiate SA's on the fly).
> >
> > Now, maybe we could start criticizing the exchange itself... and see if we
> > can improve it or forget it. Is everyone filtering out threads on recovery
> > mechanisms ? :)
> >
> >         frederic
> >
> > sankar ramamoorthi wrote:
> > >
> > > Yes, the primary reason for the existance of ike is to establish and
> > > destroy ipsec state, but not vice-versa ie: ipsec state can exist
> > > independent of ike state once established. Also ipsec sa can be created
> > > independent of IKE (manual sa).
> > >
> > > We have had a number of arguments in the past about dangling ipsec SAs
> > > and the general consensus was that ipsec-sa can exist independent of
> > ike-sa.
> > >
> > > IMHO, creating an ike-sa to handle ipsec state synchronization seems
> > > to avoid the real issue, which is the lack of an error mechanism for
> > ipsec,
> > > similar to what ip has (ie: icmp).
> > >
> > > -- sankar --
> > >
> > > -----Original Message-----
> > > From: sommerfeld@thunk.east.sun.com
> > > [mailto:sommerfeld@thunk.east.sun.com]On Behalf Of Bill Sommerfeld
> > > Sent: Wednesday, January 17, 2001 6:18 PM
> > > To: sankar ramamoorthi
> > > Cc: fd@cisco.com; sommerfeld@east.sun.com; Scott G. Kelly;
> > > ipsec@lists.tislabs.com
> > > Subject: Re: ipsec error protocol
> > >
> > > > 1. Extending IKE (with new payloads etc) to what is basically an ipsec
> > > > problem seems to be an incorrect.
> > > >    If ipsec state (ipsec-SA) is out of sync between two peers, it
> should
> > > be
> > > > dealt in ipsec.
> > >
> > > this is a weak argument; the primary reason for the existance of ike
> > > is to establish and destroy ipsec state.
> > >
> > >                                 - Bill

-- 
------------------------- * oOo * -------------------------
                     Frederic Detienne
              Cisco Systems Escalation Engineer
                 Security & Network Services

                     Tel 32 2 704 55 55


Follow-Ups: References: