Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
draft-nir-ikev2-auth-lt-05

[Ballot comment]
Section 4 answer's Joel Halpern's last call comment:

"Firstly, this is creating a TLV and associated behavior with significant interoperability problems.  As defined, the server decides it would like periodic renewal of the SA.  It sends the noew information in the IKE exchange.  It gets no indication as to whether the receiver understood the information.  Then, if the receiver does not initiate a timely repeat of the authentication (at the preferred refresh time, which is presumably noticeably shorter than the key lifetime or this would not be needed), the server disconnects the session.  This produces distinctly unanticipated results.
Secondly, I had always understood that key lifetimes were the tool for this kind of thing, not extra timers.  The problem seems to be related to the need to reverse the direction. But this technique seems awkward, and as described just above prone to producing undesirable side-effects.
If this is going to be published as is, it needs a stronger and clearer health warning about what happens if the server tries to use this and the client does not understand it."

[Ballot discuss]
I wonder whether this should be Experimental. Although it seems there was no consensus to investigate this approach in IPSEC, the writeup suggests that experimental code is being written.

[Ballot discuss]
1. I wonder whether this should be Experimental. Although it seems there was no consensus to investigate this approach in IPSEC, the writeup suggests that experimental code is being written

2. I see no response in the -05 text to Joel Halpern's last call review comment:

"Firstly, this is creating a TLV and associated behavior with significant interoperability problems.  As defined, the server decides it would like periodic renewal of the SA.  It sends the noew information in the IKE exchange.  It gets no indication as to whether the receiver understood the information.  Then, if the receiver does not initiate a timely repeat of the authentication (at the preferred refresh time, which is presumably noticeably shorter than the key lifetime or this would not be needed), the server disconnects the session.  This produces distinctly unanticipated results.
Secondly, I had always understood that key lifetimes were the tool for this kind of thing, not extra timers.  The problem seems to be related to the need to reverse the direction. But this technique seems awkward, and as described just above prone to producing undesirable side-effects.
If this is going to be published as is, it needs a stronger and clearer health warning about what happens if the server tries to use this and the client does not understand it."

IANA Follow-up Comment:
Feedback from Authors -
The notification should go in the "IKEv2 Notify Message Types" registry.
Specifically, this is not an error message, so it should go in the "RESERVED
TO IANA - Status types" range (16396-40959)

IANA Expert Review initiated now that Last Call is complete.

= = = = = = = = = =

Date: Mon, 06 Feb 2006 10:04:46 -0500
To: kivinen@iki.fi
From: Russ Housley
Subject: IANA Expert: draft-nir-ikev2-auth-lt-04.txt
Cc: ynir@checkpoint.com

Tero:

This document just passed IETF Last Call.  Please take a look at the requested IANA registry entries, and let me know if there are any problems.  I have put it on the IESG Telechat agenda for Feb., 16th, but I will withdraw it if you discover any concerns.

Russ

IANA Last Call Comments:
Upon approval of this document, we understand the IANA will need to assign a notification payload type for the AUTH_LIFETIME notifications from the IKEv2 Notification Payload Types registry.

In looking at http://www.iana.org/assignments/ikev2-parameters, we do not see specifically a "Notification Payload Types Registry". 

Can the authors please clarify as to which registry this payload type needs to go in?