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

Collision of IPSec SA negotiation.




Hi all,
  I am having a question related to the Collision of IPSec SA negotiation. I
had raised this question sometime back, but I did not get any satisfactory
reply. Hope to get some this time.

Let us take the examples where IPsec operates as a security gateway(SG) this
case, security gateway P has got one Security Policy for traffic from host A
in network X to host B in network Y with security gateway as Q. Initially
they won't have any SA to use. Now when traffic originates from A for B, P
decides to establish an IPSec SA between host A in network X and host B in
network Y. If at the same time, traffic originates from B for A, Security
gateway for Y i.e. Q. Q will see that there is no SA for this traffic, so it
will also start SA negotiation. So, now we have two SA negotiations going on
for the same traffic between two security gateways.

A similar type of situation will arise when we take the byte lifetime into
consideration. In both the peers, the soft byte lifetime may expire at the
same time, leading to the collision of IPSec SA negotiation by the peers.

	Although I could not find anything in RFC 2401 which prevents this
situation, I think that if one SG as already started negotiating for some
traffic, it is useless for the other peer SG to negotiate SA for the same
traffic. I think this is the case of IPSec SA negotiation collision. I have
observed that all the protocols which have something to negotiate between
two entities prevents the collision problem by explicitly describing them in
the RFC. Although for IPSec, I think this may not be required as this
collision will not lead to any undesirable effects, but at the same time, I
think this is irrelevant too. So, can anybody explain to me why any
collision avoidance algorithm is not specified in IPSec related set of
RFC's.

Also, I am wrong in any respect, your correction will be highly
acknowledged.

Expecting for a better response this time because I feel that this is an
important issue.

Regards,
Awan Kumar Sharma
BEGIN:VCARD
VERSION:2.1
N:Sharma;Awan
FN:Awan Kumar Sharma (E-mail)
ORG:Future Software Ltd.;NEC-DF
TITLE:Software Engg.
TEL;WORK;VOICE:+91 (4330550) - 437
TEL;HOME;VOICE:+91 (044) 8205625
ADR;WORK:;;480-481, Mount Road,;Chennai;Tamil Nadu;;India
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:480-481, Mount Road,=0D=0AChennai, Tamil Nadu=0D=0AIndia
EMAIL;PREF;INTERNET:awank@future.futsoft.com
REV:20001110T092335Z
END:VCARD