Hi Paul, > On Jun 6, 2023, at 21:43, Paul Wouters via Datatracker <nore...@ietf.org> > wrote: > > 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.
Let me help you out here. What you are saying that OSPFv3 IPsec could benefit from recent key management protocols which are still drafts. We invite you submission of an LSR draft to fill this gap. I don’t see how this can be considered a DISCUSS on these SRv6 OSPFv3 extensions. IMO, this DISCUSS is frivolous and should be cleared immediately. Note that we have https://datatracker.ietf.org/doc/rfc7166/ for authentication which Supports both replay protection and graceful key rollover with manual keying. Thanks, Acee > > > > > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
