IKEv2 Clarifications and Implementation Guidelines
RFC 4718

Note: This ballot was opened for revision 09 and is now closed.

Summary: Needs a YES.

[Russ Housley]

Comment (2006-05-07 for -)

  Section 5.11.8 says:
  >
  > If host A did receive it, it will move the CHILD_SA to the new IKE_SA
  > as usual, and the state information will then be out of sync.
  >
  s/out of sync/unsynchronized/

  Section 7.2 says:
  >
  > The IKEv2 specification refers to [RFC4301], but it never makes
  > clearly defines the exact relationship is.
  >
  Suggested rewording:
  >
  > The IKEv2 specification refers to [RFC4301], but it the relationship
  > between the two ddocuments is not clear.

  Section 7.7 says:
  >
  > Note that such notifications are explicitly not Informational exchanges;
  > Section 1.5 makes it clear that these are one-way messages that must not
  > be responded to.
  >
  Suggested rewording:
  >
  > Note that such notifications are explicitly not Informational exchanges;
  > Section 1.5 makes it clear that these are one-way messages, and the
  > recipient must not responded to them.

[Sam Hartman]

Comment (2006-05-24 for -09)

Is the recommendation in section 5.9 that the original ike initiator
can change on an IKE SA rekey consistent with mobike?  Does that mean
that in the case of mobike, you want to make sure only the original
initiator rekeys in order to avoid changing which side nat works best
with?

I'm not sure I agree with the text in 7.1 that claims the IP address
ID payloads don't impact the traffic selectors.  As far as a direct
implication, it is true.  However you do search the SPD based on the
IP address payload and that does effect traffic selectors.  For
example I don't see how to configure the SPD to allow someone claiming
an Id of 10.0.0.6 to match a policy that doesn't have 10.0.0.6 in one
of the traffic selectors.