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

# Éric Vyncke, INT AD, comments for draft-ietf-savnet-intra-domain-problem-statement-11
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. I am balloting ABSTAIN because I have too many 'near DISCUSS' points.

I am strongly supporting Gunter's DISCUSS about the lack of reference to RFC8704 (Enhanced Feasible-RPF), especially as we were the two OPSEC WG chairs ;-)

Special thanks to Xueyan Song for the shepherd's write-up including the WG consensus *and* the justification of the intended status. But, I find `The Shepherd did not find any other working areas have identified the same issues addressed in this document` a little light.

Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-savnet-intra-domain-problem-statement/reviewrequest/21463/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Host vs. node

"Host" is mainly used for plain node without forwarding capability and "node" is any node with or without forwarding capability. AFAIK, this document should rather use "node" than "host".

### Section 1

Like Erik Kline, I find the use of domain = AS a little limiting.

s/a host must use the source IP address assigned to the host/a *node* must use *one* source IP address assigned to the *node*/

`access network SAV (i.e., IP address)` mainly applies to IPv4 only as it is typical in IPv6 network to assign one prefix for one client. Strongly suggest rewriting.

s/This document focuses on the analysis of intra-domain SAV/This document focuses *only* on the analysis of intra-domain SAV/

Isn't this a solved problem: `blocking source-spoofed packets coming from other ASes using a source address of this AS` ?

### Section 2

What is the "INSIDE access list" in `If the source address of a packet is in the INSIDE access list` ?

### Section 3.1

I was about to raise a DISCUSS on this point as several routers are able to prevent spoofing based on snooped DHCP-PD prefix delegation. I fear this I-D has only IPv4 in mind :-(

### Section 3.1.1

As noted, this is only an issue with strict mode URPF.

### Section 5

This would be nice to have a link between requirements in this section and the issues of section 3.

### Section 5.1

The 2nd paragraph is not about requirements but more about solution space, suggest removing it.

### Section 5.2

I was also about to ballot a DISCUSS... this section is underspecified, e.g., it should include DHCP-PD snooping to get the delegated prefix in some cases (in addition to routing). Should PCE be mentioned ?

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

Thank you to Tim Evan for the GENART review.

I am balloting ABSTAIN because I am challenged in understanding how the requirements portion of this document is to be interpreted given their normative guidance but extremely vague details.  As written, I question if the current text is sufficient to guide the “design [of a] … new intra-domain SAV mechanism.” (per Section 5).

I am equally confused by this statement in the shepherd review “This document provides a gap analysis and problem statement of existing SAV mechanisms. It's not related to protocol design.”  If the requirements aren’t related to a protocol, who are they for?  Why are they here?

I acknowledge that the SAVNET charter calls for a “Problem Statement, Use Cases, and Requirements” document.  It remains silent whether it should be published.

Below are areas of clarity that would benefit the document:

** Section 1.  The term “multi-fence architecture” is used a few times.  Can this concept be explained more clearly.  I thought this might be a term of art, but the few search engines I tried reference this document.  Is this a “defense in depth” term?

** Section 1.
   Given numerous access networks managed by different operators
   throughout the world, it is difficult to require all access networks
   to deploy SAV
.
Perhaps a reference on the difficulty of implementing SAV on access networks would be helpful.

** Section 2.  Editorial.  Why is the Carrier Grade NAT text the only one that discusses limitations of the technology as a solution?  Is there nothing to say about uRFP or ACLs?

** Section 3.1.2.
   For special business purposes, a host/customer network will originate
   data packets using a source address that is not distributed through
   intra-domain routing protocol.  

What is “special business purposes”?

** Section 4.  This section is titled “Problem Statement” which I typically interpret as a statement of the problem to solve.  However, the text seems to be discussing the inadequacy of existing solutions.

** Section 5.1
   Improper permit SHOULD be reduced as
   much as possible so that data packets with spoofed source addresses
   can be effectively blocked.

-- What is an “improper permit”?

-- What does it mean to “reduce as much as possible” with an already non-mandatory “SHOULD”?  How does one know one has satisfied “as much as possible”?  When can one ignore this sentence since it is only a “SHOULD”?

** Section 5.1
  When the network changes, the new
   mechanisms MUST efficiently update SAV rules to guarantee the
   accuracy of SAV.

What is the definition of “efficient”?  How will know it has been realized?  Is the definition contextual?

** Section 5.3
   The new intra-domain SAV mechanism SHOULD NOT assume pervasive
   adoption.

When is it acceptable to assume there is pervasive adoption (since this text is written as a SHOULD not a MUST)?

** Section 5.3
   In
   addition, it SHOULD outperform the current ones in the same
   incremental deployment scenario.

What is the metric of performance what must be “outperformed”?  

** Section 5.3.  How is this section specifying a requirement if all of the text is describing behavior which is optional (i.e., only SHOULDs)

** Section 5.4
   To this end, routers MUST NOT
   signal too much information

How does an implementer use this requirement if “too much” is quantified or contextualized?

** Section 5.5
   Necessary security tools SHOULD be considered in the new intra-domain
   SAV mechanism. 

-- What are “necessary security tools”?

-- Why would be acceptable to ignore “necessary security tools” in the design (again because this is a SHOULD)?

I concur with the ARTART review (thanks to Robert Sparks) and Roman's observations that it's unclear that this should be published.  I also concur with the observation that was made about the peculiarity of a problem statement document making normative assertions about something.

(Note that I have not reviewed its apparent companion "-inter-" document.)

These are things that should be confirmed with or reviewed prior to the document moving forward.  I can't support its progress in its current form, but I won't obstruct progress either, hence I'm balloting ABSTAIN.