Enhanced Feasible-Path Unicast Reverse Path Forwarding
draft-ietf-opsec-urpf-improvements-04

(1) I support Alvaro Retana’s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made about Algorithm A.

(2) Editorial

-- Document header: s/Updates: RFC3704/Updates: 3704/

-- Section 2.1.  Editorial.  s/are maintained which list/are maintained to list/

Thank you for the hard work put into this extensive document which is usually well-written and easy to understand. 

Sriram, also please to see this document completing its path after starting in OPSEC years ago ;-)

Nevertheless, I have a couple of easy-to-fix COMMENTs and NITs.

Regards,

-éric

== COMMENTS ==

-- Abstract --
The abstract reads like 'promises' but not as a summary of the document. Is there any chance to add 2 lines summarizing the 'how' ?

-- Section 1.1 --
I am sure that by now you know that you have to use RFC 8174 boilerplate ;-)

-- Section 2.2 --
For completeness and symmetry with section 2.3, please explain which packets will be dropped.

-- Section 2.3 --
Suggestion: define "RPF list" before first use (even if mostly obvious).

Please define "lateral peer" and why it is different to any other "peer".
 
-- Section 3.1 --
Please define the "cone" used in this section. First time that I ever read this term and the RIPE paper does not explain it either (of course I am not a routing expert).

== NITS ==

-- Section 1 --
Beside the intro, this section also introduces some terminology wording. May I suggest to have a (sub)section about "terminology" ? 

-- Section 2.1 --
CMTS was introduced as an acronym but not DSLAM.

Thanks for a clearly written document. My understanding of routing is pretty
simplistic, and I still found the technique well-explained and easy to follow.
This is no small feat. The one term I had to go searching for was "stub AS". If
this is a generally known term, that's fine -- but if not, it may warrant a
short definition or citation.

---------------------------------------------------------------------------

§1.1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in RFC 2119 [RFC2119].

Please use the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§3.3:

I believe I understand how the described Algorithm B, is applied by AS4, will
result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about
the means by which AS2 will accept them such that they could be delivered to
AS4.  Is there an assumption that AS2 is employing an ACL-based approach? If
so, this should probably be stated explicitly. (This might be implied by text
elsewhere, in which case I apologize for my confusion; although it may still be
worth explicitly explaining.)

---------------------------------------------------------------------------

§3.5:

>  It is worth emphasizing that an indirect part of the proposal in the
>  draft is that RPF filters may be augmented from secondary sources.

Nit: "the draft" won't age gracefully. I suggest changing to "this document"
or somesuch.

---------------------------------------------------------------------------

§3.6.1:

>  +---------------------------------+---------------------------------+
>  | Very Large Global ISP           | 32392                           |
>  | ------------------------------- | ------------------------------- |
>  | Very Large Global ISP           | 29528                           |
>  | ------------------------------- | ------------------------------- |

I suspect there was a transcription error copying these lines from the source
material, as the appearance of two rows with identical labels seems unlikely
to be intended. I skimmed the cited source material to see if I could figure
out what happened here, but found neither of these numbers (nor any mention of
"Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a
fix. I did find that adding the numbers in the first column on slide 6
yielded 32393, which is tantalizingly close to the first number, but that
might just be a coincidence.

Thank you for this well-written document!  It will be beneficial to the
security of the internet as a whole to have effective BCP38 protections
applied more widely.

I'm happy to see the discussion about Algorithm A vs. B as recommended
default, prompted by Alvaro's ballot position.  On the face of things I
do share his concern, as having "safe defaults" in the sense of not
dropping legitimate traffic seems pretty compelling, but I do recognize
that Algorithm A produces a stricter check, and that is in a different
sense "more safe".  I don't think I have much to add to the discussion,
though, so I'll continue to watch it play out.  (Perhaps some of the
discussion could make it into the security considerations of this
document once things get settled, though.)

Section 2.1

   dropped.  The ACLs for the ingress/egress filters need to be
   maintained to keep them up to date.  Updating the ACLs is an operator
   driven manual process, and hence operationally difficult or
   infeasible.

nit: hyphenate "operator-driven"

Section 2.2

In Figure 1, I'm having a hard time understanding why feasible-path uRPF
fails for case (2).  Or is the intent of the caption and terminology
note from above only to say that it fails for at least one of the
enumerated cases?  (On the other hand, there's a decent chance that the
lack of comprehension is entirely on my end...)

Section 2.3

   can be described as follows.  In Scenario 2 (described above,
   illustrated in Figure 2), it is possible that the second transit
   provider (ISP-b or AS3) does not propagate the prepended route for
   prefix P1 to the first transit provider (ISP-a or AS2).  This is
   because AS3's decision policy permits giving priority to a shorter
   route to prefix P1 via a lateral peer (AS2) over a longer route
   learned directly from the customer (AS1).  In such a scenario, AS3
   would not send any route announcement for prefix P1 to AS2 (over the

I expect this is just my lack of familiarity here, but does the decision
policy "giving priority" to shorter routes vs customer routes mean that
it won't propagate the customer advertisement at all or just that it
won't route traffic that way?

Section 3.2

   o  Additionally, from the routes it has learned from customers, a
      non-stub AS SHOULD announce at least one route per origin AS to
      each of its transit provider ASes.

What are the security consequences of this?  If, say, an AS only get
very specific prefixes with very short paths from a customer and is now
"forced" to advertise at least one of them by these practices, can that
have a negative impact on routing?  Would prepending itself in the path
be a usable mitigation?

Section 3.4

nit: there's perhaps room for harmonization of language between step (3)
here and step (1) of Algorithm A.

   4.  Create the set of all unique prefixes for which routes exist in
       Adj-RIB-Ins of all lateral peer and transit provider interfaces

Is the intention that "lateral peer and transiti provider interfaces" is
equivalent to "all interfaces that are not directly-connected customer
interfaces"?

Section 3.6.1

   The techniques described in this document require that there should
   be additional memory (i.e., TCAM) available to store the RPF lists in

nit: TCAM isn't listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt , so we
probably have to expand it.

   The following table shows the measured customer cone sizes for
   various types of ISPs [sriram-ripe63]:

The table contents make it seem like these are not "per-type" data, but
rather specific data from hopefully representative samples.  In
particular...

   +---------------------------------+---------------------------------+
   | Type of ISP                     | Measured Customer Cone Size in  |
   |                                 | # Prefixes (in turn this is an  |
   |                                 | estimate for RPF list size on   |
   |                                 | line card)                      |
   +---------------------------------+---------------------------------+
   | Very Large Global ISP           | 32392                           |
   | ------------------------------- | ------------------------------- |
   | Very Large Global ISP           | 29528                           |

... perhaps these should be #1 and #2 to disambiguate.

Section 3.7

       *  In general, loose uRPF method for SAV SHOULD be applied on
          lateral peer and transit provider interfaces.  However, for
          lateral peer interfaces, in some cases an operator MAY apply
          EFP-uRPF method with Algorithm A if they deem it suitable.

Since step (1) of Algorithm A explicitly says "of customer interfaces",
we probably need a little bit more text here to say what it means to use
Algorithm A for lateral peer and/or transit provider interfaces.  (Or,
perhaps, some reworking of the text describing Algorithm A, but that
seems like a more invasive change.

Section 4

This is rather related to Alvaro's Discuss, but how is an AS operator to
know what type of peer and the nature of customer cone scenario that
applies to a given case?

Also, is there a way to know what the probability of dropping legitimate
data packets is other than experimenting and waiting for customer
complaints?

(I guess it's probably okay, given the references, to not bother
explicitly saying "erroneously dropping legitimate packets is bad".)

   Ingress/egress Access Control Lists (ACLs) are maintained which list
   acceptable (or alternatively, unacceptable) prefixes for the source
   addresses in the incoming/outgoing Internet Protocol (IP) packets.
the beginning of that sentence is a bit hard to parse, but maybe it's just for me.

   Any packet with a source address that does not match the filter is
   dropped.
well, that really depend on the match criteria. If the list is of unacceptable addresses and you don't match on these, then you should forward the packet.

   Adj-RIB-Ins
did you mean Adj-RIBs-In?

Figures 1 and 2 claim that EFP-uRPF works best but it has still not been described at that stage so it is a bit difficult to understand that claim.