Hi Paul, This document is specifying extensions for OSPFv3 for SRv6. Any discussion related to changing or improving security for base OSPFv3 protocol would be outside the scope of this document.
Regarding IPSec and IKE, FWIW, lately I have seen operators requesting RFC7166 (OSPFv3 Auth Trailer) over the IPSec method of RFC5340. That said, can you please check on my response and proposed text changes to Roman and let me know if those work for you? https://mailarchive.ietf.org/arch/msg/lsr/51bzckFrw_YCtIGiA1BikDVhyoU/ Thanks, Ketan On Wed, Jun 7, 2023 at 7:13 AM 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. > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
