[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re : Error recovery ?
Hi,
>Hans-Joachim Knobloch
wrote:
> Consider the case that two hosts communicate via two IPSec
security
>
gateways
>
A <---> SG1 <-----> SG2 <---> B
>
> and that
appropriate ISAKMP and IPSec SAs are established. Let us call
> these SAs
SA1, SA2AB and SA2BA respectively.
> Now what happens, when SG2 is
reset?
>
> When B sends a packet to A everything should be fine,
since SG2 will
> initiate new phase 1 and phase 2 exchanges.
> But
what if A sends a packet to B? SG1 will process the packet with the
> old
IPsec SA2AB and SG2 will receive a packet with a most probably unknown
>
SPI. Is this supposed to happen until SA2AB does "naturally
expire"?
> Do we have to set SA lifetime short enough and/or hope
that B will also
> send a packet more sooner than
later?
Currently, there is no standard way to do
this and I guess it is left
to the implementation.
For
phase1 SA:
Assume SG1 has phase1 SA where as SG2 does not
have corresponding
phase1 SA.
If
phase2 is initiated by SG2, there is no problem,because it
negotiaties
new phase1 SA with the
SG1.
If phase2 is initiated by SG1, then the SG1 never
receives second
quick mode message, since SG2 does not
have phase1 SA.
SG1 quick mode negotiation fails and then
SG1 can take action based
on implementation. In our
implementation, we delete the phase1 SA
if the
initiator(SG1) does not receive second message for all
retries.
( Note that we have configuration option to do
this or not ).
For phase2 SA:
This is
tricky.
Again here, assume SG1 has phase2 SA whereas SG2
does not have
corresponding phase2
SA.
If the packet comes on SG2 destined to SG1, there
is no problem as
SG2 negotiates new phase2
SA.
If the packet comes on SG1 destined to SG2, SG1
applies security
and sends it to the SG2 and SG2 drops the
packet. There will be
no packets transferred between
these two SG for that session.
Here, following can be
done:
Using IKE, you always get two SAs. One for oubound
and other for
inbound.
Here, I feel
we can use some sort of timeouts.
That is whenever packet
is sent, start software timer with some
preconfigured
value ( say 5 minutes )
Whenever packet is receieved on
the corresponding inbound SA,
then disable the timer on
the outbound SA.
If no packets are received within 5
minutes on inbound SA, then
delete both
SAs.
Here, basic assumption is that the there will be
always some packets
coming inbound within 5 minutes after
sending any outbound packet.
This mechanism still works
otherwise, but at the expense of one
quick mode
negotiation.
>
> Alternatively one
could imagine that SG2 sends SG1 some kind of
> (ICMP?) message to tell it
to invalidate SA2AB. But then, this might be
> abused by an attacker to
cause unnecessary ISAKMP traffic and a service
> disruption until new SAs
are installed.
>
> In the above
example, when SA2AB expires, SG1 will probably initiate a
> phase 2
exchange with the old SA1. What is the correct way for SG2 to
> respond to
this? Initiate a nes phase 1 exchange? Send an error
> notification to SG2
(then necessarily unencrypted due to nonexistant
> ISAKMP SA)? The latter
might open up a denial-of-service attack by sending
> spoofed error
notifications to make SG1 invalidate its existing SAs and
> thus cause
lots of unnecessary ISAKMP traffic and service
disruption.
See above. The above is a
possible means of addressing the problem, though
not explicitly stated in any RFC.
There are, obviously other alternative
solutions possible.
Regards.
- Kumar
Product
Manager
Intoto Inc.
3160, de La Cruz Blvd;
Ste #100
Santa Clara,
CA
95054