Re: AD review: draft-ietf-kink-kink [section 1-4]

>>>>> "Michael" == Michael Thomas <[email protected]> writes:

    Michael> On Tue, 2005-01-18 at 14:31, Sam Hartman wrote:
    >> Section 4.4
    >> 
    >> IPsec does not allow half-open security associations any more
    >> as far as I can tell in 2401bis.  So it's not just for
    >> simplicity, but for model conformance.

    Michael> Where is this "model conformance"? This is a kernel level
    Michael> suggestion at best, and if 2401bis forbids this, nothing
    Michael> actually changes with the KINK protocol except for the
    Michael> fact that it loses data which isn't KINK's fault, but
    Michael> 2401bis' notion of "conformance". 

I do not understand this sentence.  What I was trying to say is that
there may now be additional reasons having to do with 2401bis that
kink does not allow half open security associations.
I'd like the text to reflect this.

I believe the easiest way to do this is to drop the phrase "for simplicity."

    Michael> In any case, I don't
    Michael> see why we should change this especially since 2401 isn't
    Michael> broken in this way.

I believe it is important that IETF specs be clear.  If you claim that
you do something like disallow one-way SAs for simplicity, then it
needs to be true that you had an option in the matter.  As it stands,
I believe your behavior will be dictated by 2401bis.

    >> Section 4.4.1:
    >> 
    >> Please make sure this discussion is aligned with 2401bis.  I
    >> think it may change small details but they seem to have adopted
    >> much of the same strategy kink uses.  The area wher I believe
    >> they speak to this issue is when you should rekey (timers etc)

    Michael> This is a classic case of KINK being the _actual_ start
    Michael> of IKEv2 and 2401bis. The main question I have is whether
    Michael> there is something _wrong_ here. 

I do not believe there is something wrong at the protocol, although I
believe it is important to confirm that is the case.  I believe there
may be small textual alignment issues.

    Michael> I really don't think
    Michael> it's fair to just be sending us off on work assignments
    Michael> if there's no reason to believe that what the draft
    Michael> states is incorrect.


I'd like to draw your attention to section 6.7 of RFC 2418, working
group procedures:

  6.7. Area Director

     Area Directors are responsible for ensuring that working groups in
        their area produce coherent, coordinated, architecturally consistent
           and timely output as a contribution to the overall results of the
              IETF.

As part of my responsibility for producing coordinated specifications
I'm asking that the Kink draft be coordinated with RFC 2401bis.  In
particular when I notice that the Kink draft discusses the same issue
as 2401bis, I will either determine that both documents are consistent
myself or ask someone else to do so.  A response to such a question
could be of the form "I looked at the text dealing with rekeying in
2401bis; it says foo.  I Looked at kink which says barr.  These are
consistent."  A more abbreviated response of "I looked at rekeying in
2401bis and Kink and they are consistent," is appropriate in some
circumstances.

If you object to me delegating part of this review to the working
group rather than doing it all myself, I think we have a fundamental
disagreement.  I'm fairly sure that is within the set of things it is
appropriate and reasonable for me to do as an AD.

If you are concerned that you personally don't want to do all this
alignment checking, then work with the chairs to see if someone else
does.



    >> Section 4.4.2
    >> 
    >> [**] Discuss status message, rebooting peers and u2u.  This
    >> looks a lot like the IKE case where you lose all cryptographic
    >> context to me.

    Michael> I don't understand what you want here. Are you saying
    Michael> that this doesn't work in the u-u case? I don't
    Michael> understand what u-u has to do with anything here.

OK.  I was unclear .  When sending a status message, what happens if
the peer has gotten a new TGT?  How do I realize I need to use this
TGT rather than the one I have?