IKEv2 Clarifications and Implementation Guidelines
draft-eronen-ipsec-ikev2-clarifications-09

[Ballot discuss]
Based on the most recent mail from Steve Kent, the text in 7.1 is
inaccurate in the following way.

If you are matching against the PAD using ip addresses, then these ip
addresses must be used to look up policy in the SPD.  That requires
them to influence the traffic selectors.  So, the IP address you claim
as an Id will indirectly appear in the traffic selectors.

[Ballot discuss]
Section 7.1 is under active discussion between the authors, Steve Kent
and myself.  I need to read the last message in that discussion and
understand it.  I will either agree that answers the question or
replace this discuss and will do so by close of business May 25.

[Ballot comment]
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.

[Ballot comment]
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.

IANA Last Call Comments:

As described in the IANA Considerations section, we understand this document to have NO
IANA Actions.

(The IPSEC IANA Considerations section, appears to give the community
instructions/information about the existing registries, however this section does not
appear to request action by IANA)