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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Oct 2020 12:56:28 -0700

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

---

From: <[email-masked]>
Date: Wed, 21 Oct 2020 08:31:04 +0000

Hi Ben, 

Thank you for the review.

An updated version is available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-05.  

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mardi 20 octobre 2020 21:56
> À : [email-masked]
> Cc : [email-masked]
> Objet : AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04
> 
> 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
> 
> concept, perhaps we should drop an "IPv6/IPv4" in somewhere (or add
> a reference?  I'm not sure what reference would be good, offhand).

[Med] Added text to explain this. 

> without preceding "notification"; would it make sense to normalize
> the language around "notification status type"?

[Med] Agree. Fixed. 

> successfully assign *one* address, just not the full requested set,
> so INTERNAL_ADDRESS_FAILURE is explicitly not useful.
> 

[Med] Tweaked that part to include the text you quoted. The explanation text covers this case as well.

> 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?

[Med] This is typically INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS attributes. The attributes are not listed as I would like to cover (the experimental attribute) INTERNAL_IP6_PREFIX (or future attributes to achieve the same functionality).

Updated the text to point to Section 3.15 of 7296.  

> single-stack.

[Med] These notifications are not sent by the initiator. The default behaviour for a dual-stack initiator is to request both IPv4 and IPv6 connectivity. This behaviour can be restricted by policy. In such case, the initiator will only request the connectivity that adheres to its local policy (e.g., IPv6-only).

  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

[Med] Yes. This is inferred from the INTERNAL_* attributes listed above. Added NEW text to make this clear. 

> What is the scope of this "MUST NOT"?  Other CREATE_CHILD_SA on the
> same parent IKE SA?

[Med] Yes. Made this change: s/request/subsequent request. 

  Ever to the same responder?
> initiators to send, at the start of the section we said that a dual-
> stack initiator MUST include both address families...]

[Med] This is about covering the case where a policy is provided and the default behaviour is not followed. 

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

[Med] I prefer yours. Fixed. Thanks. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.