Paul Wouters has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-12: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a DISCUSS similar to Roman: Existing security extensions as described in [RFC5340] and [RFC8362] apply to these SRv6 extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. RFC5340 does say to use IPsec, but because of the "group" setting, IKE could not be used (I guess it pre-dates or didn't want to use Group DOI (GDOI) RFC3547 and Group Secure Association Key Management Protocol (GSAKMP) RFC4535). But RFC 4552 is recommending IPsec with manual keying, which is no longer really possible with AEAD ciphers (eg AES-GCM, which you would want to use for performance). It does state: Future specifications can explore the usage of protocols like Kerberized Internet Negotiation of Keys/Group Secure Association Key Management Protocol (KINK/GSAKMP) when they are widely available. But I don't think KINK/GSAKMP became widely available. GDOI has seen some but not much implementation. Furthermore, RFC4535 is also a (not widely implemented) IKEv1 extension. This cannot be recommended anymore because IKEv1 itself is obsolete (see RFC9395) Updated advise would be to use draft-ietf-ipsecme-g-ikev2 "Group Key Management using IKEv2, but again we don't know yet if this will be widely available. That puts us back at "use manual keying or this soon to hopefully be available IKEv2 RFC", except that with AEADs, we also cannot recommend manual keying anymore. I am not sure what to recommend as text here. Removing all IKEv1 references and putting draft-ietf-ipsecme-g-ikev2 there and saying manual keying MUST NOT be used is not a good security recommendation either. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
