Comments inline
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of [EMAIL PROTECTED]
>
> 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 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
