IKEv2 Clarifications and Implementation Guidelines
Summary: Needs a YES.
Note: This ballot was opened for revision 09 and is now closed.
( Sam Hartman ) (was Discuss) Yes
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.
( Russ Housley ) Yes
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.