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

[Benjamin Kaduk <[e-mail]>]

Thanks, Med.

I requested the IETF LC.

-Ben

On Wed, Oct 21, 2020 at 08:31:04AM +0000, [e-mail] wrote:
> 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:[e-mail]]
> > Envoyé : mardi 20 octobre 2020 21:56
> > À : [e-mail]
> > Cc : [e-mail]
> > 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
> > 
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > %
> > 
> > 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).
> 
> [Med] Added text to explain this. 
> 
> > 
> > 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"?
> 
> [Med] Agree. Fixed. 
> 
> > 
> > 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.
> > 
> 
> [Med] Tweaked that part to include the text you quoted. The explanation text covers this case as well.
> 
> > 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?
> 
> [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.  
> 
> > 
> > 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.
> 
> [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
> > something other than IP<N>_ALLOWED?
> 
> [Med] Yes. This is inferred from the INTERNAL_* attributes listed above. Added NEW text to make this clear. 
> 
> > 
> >    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?
> 
> [Med] Yes. Made this change: s/request/subsequent request. 
> 
>   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...]
> 
> [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.
>