Re: comments on IKEv2-05

[Charlie_Kaufman@notesdev.ibm.com]

Dan Harkins <dharkins@trpz.com> wrote:
>   I have several comments on IKEv2 that I'm going to spread
> across different messages to keep from sending on huge post.

A wonderful idea that I will try to emulate. Sorting messages
by thread is a lot easier when there is only one topic in each
one.

> I'll start here with minor nits:
>
>   - Section 2.13 describes a Diffie-Hellman group as a cryptographic
>     algorithm that takes fixed size key. That is wrong.

Fixed.

>
>   - page 82 and the TOC: s/Author/Editor/

Fixed.

>
>   - Section 8.1 should include a normative reference to RFC2451.
>     (A good way to tell whether it's normative or informative is to
>     check if implementation of the requirement can be visible
>     externally and if it has an impact on interoperability. Yes on
>     both counts: normative).

Done, though I'd quibble with the criteria. I'd say it's normative
if you can't implement something compliant with this spec without
information from the other. A normative reference can be made
informative by copying its critical content into the referencing
document. RFC2451 is clearly normative by my definition as well.
I believe there are a lot of other normative references missing.
I keep not getting to tracking them all down. If others would like
to point them out to me, there's a better chance the list will be
complete.

>
>   - Section 1.4 The Informational Exchange says, "When SAs are nested,
>     as when data (and IP headers if in tunnel mode) are encapsulated
>     first with IPcomp, then with ESP, and finally with AH between the
>     same pair of endpoints...." How does one negotiate such nested SAs
>     using IKEv2? I don't think it's possible.

One would have to define a suite that contains multiple nested protocols.
The spec says how to pass the multiple SPIs in that case. There are
currently no suites defined that negotiate nested SAs. I believe they
are a bad idea, but I didn't dare remove the functionality from the
protocol for fear someone would deem it crucial. Unless you support
a suite that includes nested SAs, there is no implementation complexity
added by their possibility.

>
>   - page breaks need to be thought through more. For instance, the
>     Authentication Payload in section 3.8 is bisected by a page break.

I went through and fixed the most obvious problems. Of course, another set
will come up when I run it off again, but I'll try to keep on top of this.
I did make sure that there would be no page breaks in figures of
immediately following section titles.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).