Draft: draft-nir-ikev2-auth-lt-04.txt Reviewer: Joel M. Halpern [joel@stevecrocker.com] Review Date: Saturday 1/7/2006 2:57 PM CST LC Date: 1/18/2006 Summary: This document is close to ready for publication as an individual informational RFC. There are some issues. 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. I would guess from the clause prohibiting derivative works that this is actually a publication of Check Point's approach. Such publication is fine, but needs to be clearly labelled as such. Traditionally, we have included the company name in the title of such publications. The registry for identifying the information used in this is described by RFC 4306 as requiring expert review. I don't see evidence in the ID-Tracker of that review, unless Russ decided to provide that himself. minor: This document uses old boilerplate. Yours, Joel M. Halpern PS: I was going to ask what the IKEv2 working group thinks about the problem / solution, but there does not appear to be an IKEv2 working group to provide such an opinion.