[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsec error protocol
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
Follow-Ups:
References: