Hi Med, Not a whole lot to comment on here, but probably we should publish a new revisionn to tidy things up before asking for IETF LC.
Thanks, Ben %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% We use the term "dual-stack" several times but it is not defined explicitly. While this is certainly a common and fairly well-known concept, perhaps we should drop an "IPv6/IPv4" in somewhere (or add a reference? I'm not sure what reference would be good, offhand). There seem to be a few places where we use the phrase "status type" without preceding "notification"; would it make sense to normalize the language around "notification status type"? Section 3 Section 3.15.4 of [RFC7296] defines a generic notification error type that is related to a failure to handle an address assignment request. That error type does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. INTERNAL_ADDRESS_FAILURE is a catch- all error type when an address-related issue is encountered by an IKEv2 responder. INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the IKEv2 initiator to adjust its behavior. I feel like we might also want to mention that (per 7296), "[t]he responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned", and in many of the indicated use cases, the responder can successfully assign *one* address, just not the full requested set, so INTERNAL_ADDRESS_FAILURE is explicitly not useful. Section 5 If the initiator is dual-stack, it MUST include both address families in its request (absent explicit policy/configuration otherwise). By "both address families" we mean "both the IP6_ALLOWED and IP4_ALLOWED notification status types"? Or are we talking about something else, like a configuration payload? It is perhaps surprising that we only impose the requirement for the initiator to send these notifications specifically on dual-stack initiators; a generic protocol update might typically impose a requirement to always send your capabilities, whether dual-stack or single-stack. In particular, the table seems to imply that the initiator will still send something to indicate the requested AF in the single-requested-AF case (which need not be dual-stack); is this something other than IP<N>_ALLOWED? If the initiator only receives one single notification IP4_ALLOWED or IP6_ALLOWED from the responder, the initiator MUST NOT send a request for an alternate address family not supported by the responder. What is the scope of this "MUST NOT"? Other CREATE_CHILD_SA on the same parent IKE SA? Ever to the same responder? If a dual-stack initiator requests only an IPv6 prefix (or an IPv4 address) but only receives IP4_ALLOWED (or IP6_ALLOWED) notification status type from the responder, the initiator MUST send a request for IPv4 address(es) (or IPv6 prefix(es)). [related to the earlier comment about only requiring dual-stack initiators to send, at the start of the section we said that a dual-stack initiator MUST include both address families...] Section 6 I think a phrasing like "since the IPv4/IPv6 capabilities of a node are readily determined from the traffic it generates, this document does not introduce any new security considerations compared to the ones described in [RFC7296], which continue to apply" might be more conventional. (I don't object to the current phrasing, though.) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
