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

RE: ipsec error protocol

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: