Presumably, such implementations would do the same as they normally do
for INITIAL_CONTACT:
The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. It MAY
be sent when an IKE SA is established after a crash, and the
recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout.
The original RFC did not specify that it MUST be sent in a specific
message, and therefore we'd better leave it somewhat vague instead of
forcing the protocol to fail otherwise. In particular because the normal
recipient behavior is a MAY.
Thanks,
Yaron
On 31.3.2010 2:59, Paul Hoffman wrote:
s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST be in the first
IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties
MAY ignore it in other messages."
What should receiving parties do if they *do* receive it and *don't* ignore it?
Since it 'MUST be sent in the first IKE_AUTH' receiving at any other time is a
protocol error and should cause some response (like dropping the IKE_SA
perhaps).
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec