[IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04

[Benjamin Kaduk <[e-mail]>]

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.)