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

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
Follow-Ups: References: