Hi Roman, Please check if the update posted below addresses your concerns: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-13
Thanks, Ketan On Tue, Jun 6, 2023 at 1:52 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > 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
