Comments inline > -----Original Message----- > From: ipsec-bounces@xxxxxxxx [mailto:ipsec-bounces@xxxxxxxx] > On Behalf Of Pasi.Eronen@xxxxxxxxx > > 1) Overall: Being able to reauthenticate the client (either > periodically or by some other trigger) is a common requirement in > remote access deployments. It's a good idea to have one documented > way to do this, instead of each vendor inventing its own proprietary > payloads. Thus, I think this document is a very useful extension to > IKEv2, and deserves to be published. > > 2) The document could be more precise about in describing what > messages can contain the AUTH_LIFETIME notification. The intent was > clearly "in the last IKE_AUTH response or in any INFORMATIONAL > request", but this is not exactly the same as saying "in a separate > Informational exchange" (which might be interpreted as including > both the request and response messages) or "MAY be sent by the > original Responder at any time". You're right about the former, but I think the latter needs to stay. It refers to the timing of sending the message. > 3) Section 2: "It is recommended that an INITIAL-CONTACT > notification be included in the AUTH exchange." > > This is probably not correct. RFC4306 says that "This notification > MUST NOT be sent by an entity that may be replicated (e.g., a > roaming user's credentials where the user is allowed to connect to > the corporate firewall from two remote systems at the same time)." > > Even if the corporate IT department has decided not to allow this, > the initiator probably does not know this, so it should not include > the notification. > > Furthermore, the INITIAL_CONTACT notification is not really needed > for anything in this case, since the client has not crashed, > and it still has all the information it needs to properly close > the old IKE_SA (once the new one has been established). I thought INITIAL_CONTACT would be a shorter way to achieve the same goal, but I forgot about the replication problem. I agree. This line must go. > 4) Section 7 (IANA Considerations): The text should say that the > number needs to be assigned from the "Status Types" range (and not > the "Error Types" part) Well, if and when this is published, This would change to a specific, allocated number. I did write this in the IANA application. > 5) Typos etc. > Section 2: the Informational response should be "HDR, SK{}" > Section 3, s/AUTH_LEFETIME/AUTH_LIFETIME/ > Section 6, should explicitly say that both references are normative Agreed. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf