Proposed resolution to Issue 1

[Charlie_Kaufman@notesdev.ibm.com]

(apologies if this is a duplicate. I sent this two days ago and it never
came back to me from the list).

      --Charlie

Issue 1 notes that it is not clear when a newly created SA can be used. I
propose adding the following text to the end of Section 2.8:

There are timing windows - particularly in the presence of lost packets -
where endpoints may not agree on the state of an SA. The responder to
a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before
sending its response to the creation request, so there is no ambiguity
for the initiator. The initiator may begin sending on an SA as soon as
it processes the response. The initiator, however, cannot receive on a
newly created SA until it receives and processes the response to its
CREATE_CHILD_SA request. How, then, is the responder to know when it is
OK to send on the newly created SA?
.sp
From a technical correctness and interoperability perspective, the
responder MAY begin sending on an SA as soon as it sends its response
to the CREATE_CHILD_SA request. In some situations, however, this could
result in packets unnecessarily being dropped, so an implementation MAY
want to defer such sending.
.sp
The responder can be assured that the initiator is prepared to receive
messages on an SA if either (1) it has received a cryptographically valid
message on the new SA, or (2) the new SA rekeys an existing SA and it
receives an IKE request to close the replaced SA. When rekeying an SA,
the responder SHOULD continue to send requests on the old SA until it
one of those events occurs. When establishing a new SA, the responder
MAY defer sending messages on a new SA until either it receives one or
a timeout has occurred. If an initiator receives a message on an SA for
which it has not received a response to its CREATE_CHILD_SA request, it
SHOULD interpret that as a likely packet loss and retransmit the
CREATE_CHILD_SA request. An initiator MAY send a dummy message on a newly
created SA if it has no messages queued in order to assure the responder
that the initiator is ready to receive
messages.