On Tue, 11 Jan 2022, Valery Smyslov wrote:
This sort of construction invites ambiguity if there is ever some other
future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This
seems like a strong argument in support of the approach this draft
takes, i.e., make IKE_INTERMEDIATE fully
HI Ben,
thank you for your review.
> Hi all,
>
> The core mechanisms here seem in good shape. My main area of
> uncertainty relates to how much analysis, and with what degree of
> formalism, has been applied to the updated IKE_AUTH procedures that are
> supposed to authenticate the intermediate
> > o if the Responder chooses to send Cookie request (possibly along
> > with Puzzle request), then the TCP connection that the IKE_SA_INIT
> > request message was received over SHOULD be closed after the
> > Responder sends its reply
> > and no repeated requests are received
Valery Smyslov writes:
> The latest text I proposed in reply to Paul's comments incorporates
> this strategy:
>
> o if the Responder chooses to send Cookie request (possibly along
> with Puzzle request), then the TCP connection that the IKE_SA_INIT
> request message was received ov
Hi Paul,
> On Mon, 10 Jan 2022, Valery Smyslov wrote:
>
> > The responder does use an existing TCP connection to reply,
> > but once it replies with cookie request, it should close this connection.
> > If it keeps this connection, then it keeps TCP state until the client
> > resends IKE_SA_INIT r
Benjamin Kaduk writes:
> I'd also like to confirm that the current (lack of) Updates:
> relationship between this document and RFC 7296 is correct. In ยง3.2, we
> reaffirm that the normal IKE rules for assigning Message IDs apply, so
> "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for
Hi Tero,
> Valery Smyslov writes:
> > The responder does use an existing TCP connection to reply, but once
> > it replies with cookie request, it should close this connection. If
> > it keeps this connection, then it keeps TCP state until the client
> > resends IKE_SA_INIT request (if ever) and th
