Hi Paul,
Thanks for rejecting my issues so quickly :-) Please see some comments below. I
have deleted issues where I accept the rejection.
Yaron
> -----Original Message-----
>
> =====
> 1.4.1: the last paragraph springs a surprise by defining the behavior
> of IKE SA deletion while discussing an unlikely "messing up" of Child
> SAs. IKE SA deletion deserves its own subsection.
>
> [[ Response: it is optional behavior and makes sense. If you want a
> section on IKE SA deletion, you have to write it. I propose that it
> might be very late for doing that. ]]
>
I suggest replacing the last paragraph by the following text (not a new
section, though):
Similarly to ESP and HA SAs, IKE SAs are also deleted by sending an
Informational exchange. Deleting an IKE SA implicitly closes any remaining
Child SAs negotiated under it. The response to a request that deletes the IKE
SA is an empty INFORMATIONAL response.
Half-closed ESP or AH connections are anomalous, and a node with auditing
capability should probably audit their existence if they persist. Note that
this specification nowhere specifies time periods, so it is up to individual
endpoints to decide how long to wait. A node MAY refuse to accept incoming data
on half-closed connections but MUST NOT unilaterally close them and reuse the
SPIs. If connection state becomes sufficiently messed up, a node MAY close the
IKE SA, as described above. It can then rebuild the SAs it needs on a clean
base under a new IKE SA.
> =====
> 2: the last paragraph, beginning "The UDP payload" is out of place
> here.
>
> [[ Response: It is useful in the general sense of "IKE Protocol Details
> and Variations". It is described in more detail later. ]]
>
Yeah well, it still sticks out like a sore thumb. And it's fully described in
2.23, so it's redundant here.
> =====
> 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We
> don't say we don't - although we do say that it would only be effective
> starting with IKE_AUTH. But I believe we should not accept it until
> both peers are fully authenticated.
>
> [[ Response: that would be a new prohibition. I don't see text in the
> current doc indicating this. ]]
>
In fact we do: "The window size is always one until the initial exchanges
complete." And Tero mentioned correctly that the "initial exchanges" are both
IKE_SA_INIT and IKE_AUTH. The current text is fine.
> =====
> 2.8: "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." A dummy message on an IPsec SA
> is way out of scope. Whether such messages even exist is a matter of
> local implementation. We certainly don't have IPsec-level keepalives.
> Overall, the last 3 paragraphs of 2.8 (starting "There are timing
> windows") are a mess: you have to read them several times before you
> realize that this is not normative text, rather it is several
> implementation alternatives.
>
> [[ Response: I found those paragraphs clear, but I might have missed
> something. Suggest rewording in a new ticket if you wish. ]]
>
I will pass on the last 3 paragraphs. But please open an issue regarding the
"dummy message" text (the first part of my text above).
> --Paul Hoffman, Director
> --VPN Consortium
>
> Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
