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? ---------------------------------------------------------------------- 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. _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
