Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > As you can see at https://tinyurl.com/add-ike-latest, the note is > updated as follows: > > Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) > attribute to be mandatory present when INTERNAL_DNS_DOMAIN is > included. This specification relaxes that constraint in the > presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* > attributes are supplied, it is allowed for responders to include > ^^ > INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or > INTERNAL_IP4_DNS) attributes. > > Thanks for zooming into this. I was expecting to have this > discussion during the IESG review. We have now a fresh thread to > which we can refer :-) That looks good, and solves the issue I had with backward compatibility. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Hi Tero, As you can see at https://tinyurl.com/add-ike-latest, the note is updated as follows: Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute to be mandatory present when INTERNAL_DNS_DOMAIN is included. This specification relaxes that constraint in the presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* attributes are supplied, it is allowed for responders to include ^^ INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes. Thanks for zooming into this. I was expecting to have this discussion during the IESG review. We have now a fresh thread to which we can refer :-) Cheers, Med > -Message d'origine- > De : Tero Kivinen > Envoyé : lundi 20 mars 2023 13:56 > À : Valery Smyslov > Cc : BOUCADAIR Mohamed INNOV/NET ; > 'Patrick Mevzek' ; > dns...@ietf.org; draft-ietf-ipsecme-add-ike@ietf.org; > ipsec@ietf.org; last-c...@ietf.org > Objet : RE: Dnsdir last call review of draft-ietf-ipsecme-add-ike- > 09 > > Valery Smyslov writes: > > > I mean if initiator proposes: > > > > > >CP(CFG_REQUEST) = > > > INTERNAL_IP6_ADDRESS() > > > ENCDNS_IP6() > > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > > INTERNAL_DNS_DOMAIN() > > > > > > to indicate that it only wants to talk ENCDNS server, and it > does > > > NOT want to have normal DNS server, then responder who do not > > > understand > > > ENCDNS_IP6() will see that this is against MUST in RFC8598 and > as > > > there is no other error to use, it will most likely consider > this a > > > malformed message (==fatal error) and return with > INVALID_SYNTAX. > > > This will tear down the IKE SA and does not specify for the > > > initiator why the connection attempt failed. > > > > The initiator cannot force the responder to do anything (e.g. to > > explicitly provide it with the encrypted DNS info). It can only > > indicate support for this feature. So, in my understanding, the > above > > set of configuration attributes indicates some problems with > initiator > > (in which case fatal error is not a bad solution). > > > > The correct request should be: > > > > CP(CFG_REQUEST) = > > INTERNAL_IP6_ADDRESS() > > INTERNAL_IP6_DNS() > > ENCDNS_IP6() > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > INTERNAL_DNS_DOMAIN() > > > > If the responder doesn't support this extension, it will ignore > > ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return > INTERNAL_IP6_DNS(...) + > > INTERNAL_DNS_DOMAIN(...). > > > > If the responder supports this extension, it will return either > > ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + > INTERNAL_DNS_DOMAIN(...) or > > INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on > its > > configuration (most probably the former). > > This is all clear. > > > If the initiator is configured to allow only encrypted DNS, it > may > > immediately delete IKE SA in case the responder returns > > INTERNAL_IP6_DNS. There is nothing more the initiator can do in > this > > case. > > > > Note, that with this approach there is no room for fatal errors, > all > > protocol paths are legal with no need to update 8598. > > Ok, so the note for RFC8598 behavior only applies to responder, > i.e., responder is allowed return ENCDNS_IP* and > INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but inititiator needs > to send request that contains both. Perhaps the Note about the > RFC8598 should be updated to say "it is allowed for responder to > include INTERNAL_DNS_DOMAIN even in the absense of > INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, provided there > is ENCDNS_IP* attributes in the response." or something like that. > > Then I agree that this does not update RFC8598. > -- > kivi...@iki.fi _ 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
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Valery Smyslov writes: > > I mean if initiator proposes: > > > >CP(CFG_REQUEST) = > > INTERNAL_IP6_ADDRESS() > > ENCDNS_IP6() > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > INTERNAL_DNS_DOMAIN() > > > > to indicate that it only wants to talk ENCDNS server, and it does NOT > > want to have normal DNS server, then responder who do not understand > > ENCDNS_IP6() will see that this is against MUST in RFC8598 and as > > there is no other error to use, it will most likely consider this a > > malformed message (==fatal error) and return with INVALID_SYNTAX. This > > will tear down the IKE SA and does not specify for the initiator why > > the connection attempt failed. > > The initiator cannot force the responder to do anything (e.g. to > explicitly provide it with the encrypted DNS info). It can only > indicate support for this feature. So, in my understanding, the > above set of configuration attributes indicates some problems with > initiator (in which case fatal error is not a bad solution). > > The correct request should be: > > CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > INTERNAL_IP6_DNS() > ENCDNS_IP6() > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > INTERNAL_DNS_DOMAIN() > > If the responder doesn't support this extension, it will ignore > ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return INTERNAL_IP6_DNS(...) + > INTERNAL_DNS_DOMAIN(...). > > If the responder supports this extension, it will return either > ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + INTERNAL_DNS_DOMAIN(...) > or INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on its > configuration (most probably the former). This is all clear. > If the initiator is configured to allow only encrypted DNS, it may > immediately delete IKE SA in case the responder returns > INTERNAL_IP6_DNS. There is nothing more the initiator can do in this > case. > > Note, that with this approach there is no room for fatal errors, all > protocol paths are legal with no need to update 8598. Ok, so the note for RFC8598 behavior only applies to responder, i.e., responder is allowed return ENCDNS_IP* and INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but inititiator needs to send request that contains both. Perhaps the Note about the RFC8598 should be updated to say "it is allowed for responder to include INTERNAL_DNS_DOMAIN even in the absense of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, provided there is ENCDNS_IP* attributes in the response." or something like that. Then I agree that this does not update RFC8598. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Hi Tero, > mohamed.boucad...@orange.com writes: > > > But my understanding is that this is not the case here, as if you > > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > > > ENCDNS_IP* to implementations supporting old RFC, > > > > [Med] Responders know when it will break. They will basically supply > > the encrypted DNS to initiators who indicated support as per: > > > >Initiators first indicate support for encrypted DNS by including > >ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders > >supply encrypted DNS configuration by including ENCDNS_IP* attributes > >in their CFG_REPLY payloads. > > > > If responders decide to ignore the capabilities of the initiators, > > returning **only** the ENCDNS_IP* won't break only split horizon but > > the full DNS service! > > I mean if initiator proposes: > >CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > ENCDNS_IP6() > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > INTERNAL_DNS_DOMAIN() > > to indicate that it only wants to talk ENCDNS server, and it does NOT > want to have normal DNS server, then responder who do not understand > ENCDNS_IP6() will see that this is against MUST in RFC8598 and as > there is no other error to use, it will most likely consider this a > malformed message (==fatal error) and return with INVALID_SYNTAX. This > will tear down the IKE SA and does not specify for the initiator why > the connection attempt failed. The initiator cannot force the responder to do anything (e.g. to explicitly provide it with the encrypted DNS info). It can only indicate support for this feature. So, in my understanding, the above set of configuration attributes indicates some problems with initiator (in which case fatal error is not a bad solution). The correct request should be: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) INTERNAL_DNS_DOMAIN() If the responder doesn't support this extension, it will ignore ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...). If the responder supports this extension, it will return either ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + INTERNAL_DNS_DOMAIN(...) or INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on its configuration (most probably the former). If the initiator is configured to allow only encrypted DNS, it may immediately delete IKE SA in case the responder returns INTERNAL_IP6_DNS. There is nothing more the initiator can do in this case. Note, that with this approach there is no room for fatal errors, all protocol paths are legal with no need to update 8598. > Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if > INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer > them it can't add them. > > Thats why it would be better for even those RFC8598 implementations > which will not support this RFC to be modified so that they will > understand ENCDNS_IP* at least so much that they understand that they > can ignore INTERNAL_DNS_DOMAIN attribute if there is no > INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply > ignore ENCDNS_IP* (is they should, as they do not understand), and > they ignore the INTERNAL_DNS_DOMAIN also because there is no > INTERNAL_IP*_DNS then the initiator will be able to connect. And then > the initiator can later do another configuration payload to fetch > normal DNS servers ip-addresses if those would be acceptable for it. > > Or, have I misunderstood the protocol somehow. I.e., what should old > responder implementation do when it receives the request like above? I believe so. Regards, Valery. > -- > kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > > But my understanding is that this is not the case here, as if you > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > > ENCDNS_IP* to implementations supporting old RFC, > > [Med] Responders know when it will break. They will basically supply > the encrypted DNS to initiators who indicated support as per: > >Initiators first indicate support for encrypted DNS by including >ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders >supply encrypted DNS configuration by including ENCDNS_IP* attributes >in their CFG_REPLY payloads. > > If responders decide to ignore the capabilities of the initiators, > returning **only** the ENCDNS_IP* won't break only split horizon but > the full DNS service! I mean if initiator proposes: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) INTERNAL_DNS_DOMAIN() to indicate that it only wants to talk ENCDNS server, and it does NOT want to have normal DNS server, then responder who do not understand ENCDNS_IP6() will see that this is against MUST in RFC8598 and as there is no other error to use, it will most likely consider this a malformed message (==fatal error) and return with INVALID_SYNTAX. This will tear down the IKE SA and does not specify for the initiator why the connection attempt failed. Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer them it can't add them. Thats why it would be better for even those RFC8598 implementations which will not support this RFC to be modified so that they will understand ENCDNS_IP* at least so much that they understand that they can ignore INTERNAL_DNS_DOMAIN attribute if there is no INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply ignore ENCDNS_IP* (is they should, as they do not understand), and they ignore the INTERNAL_DNS_DOMAIN also because there is no INTERNAL_IP*_DNS then the initiator will be able to connect. And then the initiator can later do another configuration payload to fetch normal DNS servers ip-addresses if those would be acceptable for it. Or, have I misunderstood the protocol somehow. I.e., what should old responder implementation do when it receives the request like above? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Hi Tero, Please see inline. Cheers, Med > -Message d'origine- > De : Tero Kivinen > Envoyé : vendredi 17 mars 2023 14:29 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Patrick Mevzek ; > dns...@ietf.org; draft-ietf-ipsecme-add-ike@ietf.org; > ipsec@ietf.org; last-c...@ietf.org > Objet : RE: Dnsdir last call review of draft-ietf-ipsecme-add-ike- > 09 > > mohamed.boucad...@orange.com writes: > > > At the IETF process level, which I don't master, because of > last > > > note in §4, shouldn't that document explicitly say it updates > > > RFC8598? > > > > [Med] We discussed this point at the time (and I was personally > for > > adding the header), but we didn't because the convention in > ipsecme WG > > is to not add the Update header if implementations are clearly > able to > > distinguish the cases when an extension is being used even if > the > > extension would change the behavior defined in the existing > RFCs. In > > this spec, if the initiator receives any of ENCDNS_IP* > attributes, it > > will know that it should not expect the INTERNAL_IP*_DNS even if > it > > receives INTERNAL_DNS_DOMAIN too. The note you are referring to > is to > > make that clear. > > I think we usually use updates header if implementations > supporting old RFC but not this, needs to change their behavior. > > I.e., if we just add new attributes, and the implementations of > old RFC simply ignore them then everything is fine. > > But my understanding is that this is not the case here, as if you > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > ENCDNS_IP* to implementations supporting old RFC, [Med] Responders know when it will break. They will basically supply the encrypted DNS to initiators who indicated support as per: Initiators first indicate support for encrypted DNS by including ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply encrypted DNS configuration by including ENCDNS_IP* attributes in their CFG_REPLY payloads. If responders decide to ignore the capabilities of the initiators, returning **only** the ENCDNS_IP* won't break only split horizon but the full DNS service! then that RFC > will consider this as a fatal error, and tear down the whole IKE > SA, instead of silently ignoring ENCDNS_IP* and > INTERNAL_DNS_DOMAIN attributes. > > So in this case it would be better for the old Split DNS > Configuration for IKEv2 RFC8598 implementations to be changed in a > way that they recognize this situation and do not consider it as a > fatal error. > > Update to the RFC8598 would not be needed if the RFC8598 > implementations would simply ignore both the INTERNAL_DNS_DOMAIN > and > ENCDNS_IP* in configuration payload, but I do not think that is > the case here. > > So question is not whether it is possible to recognize the > situation, it is what happens when you combine new and old > implementations. If things works without a need to change old > implementations then no updates is needed, if you need to update > the old implentations too, then you do need updates header. > -- > kivi...@iki.fi _ 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
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > > At the IETF process level, which I don't master, because of last > > note in §4, shouldn't that document explicitly say it updates > > RFC8598? > > [Med] We discussed this point at the time (and I was personally for > adding the header), but we didn't because the convention in ipsecme > WG is to not add the Update header if implementations are clearly > able to distinguish the cases when an extension is being used even > if the extension would change the behavior defined in the existing > RFCs. In this spec, if the initiator receives any of ENCDNS_IP* > attributes, it will know that it should not expect the > INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The > note you are referring to is to make that clear. I think we usually use updates header if implementations supporting old RFC but not this, needs to change their behavior. I.e., if we just add new attributes, and the implementations of old RFC simply ignore them then everything is fine. But my understanding is that this is not the case here, as if you send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with ENCDNS_IP* to implementations supporting old RFC, then that RFC will consider this as a fatal error, and tear down the whole IKE SA, instead of silently ignoring ENCDNS_IP* and INTERNAL_DNS_DOMAIN attributes. So in this case it would be better for the old Split DNS Configuration for IKEv2 RFC8598 implementations to be changed in a way that they recognize this situation and do not consider it as a fatal error. Update to the RFC8598 would not be needed if the RFC8598 implementations would simply ignore both the INTERNAL_DNS_DOMAIN and ENCDNS_IP* in configuration payload, but I do not think that is the case here. So question is not whether it is possible to recognize the situation, it is what happens when you combine new and old implementations. If things works without a need to change old implementations then no updates is needed, if you need to update the old implentations too, then you do need updates header. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Hi Patrick, Thank you for the careful review. Really appreciated. A candidate version to address your review can be seen at: https://tinyurl.com/add-ike-latest. Let's us know if any further change is needed. Please see inline for more context. Cheers, Med > -Message d'origine- > De : Patrick Mevzek via Datatracker > Envoyé : jeudi 16 mars 2023 21:44 > À : dns...@ietf.org > Cc : draft-ietf-ipsecme-add-ike@ietf.org; ipsec@ietf.org; > last-c...@ietf.org > Objet : Dnsdir last call review of draft-ietf-ipsecme-add-ike-09 > > Reviewer: Patrick Mevzek > Review result: Ready with Nits > > I have been selected as the DNS Directorate reviewer for this > draft. The DNS Directorate seeks to review all DNS or DNS-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to > provide assistance to the ADs. > For more information about the DNS Directorate, please see > https://wiki.ietf.org/en/group/dnsdir > > There are clear and direct references to various DNS RFCs and > currently active IDs and this draft is not in any major conflict > with the wider DNS space. > > At the IETF process level, which I don't master, because of last > note in §4, shouldn't that document explicitly say it updates > RFC8598? [Med] We discussed this point at the time (and I was personally for adding the header), but we didn't because the convention in ipsecme WG is to not add the Update header if implementations are clearly able to distinguish the cases when an extension is being used even if the extension would change the behavior defined in the existing RFCs. In this spec, if the initiator receives any of ENCDNS_IP* attributes, it will know that it should not expect the INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The note you are referring to is to make that clear. Other WGs would follow a distinct approach. This is one of the areas where a more consistent approach should be followed in the IETF. > > I do have the following nits or questions from a client > implementor point of view to report, which may be caused by my own > very superficial knowledge of IKE, so feel free to ignore as > irrelevant: > > - §3.1 > > "Length (2 octets, unsigned integer) - Length of the data in > octets." > > It is explained further how it is computed, but just this sentence > alone is unclear for someone implementing it as not stating length > of which part of the content (as the length field is kind of "in > the middle" of the content itself) Med: Made this change: s/Length of the data in octets/Length of the enclosed data in octets I think this change with the text right after this one is clear how to set the field. Please let us know if you still think is not sufficiently clear. > > In §3.2, there is "Length (2 octets, unsigned integer) - Length of > the data in octets." as well, with then no explanation on which > data to consider for the length. > Med: Added this NEW text: OLD: Length (2 octets, unsigned integer) - Length of the enclosed data in octets. NEW: Length (2 octets, unsigned integer) - Length of the enclosed data in octets. This field MUST be set to "2 + 2 * number of included hash algorithm identifiers". > "Authentication Domain Name (variable) - A fully qualified domain > name of the encrypted DNS resolver following the syntax defined in > [RFC5890]." > > Maybe specify which part of RFC5890? > But I agree not finding myself there a single section clearly for > that point, nor is the DNS terminology RFC providing a single > definition. > Med: Fair point. We can reuse similar wording as in RFC8598 and indicate the following: "in DNS presentation format and using an Internationalized Domain Names for Applications (IDNA) A-label [RFC5890]." > - §3.2 > > "List of Hash Algorithm Identifiers (variable) - Specifies a list > of 16-bit hash algorithm identifiers that are supported by the > encrypted DNS client." > > Is order of items in the list relevant or not? Med: No. > > "Note that SHA2-256 is mandatory to implement." > > SHA2-256 is only defined later in the document, at section 5 with: > "Implementations MUST support SHA2-256 [RFC6234]." > > So the reference might need to be moved to its first appearance, > from section 5 to 3.2 Med: We already added a reference to that section as per a comment we received from Dhruv (opsdir). > > Also, I don't know if it is customary from elsewhere, but RFC6234 > does not talk at all about SHA2-256 only about SHA256 or SHA-256, > no "SHA2". So maybe use the same moniker? > Same for other lengths, including in all examples at end. > > I see that > https://www.iana.org/assignments/ikev2-parameters/ikev2- > parameters.xhtml#hash-algorithms > references RFC7427 instead, which does use SHA2-256 terminology, > so maybe better to reference RFC7427 instead of RFC6234 above? > Med: We use SHA2-256 as this is the label in the aut
