Enhanced Feasible-Path Unicast Reverse Path Forwarding
draft-ietf-opsec-urpf-improvements-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-03
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-01-30
|
04 | (System) | RFC Editor state changed to AUTH48 from TI |
2020-01-28
|
04 | (System) | RFC Editor state changed to TI |
2020-01-10
|
04 | (System) | RFC Editor state changed to TI from AUTH48 |
2019-12-23
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-10-18
|
04 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Carlos Martínez was marked no-response |
2019-10-15
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-09-09
|
04 | Wesley Eddy | Request closed, assignment withdrawn: Brian Trammell Last Call TSVART review |
2019-09-09
|
04 | Wesley Eddy | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2019-09-05
|
04 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Derek Atkins was marked no-response |
2019-09-03
|
04 | (System) | RFC Editor state changed to EDIT |
2019-09-03
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-09-03
|
04 | (System) | Announcement was received by RFC Editor |
2019-09-03
|
04 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-09-03
|
04 | (System) | IANA Action state changed to In Progress |
2019-09-03
|
04 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2019-09-03
|
04 | Cindy Morgan | IESG has approved the document |
2019-09-03
|
04 | Cindy Morgan | Closed "Approve" ballot |
2019-09-03
|
04 | Cindy Morgan | Ballot approval text was generated |
2019-08-30
|
04 | Alvaro Retana | [Ballot Position Update] Position for Alvaro Retana has been changed to Yes from Discuss |
2019-08-30
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-30
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-08-30
|
04 | Kotikalapudi Sriram | New version available: draft-ietf-opsec-urpf-improvements-04.txt |
2019-08-30
|
04 | (System) | New version approved |
2019-08-30
|
04 | (System) | Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas |
2019-08-30
|
04 | Kotikalapudi Sriram | Uploaded new revision |
2019-08-28
|
03 | Pete Resnick | Assignment of request for Last Call review by GENART to Pete Resnick was rejected |
2019-08-22
|
03 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-08-22
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-08-22
|
03 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-08-21
|
03 | Min Ye | Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Matthew Bocci. |
2019-08-21
|
03 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-08-21
|
03 | Benjamin Kaduk | [Ballot comment] Thank you for this well-written document! It will be beneficial to the security of the internet as a whole to have effective BCP38 … [Ballot comment] 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".) |
2019-08-21
|
03 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-08-21
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-08-21
|
03 | Éric Vyncke | [Ballot comment] Thank you for the hard work put into this extensive document which is usually well-written and easy to understand. Sriram, also please to … [Ballot comment] 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. |
2019-08-21
|
03 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-08-21
|
03 | Martin Vigoureux | [Ballot comment] Ingress/egress Access Control Lists (ACLs) are maintained which list acceptable (or alternatively, unacceptable) prefixes for the source addresses in the … [Ballot comment] 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. |
2019-08-21
|
03 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-08-20
|
03 | Adam Roach | [Ballot comment] Thanks for a clearly written document. My understanding of routing is pretty simplistic, and I still found the technique well-explained and easy to … [Ballot comment] 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. |
2019-08-20
|
03 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-08-20
|
03 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-08-20
|
03 | Roman Danyliw | [Ballot comment] (1) I support Alvaro Retana’s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made … [Ballot comment] (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/ |
2019-08-20
|
03 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-08-19
|
03 | Warren Kumari | Forgot to change state. |
2019-08-19
|
03 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2019-08-16
|
03 | Alvaro Retana | [Ballot discuss] I have significant concerns about the recommendation (in §3.7) to use Algorithm A. I think that the considerations to select an Algorithm are … [Ballot discuss] I have significant concerns about the recommendation (in §3.7) to use Algorithm A. I think that the considerations to select an Algorithm are not clear and potentially impossible to verify. Also, the selection of Algorithm A creates a vulnerability that could result in legitimate traffic dropped. §3.7 (Summary of Recommendations) says that "if the scenario does not involve complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be applied on customer interfaces." From Figure 4, how does the operator of ISP4 know that it is not in a "challenging scenario" (§3.3)? How can ISP4 tell the difference between ISP2 not propagating routes vs it not even being connected to AS1? By definition, each autonomous system can have its own set of policies, which may not be known by any of their upstreams. In short, I find the guidance provided in the document to select an algorithm not clear enough to really be actionable -- specially in a document tagged to be a BCP. Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because he/she thinks they may not be in a "challenging scenario"), then it opens the door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was flowing fine and then it stopped. I am balloting DISCUSS because the guidance provided for the selection of an Algorithm is not clear enough to be certain that the selection is the correct one; and the election of Algorithm A creates a vulnerability (as explained in the text) that is not mentioned. |
2019-08-16
|
03 | Alvaro Retana | [Ballot comment] (1) The implementation of the EFP-uRPF method is expected at a transit AS. However, that AS has no control over what the origin … [Ballot comment] (1) The implementation of the EFP-uRPF method is expected at a transit AS. However, that AS has no control over what the origin AS and others announce. I find the use of rfc2119 keywords in §3.2 inappropriate because none of the actions are under the control of the AS implementing uRPF and can't be Normatively enforced. (2) §3.5: "Prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF lists." How? Note that the Introduction already sets the stage by saying that "the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." If ROAs SHOULD be used (§3.5), why is origin validation only "possibly (in the future)" considered (§1)? Maybe a better statement would be that "routes SHOULD be validated using prefix filtering, origin validation and IRR route objects". (3) How does EFP-uRPF work when multiple border routers are present in the AS, some customer facing and some not (which I assume to be the normal case)? I'm asking because §3.1 describes the method when "prefixes with the same origin AS were received on different interfaces (at border routers)", and the example talks about the Local Adj-RIB-Ins. I think there's a missing explanation of how the routers with the customer-facing interfaces learn about *all* the received routes if the local policy might select a single BGP best route. OTOH, maybe I'm missing something. (4) The document assumes familiarity with terminology such as "customer cone" or "lateral peer", that is not explained anywhere. The average operator will most likely know what those terms mean and how they apply to their network. However, those operators are not the only people reviewing this document. A short explanation or reference would be nice. (5) Please use the rfc8174 template. (6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to be part of BCP 84, is that correct? I'm not sure how to let the RFC Editor know that is the intent, but it should be made clear somewhere. |
2019-08-16
|
03 | Alvaro Retana | [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana |
2019-08-15
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-08-15
|
03 | Warren Kumari | Ballot has been issued |
2019-08-15
|
03 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2019-08-13
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2019-08-13
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Martínez |
2019-08-12
|
03 | Min Ye | Request for Telechat review by RTGDIR is assigned to Matthew Bocci |
2019-08-12
|
03 | Min Ye | Request for Telechat review by RTGDIR is assigned to Matthew Bocci |
2019-08-12
|
03 | Alvaro Retana | Requested Telechat review by RTGDIR |
2019-08-08
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2019-08-08
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2019-08-08
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-08-08
|
03 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-urpf-improvements-03, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-urpf-improvements-03, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-08-05
|
03 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2019-08-05
|
03 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2019-08-01
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-08-01
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2019-08-01
|
03 | Cindy Morgan | Placed on agenda for telechat - 2019-08-22 |
2019-08-01
|
03 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-08-01
|
03 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-08-15): From: The IESG To: IETF-Announce CC: draft-ietf-opsec-urpf-improvements@ietf.org, opsec-chairs@ietf.org, Sandra Murphy , opsec@ietf.org, … The following Last Call announcement was sent out (ends 2019-08-15): From: The IESG To: IETF-Announce CC: draft-ietf-opsec-urpf-improvements@ietf.org, opsec-chairs@ietf.org, Sandra Murphy , opsec@ietf.org, sandy@tislabs.com, warren@kumari.net Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Enhanced Feasible-Path Unicast Reverse Path Filtering) to Best Current Practice The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Enhanced Feasible-Path Unicast Reverse Path Filtering' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see BCP 84). However, as shown in this draft, the existing feasible-path uRPF still has shortcomings. This document describes an enhanced feasible-path uRPF technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF. It can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - IETF stream) |
2019-08-01
|
03 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-08-01
|
03 | Cindy Morgan | Last call was requested |
2019-08-01
|
03 | Cindy Morgan | IESG state changed to Last Call Requested from Publication Requested |
2019-08-01
|
03 | Cindy Morgan | Last call announcement was generated |
2019-08-01
|
03 | Cindy Morgan | Removed from agenda for telechat |
2019-08-01
|
03 | Cindy Morgan | Placed on agenda for telechat - 2019-08-08 |
2019-08-01
|
03 | Warren Kumari | Ballot has been issued |
2019-08-01
|
03 | Warren Kumari | Ballot approval text was generated |
2019-08-01
|
03 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2019-08-01
|
03 | Warren Kumari | Created "Approve" ballot |
2019-08-01
|
03 | Warren Kumari | Ballot writeup was changed |
2019-07-15
|
03 | Ron Bonica | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document requests publication as Best Current Practice. This is indicated in the header. BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique. The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP. The presented technique is an enhancement of a technique specified in RFC3704. The document updates RFC3704. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF technique is inflexible about directionality, the loose uRPF technique is oblivious to directionality, and the current feasible-path uRPF technique attempts to strike a balance between the two (see BCP 84). However, as shown in this draft, the existing feasible-path uRPF technique still has shortcomings. This document describes an enhanced feasible-path uRPF technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF technique. It can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques.. Working Group Summary The document was discussed in grow and in opsec, and adopted by opsec. Discussions in both working groups were incorporated into the document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The shepherd sees no wg mail indicating that there are are current software implementations. However, the draft containS a section “Implementation Considerations” that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique. One wg comment explicitly said that the document was clear enough to “assist the operators to better implement the recommendations”. No MIB Doctor, Media Type, or other expert review was required. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Sandra Murphy Responsible Area Director: Warren Kumari (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the document, references, and the wg discussions and presentations. The draft was presented and discussed in the grow wg, and those interactions were also reviewed. The authors have incorporated shepherd comments into the latest version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, there are no document portions that need additional review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The shepherd has no concerns or issues with the current version of the draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. All authors of this document have confirmed on the wg list that they know of no IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The shepherd sees no IPR disclosure notice on the wg email list. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The wg adoption discussion was energetic. That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic. The document as an individual contribution was first discussed in the grow wg. This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104 In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tool reports: Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). One warning concerns the format of the Updates line in the document header. The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of “[“ in a notation. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. There are no features of the draft that require formal review. (13) Have all references within this document been identified as either normative or informative? Yes. All references are divided into normative and informative sections. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All IETF documents in the references are RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document header notes that the document will update RFC3704. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). None required. There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None required. There are no new IANA registries created by this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None required. There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language. |
2019-07-15
|
03 | Ron Bonica | Responsible AD changed to Warren Kumari |
2019-07-15
|
03 | Ron Bonica | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-07-15
|
03 | Ron Bonica | IESG state changed to Publication Requested from I-D Exists |
2019-07-15
|
03 | Ron Bonica | IESG process started in state Publication Requested |
2019-07-11
|
03 | Sandra Murphy | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The document requests publication as Best Current Practice. This is indicated in the header. BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique. The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP. The presented technique is an enhancement of a technique specified in RFC3704. The document updates RFC3704. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF technique is inflexible about directionality, the loose uRPF technique is oblivious to directionality, and the current feasible-path uRPF technique attempts to strike a balance between the two (see BCP 84). However, as shown in this draft, the existing feasible-path uRPF technique still has shortcomings. This document describes an enhanced feasible-path uRPF technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF technique. It can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques.. Working Group Summary The document was discussed in grow and in opsec, and adopted by opsec. Discussions in both working groups were incorporated into the document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The shepherd sees no wg mail indicating that there are are current software implementations. However, the draft containS a section “Implementation Considerations” that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique. One wg comment explicitly said that the document was clear enough to “assist the operators to better implement the recommendations”. No MIB Doctor, Media Type, or other expert review was required. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Sandra Murphy Responsible Area Director: Warren Kumari (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the document, references, and the wg discussions and presentations. The draft was presented and discussed in the grow wg, and those interactions were also reviewed. The authors have incorporated shepherd comments into the latest version. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No, there are no document portions that need additional review. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The shepherd has no concerns or issues with the current version of the draft. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. All authors of this document have confirmed on the wg list that they know of no IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The shepherd sees no IPR disclosure notice on the wg email list. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The wg adoption discussion was energetic. That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic. The document as an individual contribution was first discussed in the grow wg. This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104 In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The nits tool reports: Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). One warning concerns the format of the Updates line in the document header. The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of “[“ in a notation. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. There are no features of the draft that require formal review. (13) Have all references within this document been identified as either normative or informative? Yes. All references are divided into normative and informative sections. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. All IETF documents in the references are RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The document header notes that the document will update RFC3704. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). None required. There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None required. There are no new IANA registries created by this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None required. There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language. |
2019-07-11
|
03 | Sandra Murphy | {\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf600 {\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fnil\fcharset204 PTSerif-Regular;\f2\fmodern\fcharset0 Courier; } {\colortbl;\red255\green255\blue255;\red255\green0\blue0;\red251\green2\blue7;\red0\green0\blue0; \red26\green26\blue26;\red0\green0\blue0;} {\*\expandedcolortbl;;\csgenericrgb\c100000\c0\c0;\cssrgb\c100000\c14913\c0;\csgenericrgb\c0\c0\c0; \cssrgb\c13333\c13333\c13333;\cssrgb\c0\c0\c0;} \margl1440\margr1440\vieww10800\viewh8400\viewkind0 \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \f0\fs24 \cf0 As required by RFC 4858, this is the current template … {\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf600 {\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fnil\fcharset204 PTSerif-Regular;\f2\fmodern\fcharset0 Courier; } {\colortbl;\red255\green255\blue255;\red255\green0\blue0;\red251\green2\blue7;\red0\green0\blue0; \red26\green26\blue26;\red0\green0\blue0;} {\*\expandedcolortbl;;\csgenericrgb\c100000\c0\c0;\cssrgb\c100000\c14913\c0;\csgenericrgb\c0\c0\c0; \cssrgb\c13333\c13333\c13333;\cssrgb\c0\c0\c0;} \margl1440\margr1440\vieww10800\viewh8400\viewkind0 \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \f0\fs24 \cf0 As required by RFC 4858, this is the current template for the Document \ Shepherd Write-Up.\ \ Changes are expected over time. This version is dated 24 February 2012.\ \ (1) What type of RFC is being requested (BCP, Proposed Standard,\ Internet Standard, Informational, Experimental, or Historic)? Why\ is this the proper type of RFC? Is this type of RFC indicated in the\ title page header?\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 The document requests publication as Best Current Practice. This is indicated in the header.\ \ BCP is appropriate. The document compares the effectiveness of various current techniques of reverse path filtering and presents an additional, enhanced technique. The current techniques are expressed in RFC2827 and RFC3704, both themselves BCP. The presented technique is an enhancement of a technique specified in RFC3704. The document updates RFC3704.\cf0 \ \ (2) The IESG approval announcement includes a Document Announcement\ Write-Up. Please provide such a Document Announcement Write-Up. Recent\ examples can be found in the "Action" announcements for approved\ documents. The approval announcement contains the following sections:\ \ Technical Summary\ \ \pard\pardeftab720\partightenfactor0 \cf2 \expnd0\expndtw0\kerning0 This document identifies a need for improvement of the unicast\ Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection\ and mitigation of source address spoofing (see BCP 38). The strict\ uRPF technique is inflexible about directionality, the loose uRPF\ technique is oblivious to directionality, and the current\ feasible-path uRPF technique attempts to strike a balance between the\ two (see BCP 84). However, as shown in this draft, the existing\ feasible-path uRPF technique still has shortcomings. This document\ describes an enhanced feasible-path uRPF technique, which aims to be\ more flexible (in a meaningful way) about directionality than the\ feasible-path uRPF technique. It can potentially alleviate ISPs'\ concerns about the possibility of disrupting service for their\ customers, and encourage greater deployment of uRPF techniques..\cf0 \ \kerning1\expnd0\expndtw0 \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 Working Group Summary\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 The document was discussed in grow and in opsec, and adopted by opsec. Discussions\ in both working groups were incorporated into the document.\cf0 \ \ Document Quality\ \ \pard\pardeftab720\partightenfactor0 \cf0 Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? \ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 The shepherd sees no wg mail indicating that there are are current software implementations. However, the draft containS a section \'93Implementation Considerations\'94 that points to the similarity to current uRPF techniques that query a VRF table, so existing implementation methods could be leveraged for this new technique. One wg comment explicitly said that the document was clear enough to \'93\expnd0\expndtw0\kerning0 assist the operators to better implement the recommendations\'94. \cf3 \ \pard\pardeftab720\partightenfactor0 \cf2 \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 \kerning1\expnd0\expndtw0 No MIB Doctor, Media Type, or other expert review was required.\ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ Personnel\ \ Who is the Document Shepherd? Who is the Responsible Area\ Director?\ \ \cf3 Document Shepherd: Sandra Murphy\cf0 \ \ Responsible Area Director: {\field{\*\fldinst{HYPERLINK "mailto:warren@kumari.net"}}{\fldrslt \cf4 \expnd0\expndtw0\kerning0 Warren Kumari}}\cf4 \expnd0\expndtw0\kerning0 \f1\fs30 \cf5 \ \f0\fs24 \cf0 \kerning1\expnd0\expndtw0 \ \ (3) Briefly describe the review of this document that was performed by\ the Document Shepherd. If this version of the document is not ready\ for publication, please explain why the document is being forwarded to\ the IESG.\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 The document shepherd has reviewed the document, references, and \ the wg discussions and presentations. The draft was presented and \ discussed in the grow wg, and those interactions were also reviewed. \ The authors have incorporated shepherd comments into the latest version.\cf0 \ \ (4) Does the document Shepherd have any concerns about the depth or\ breadth of the reviews that have been performed?\ \ \cf2 No.\cf0 \ \ \ (5) Do portions of the document need review from a particular or from\ broader perspective, e.g., security, operational complexity, AAA, DNS,\ DHCP, XML, or internationalization? If so, describe the review that\ took place.\ \ \cf2 No, there are no document portions that need additional review.\cf0 \ \ (6) Describe any specific concerns or issues that the Document Shepherd\ has with this document that the Responsible Area Director and/or the\ IESG should be aware of? For example, perhaps he or she is uncomfortable\ with certain parts of the document, or has concerns whether there really\ is a need for it. In any event, if the WG has discussed those issues and\ has indicated that it still wishes to advance the document, detail those\ concerns here.\ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf3 \ The shepherd has no concerns or issues with the current version of the\ draft.\ \cf0 \ (7) Has each author confirmed that any and all appropriate IPR\ disclosures required for full conformance with the provisions of BCP 78\ and BCP 79 have already been filed. If not, explain why.\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 Yes. All authors of this document have confirmed on the wg list that they know of no IPR.\cf0 \ \ (8) Has an IPR disclosure been filed that references this document?\ If so, summarize any WG discussion and conclusion regarding the IPR\ disclosures.\ \ \cf2 The shepherd sees no IPR disclosure notice on the wg email list.\cf0 \ \ (9) How solid is the WG consensus behind this document? Does it \ represent the strong concurrence of a few individuals, with others\ being silent, or does the WG as a whole understand and agree with it? \ \ \cf2 The wg adoption discussion was energetic. That discussion appeared to have resolved most issues; the subsequent conversation was not as energetic. The document as an individual contribution was first discussed in the grow wg.\cf0 \ \cf2 \ This draft was presented as an individual submission at grow at IETF97, presented at opsec IETF 99, IETF100, IETF101, and as an opsec draft at IETF104\ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \cf3 In total, there were 15 different individuals between the two groups, which is adequately broad support for these groups.\ \cf0 \ (10) Has anyone threatened an appeal or otherwise indicated extreme \ discontent? If so, please summarise the areas of conflict in separate\ email messages to the Responsible Area Director. (It should be in a\ separate email because this questionnaire is publicly available.) \ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 The shepherd sees no threats of appeal in the wg discussions and no indications on the wg list of a discontented wg member.\cf0 \ \ (11) Identify any ID nits the Document Shepherd has found in this\ document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts\ Checklist). Boilerplate checks are not enough; this check needs to be\ thorough.\ \ \cf2 The nits tool reports:\ \pard\pardeftab720\partightenfactor0 \cf3 \expnd0\expndtw0\kerning0 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). \f2\fs26 \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \f0\fs24 \cf2 \kerning1\expnd0\expndtw0 \ One warning concerns the format of the Updates line in the document header. The other warnings are about strings in the text that the nits tool thinks are citations, but it appears the tool is just picking up on the use of \'93[\'93 in a notation.\cf0 \ \ (12) Describe how the document meets any required formal review\ criteria, such as the MIB Doctor, media type, and URI type reviews.\ \ \cf2 None required. There are no features of the draft that require formal review.\ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ (13) Have all references within this document been identified as\ either normative or informative?\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 Yes. All references are divided into normative and informative sections.\ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf0 \ \ (14) Are there normative references to documents that are not ready for\ advancement or are otherwise in an unclear state? If such normative\ references exist, what is the plan for their completion?\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 No. All IETF documents in the references are RFCs.\cf0 \ \ (15) Are there downward normative references references (see RFC 3967)?\ If so, list these downward references to support the Area Director in \ the Last Call procedure. \ \ \cf2 No.\cf0 \ \ (16) Will publication of this document change the status of any\ existing RFCs? Are those RFCs listed on the title page header, listed\ in the abstract, and discussed in the introduction? If the RFCs are not\ listed in the Abstract and Introduction, explain why, and point to the\ part of the document where the relationship of this document to the\ other RFCs is discussed. If this information is not in the document,\ explain why the WG considers it unnecessary.\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf3 The document header notes that the document will update RFC3704.\cf0 \ \ (17) Describe the Document Shepherd's review of the IANA considerations\ section, especially with regard to its consistency with the body of the\ document. Confirm that all protocol extensions that the document makes\ are associated with the appropriate reservations in IANA registries.\ Confirm that any referenced IANA registries have been clearly\ identified. Confirm that newly created IANA registries include a\ detailed specification of the initial contents for the registry, that\ allocations procedures for future registrations are defined, and a\ reasonable name for the new registry has been suggested (see RFC 5226).\ \ \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\pardirnatural\partightenfactor0 \cf2 None required. There are no protocol extensions, no reference to IANA registries, no creation of new IANA registries in this document.\cf0 \ \ (18) List any new IANA registries that require Expert Review for future\ allocations. Provide any public guidance that the IESG would find\ useful in selecting the IANA Experts for these new registries.\ \ \cf2 None required. There are no new IANA registries created by this document.\cf0 \ \ (19) Describe reviews and automated checks performed by the Document\ Shepherd to validate sections of the document written in a formal\ language, such as XML code, BNF rules, MIB definitions, etc.\ \ \cf2 None required. There are no sections of the document that are XML code, BNF rules, MIM definitions, or any other formal language.\cf0 \ } |
2019-07-08
|
03 | Kotikalapudi Sriram | New version available: draft-ietf-opsec-urpf-improvements-03.txt |
2019-07-08
|
03 | (System) | New version approved |
2019-07-08
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas |
2019-07-08
|
03 | Kotikalapudi Sriram | Uploaded new revision |
2019-04-23
|
02 | Ron Bonica | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-04-08
|
02 | Ron Bonica | Notification list changed to Sandra Murphy <sandy@tislabs.com> |
2019-04-08
|
02 | Ron Bonica | Document shepherd changed to Sandra L. Murphy |
2019-04-08
|
02 | Ron Bonica | IETF WG state changed to In WG Last Call from WG Document |
2019-04-08
|
02 | Ron Bonica | Changed consensus to Yes from Unknown |
2019-04-08
|
02 | Ron Bonica | Intended Status changed to Best Current Practice from None |
2019-04-04
|
02 | Kotikalapudi Sriram | New version available: draft-ietf-opsec-urpf-improvements-02.txt |
2019-04-04
|
02 | (System) | New version approved |
2019-04-04
|
02 | (System) | Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas |
2019-04-04
|
02 | Kotikalapudi Sriram | Uploaded new revision |
2018-10-21
|
01 | Kotikalapudi Sriram | New version available: draft-ietf-opsec-urpf-improvements-01.txt |
2018-10-21
|
01 | (System) | New version approved |
2018-10-21
|
01 | (System) | Request for posting confirmation emailed to previous authors: Kotikalapudi Sriram , Doug Montgomery , Jeffrey Haas |
2018-10-21
|
01 | Kotikalapudi Sriram | Uploaded new revision |
2018-04-20
|
00 | Ron Bonica | This document now replaces draft-sriram-opsec-urpf-improvements instead of None |
2018-04-20
|
00 | Kotikalapudi Sriram | New version available: draft-ietf-opsec-urpf-improvements-00.txt |
2018-04-20
|
00 | (System) | WG -00 approved |
2018-04-20
|
00 | Kotikalapudi Sriram | Set submitter to "Kotikalapudi Sriram ", replaces to (none) and sent approval email to group chairs: opsec-chairs@ietf.org |
2018-04-20
|
00 | Kotikalapudi Sriram | Uploaded new revision |