Problem Statement, Gap Analysis, and Requirements for Intra-domain Source Address Validation
draft-ietf-savnet-intra-domain-problem-statement-25

** Section 5.1
   Any new intra-domain SAV mechanism MUST improve the accuracy of
   source address validation compared to existing uRPF-based mechanisms.
   In particular, it MUST reduce the occurrence of improper blocks
   (i.e., blocking legitimate traffic), improper permits (i.e., allowing
   spoofed traffic), or both.  Specifically, it MUST satisfy the
   following conditions:

   *  result in fewer improper blocks than strict uRPF, particularly in
      scenarios involving asymmetric routes or hidden prefixes;

   *  result in fewer improper permits than loose uRPF.

How would the measurement of this approach be computed?  Would the accuracy have to hold for any arbitrary configuration?  Would it be possible for some configuration to make strict+loose uPRF equivalent to this new mechanism?

** Section 5.2
   Any new intra-domain SAV mechanism MUST be capable of automatically
   generating and updating SAV rules on routers, rather than relying
   entirely on manual updates as in ACL-based SAV.  Automation helps
   reduce operational complexity and maintenance overhead, while
   allowing some initial configuration to improve SAV accuracy.  This
   ensures the mechanism is deployable in practical networks without
   introducing excessive management burden.

I think I understand the requirement in the sense that there is a desire to add automation to the process.  What I’m hoping the text could clarify is why automation can’t be added to ACL-based SAV, and why it is considered entirely manual.

** Section 5.4
   Second, such mechanism MUST NOT transmit excessive SAV-specific
   information via a protocol, as this could significantly increase the
   burden on the routers’ control planes and potentially degrade the
   performance of existing protocols.

How would one know that they aren’t transmitting “excessive” to meet this requirement?

One sentence summary: I would like to discuss why the authors and WG believe this needs to be published as an RFC, and if that results in a good reason to do so, how the current hand waving of security requirements can be improved.

I echo what other ADs are raising. In my experience, WGs do well with having their own requirements document with WG consensus but not publishing as an RFC. For example, add and deleg both took this approach. It would save going through the much more stringent bar of IESG review over what the WG knows they need to define success amongst themselves for future documents.

However, I am reviewing as if there are good reasons to publish as an RFC that I'm not aware of. As such, I want to bring up the same bit Roman did, which jumped out at me:

>   Any new intra-domain SAV mechanism MUST NOT introduce additional
>   security vulnerabilities to existing intra-domain architectures or
>   protocols. 

As a WG document, I would say this is underspecified but maybe the WG knows what they mean. As an RFC, I do not think this is appropriate at all. Combining this with the Security Considerations that says this introduces no new considerations and I do not think this document says much that is meaningful to people outside your very specific context. It's possible some of this may be obvious to your WG even if not written down because of context for terminology (i.e. "vulnerability" means something specific like "attack surface represented by the presence of a node" to say "MUST NOT introduce additional hops to existing..."). If so, that needs to be defined here, as it currently could be interpreted as "MUST NOT introduce the potential for CVEs" or a number of other things that are quite difficult to mandate normatively.

For an example of how security considerations can still apply to a requirements document, check out Section 4 of the add WG's requirements document (which is what their Security Considerations section links to): https://datatracker.ietf.org/doc/html/draft-ietf-add-requirements-00

All this becomes non-applicable if this is a document the WG writes for themselves, setting aside that then my review isn't needed anyway, because there's some wiggle room for WGs to "know what they meant" since the WG itself can shift its take on requirements as work on drafts meeting those requirements proceeds. This isn't a flexibility given once it is published as an RFC however.