[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Peter,
> a) SAs established based on data flow triggering from A to B, A is the
> initiator (e.g. policy on A: do IPSEC for traffic to peer B)
> b) A crashes
> c) B holds an SA and believes the other side (A) is still able to undo
> IPSEC traffic on the SA that was wiped out on the reboot of A. All IPSEC'd
> traffic from B to A is unusable and nothing drives the establishment of new
> SAs btw A and B since A has no traffic destined for B and B already has what
> it thinks are valid SAs to A.
>
> there are several proposals for peer recovery floating around, but without
> it the spec seems incomplete.
If an IPSEC implementation is being pelted with SPI's that it doesn't
understand from a particular source, a reasonable thing for it to do might be
to turn around and initiate to the host who's sending it all that traffic it
doesn't understand. In the subsequent Main Mode exchange, an INITIAL-CONTACT
Notify message can be used to inform the host who didn't reboot that previous
SA's it holds to the new peer are now invalid. This can be implemented today.
I do not believe that there would be concensus to make this mandatory however.
> If AH moves to PS, customers will expect it to be part of ALL
> implementations. This is the time to simplify IPSEC.
No, three years ago was the time to simplify AH/ESP. Now is the time to
finish this work and get on with more interesting problems. Though I
personally agree with you that there's no need for two slightly different
authentication protocols, the fact of the matter is that we collectively
settled on the current drafts and now have rough concensus and running code.
These drafts are not elegant, but I believe that they do now satisfy the
stated requirements for an IP-level security protocol for the Internet.
Derrell
References: