Hi Roman, Thanks for your review and comments. Please check inline below for responses.
On Tue, Jun 6, 2023 at 3:46 AM Roman Danyliw via Datatracker < nore...@ietf.org> wrote: > Roman Danyliw 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: > ---------------------------------------------------------------------- > > ** Section 12. > > 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. > > Please rewrite this guidance. It appears to be saying that in networks > with > potential attackers stronger authentication mechanisms SHOULD be used. > With > the use of the language of "_potential attacker" and "_one_ or more", > isn’t > that all networks? Is this equivalent to strong auth SHOULD be used? > KT> I see your point. How about the following? Stronger authentication mechanisms such as those specified in [RFC4552 <https://www.rfc-editor.org/info/rfc4552>] or [RFC7166 <https://www.rfc-editor.org/info/rfc7166>] SHOULD be used in OSPFv3 deployments. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ** Section 12. This document cites the applicability of RFC8362’s Security > Considerations whose primary guidance appears to be: > > If there were ever a requirement to digitally sign OSPFv3 LSAs as > described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the > mechanisms described herein would greatly simplify the extension. > > Is the signature mechanism in RFC2154 still considered viable and needed? > I > note that it was published with experimental status in 1997 and supports > only > one signature-hash mechanism, RSA-MD5, despite having seemingly robust > extensibility mechanisms via > https://www.iana.org/assignments/ospf-sig-alg/ospf-sig-alg.xhtml. > > KT> I am not aware of those mechanisms being implemented or deployed. I would be happy to be corrected. That said, the reference to RFC8362 was because we are building on top of the specifications therein. All aspects other than this one about signatures are covered in this document already. We can remove the reference to RFC8362 from this section, if that works. Thanks, Ketan
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
