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".
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).
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)
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
Best regards,
Pasi
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf