Ballot for draft-ietf-opsec-urpf-improvements
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(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.