Subject: RE: [Ipsec] IKEv2 and Initial Contact

From: "Charlie Kaufman" <[email-masked]>
Date: Mon, 13 Sep 2004 14:40:45 -0700

While there a variety of things an implementation might do and remain
interoperable, my assumption has been that an implementation would not
initiate an IKE exchange just to notify its peer that it has recovered
from a crash. Rather that it would wait for the peer to time out the old
IKE SA. The peer has to be prepared to do that in the case where the
implementation has crashed and not immediately recovered.

If an implementation did want to start up a new SA solely for the
purpose of telling the other endpoint to stop sending, I think it would
be better to negotiate some "dummy" address than to special case the
spec. The spec doesn't say either way, but it would not be unreasonable
for a peer to recognize and process the "INITIAL_CONTACT" notification
even if it were going to reject the child SA request.

	--Charlie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Srinivasa Rao Addepalli
Sent: Friday, September 10, 2004 4:45 PM
To: [email-masked]
Subject: [Ipsec] IKEv2 and Initial Contact

As I understand, SAi2, SAr2 and TSi, TSr are MUST payloads in AUTH
exchange.
When the system restarts, the implementation are  expected to send
INITIAL_CONTACT
notification to others so that the remote peers would reset any state
information,
remote peer has with this node. Since this message needs to be
cryptographically protected,
IKE SA needs to be negotiated with the peer. Note that, here the IKE SA
is
not initiated due to the data packet. In this case, what should be the
values of
SA and TS payloads. I guess, we can send send any values (may be all
supported ones) in SAs so that
atleast one of the combination would be accepted by peer.  What are the
appropriate
values for Traffic Selectors? 

Options, I can think of are:
1. Make SA and TS optional in AUTH exchange.  Is there any particular
reason for not 
    making them optional.
2. Define some predefined value for SA and TS to indicate to the peer
that they are not to
    be interpreted, so that peer does not fail the exchange.

What do other think about this?
Did I overlook any text in the draft?

Thanks
Srini

Intoto Inc.
www.intoto.com

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Mon, 13 Sep 2004 15:31:45 -0700

> from a crash. 
I have taken one example to illustrate the need. You are right that in most cases,
the peer would detect the IKE SA is no longer live and delete the SA by itself.
This can take longer time and the local node can, based on its local intelligence(say upon 
receiving secured packet from a gateway, to which there are no IKE SAs)
can decide to send INITIAL CONTACT message. 

>Rather that it would wait for the peer to time out the old

Yes. I guess this can solve the problem. I guess, once AUTH payload is validated,
action on 'INITIAL_CONTACT' can be taken.