Paul Hoffman writes:
> At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:
>
> All changes made other than the following.
>
> >----------------------------------------------------------------------
> >
> >Section 2.8.2 there was removed paragraph:
> >
> > However, there is a twist to the other case where one rekeying
> > finishes first:
> >
> >and I think some kind of paragraph is needed, as the example given
> >below is not about normal simultaneous IKE SA rekey, but this special
> >case. Now someone might think that the example given is the normal
> >simulatenous IKE SA rekey example.
>
> Please open a new issue in the tracker and put specific text in it.
Opened ticket #171.
> >The section 1.7 should be more like description of changes, not just
> >listing section numbers with changed text. For example I think it
> >would be better to combine:
> >
> > In section 1.3.2, changed "The KEi payload SHOULD be included" to be
> > "The KEi payload MUST be included". This also lead to changes in
> > section 2.18.
> >
> > Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
> > the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie-
> > Hellman exchange was optional, but this was not useful (or
> > appropriate) when rekeying the IKE_SA.
> >
> >to one item saying:
> >
> > Diffie-Hellman exchange is now required for IKE SA rekeys. In
> > theory, RFC 4306 allowed a policy where the Diffie- Hellman
> > exchange was optional, but this was not useful (or appropriate)
> > when rekeying the IKE_SA (section 1.3.2 and section 2.18).
>
> This difference is not worth the effort of re-writing the whole
> section and possibly losing information.
I do not think we need to rewrite whole section, but I think it would
be worth of cleaning up some of the items to better explain what is
changed, compared to just listing changed section numbers with very
cryptic texts.
And as you pointed out we do not try to include every single change,
only those which are important, meaning if we loose some information
while changing those sections then it is probably ok, as if we do not
notice we are loosing important information then that information we
loose cannot be very important, thus it can be left out anyways.
This is section listing changes happening in otherwhere in the
document, so we cannot really loose real information. Everything here
needs to be something that is already explained somewhere else.
> >----------------------------------------------------------------------
> >
> >For example in 1.7 the point:
> >
> > This document clarifies the use of the critical flag in Section 2.5.
> >
> >does not help implementors at all, as they now need to go through the
> >old RFC4306 section 2.5 and compare it with the new section 2.5 to
> >find out what was done (and I do not remember that myself, so I need
> >to do that to provide better text for that bullet).
>
> Clarifications such as this are welcome. Please provide text.
Hmm.. I think this comment is about the this added text in IKEv2bis
(by looking at the diff of section 2.5 between RFC4306 and
draft-ietf-ipsecme-ikev2bis-07):
Payloads sent in IKE response messages MUST
NOT have the critical flag set. Note that the critical flag applies
only to the payload type, not the contents. If the payload type is
recognized, but the payload contains something which is not (such as
an unknown transform inside an SA payload, or an unknown Notify
Message Type inside a Notify payload), the critical flag is ignored.
So the more descriptive text could be:
This document clarifies that critical flag MUST NOT be used in
response messages, and that critical flag applies only to the
payload type, note the contents (Section 2.5).
> >----------------------------------------------------------------------
> >
> >In section 1.7 the bullet
> >
> > In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
> > different traffic selectors and algorithms than the old one" to "Note
> > that, when rekeying, the new Child SA SHOULD NOT have different
> > traffic selectors and algorithms than the old one".
> >
> >should be rewritten to
> >
> > In the Child SA rekey the new recommended behavior is that the new
> > Child SA SHOULD NOT have different traffic selectors and algorithms
> > than what was used in the old Child SA. Previously it
> > was that "Child SA MAY have different traffic selectors and
> > algorithms then the old one" (section 2.8).
>
> Those two feel equivalent to me; not done. I am quite hesitant to do
> wordsmithing at this stage, particularly if it could cause loss of
> information.
Yes, I tried to write them so they are equivalent, but I think it is
better to try to explain the change in normal words, than just provide
diff. If diff would be enough, then we could just point everybody to
the rfcdiff between RFC4306 vs IKEv2bis.
> >----------------------------------------------------------------------
> >
> >Also I think the new sections could be combined together i.e. replace:
> >
> > The new Section 2.8.2 covers simultaneous IKE SA rekeying.
> >
> > The new Section 2.9.2 covers traffic selectors in rekeying.
> >
> > Added Section 2.23.1 to describe NAT traversal when transport mode is
> > requested.
> >
> >to
> >
> > There are completely new sections covering simultaneous IKE SA
> > rekeying (Section 2.8.2), traffic selectors in rekeying (Section
> > 2.9.2) and NAT traversal in transport mode (2.23.1).
>
> Ditto. These are equivalent.
Yes, but same reason again. Put emphasis on the new information, not
to new section numbers.
> >----------------------------------------------------------------------
> >
> >In general implementators are not that interested in what parts of the
> >text changed, they are interested in what was the real change that
> >affects them.
>
> That's a very broad claim, made by someone who already fully
> implemented IKEv2. Other implementers, particularly those who are in
> the middle of implementing IKEv2, might differ.
If someone are middle of implementing IKEv2 then either they have
already implemented something that needs to be changed, in which case
they are interested what parts of text that affects them has changeed,
or they have not yet implemented that part, in which case that change
does not interest them at all, in which case they just ignore the old
RFC4306 and directly read new IKEv2bis text.
If they are new to IKEv2 they do not need this section at all, as it
is not important to know what was before, if they are just trying to
see what they need to make for their implementation.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
