Thanks, Med. I requested the IETF LC.
-Ben On Wed, Oct 21, 2020 at 08:31:04AM +0000, mohamed.boucad...@orange.com 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:ka...@mit.edu] > > Envoyé : mardi 20 octobre 2020 21:56 > > À : draft-ietf-ipsecme-ipv6-ipv4-codes....@ietf.org > > Cc : ipsec@ietf.org > > 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. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
