[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: