Subject: [OPSEC] FW: New Version Notification for draft-sriram-opsec-urpf-improvements-01.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 16 May 2017 20:54:32 +0000

This version incorporates changes based on comments received
at the IETF-97 GROW WG meeting and 
also on the GROW and OPSEC lists back in November 2016.
Please see the next couple of posts from me for the details of the changes made.

Sriram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 03, 2017 7:37 PM
To: Sriram, Kotikalapudi (Fed) <[email-masked]>; Montgomery, Douglas (Fed) <[email-masked]>
Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-01.txt

A new version of I-D, draft-sriram-opsec-urpf-improvements-01.txt
has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository.

Name:		draft-sriram-opsec-urpf-improvements
Revision:	01
Title:		Enhanced Feasible-Path Unicast Reverse Path Filtering
Document date:	2017-05-03
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-sriram-opsec-urpf-improvements-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sriram-opsec-urpf-improvements/
Htmlized:       https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sriram-opsec-urpf-improvements-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sriram-opsec-urpf-improvements-01

Abstract:
   This document identifies a need for improvement of the unicast
   Reverse Path Filtering techniques (uRPF) [BCP84] for source address
   validation (SAV) [BCP38].  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 [BCP84].  However, as shown in this draft, the existing
   feasible-path uRPF still has short comings.  This document proposes
   an enhanced feasible-path uRPF technique, which aims to be more
   flexible (in a meaningful way) about directionality than the
   feasible-path uRPF.  It is expected to alleviate ISPs' concerns about
   the possibility of disrupting service for their customers, and
   encourage greater deployment of uRPF.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 16 May 2017 21:16:08 +0000

Job, Marco, Brian:

Thanks for your comments (back in November).
Version -01 of this draft is available at:
https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-01  

In response to your comments from when this was discussed (November 2016) 
in the GROW meeting at IETF-97 and on the GROW/OPSEC lists,

https://www.ietf.org/mail-archive/web/grow/current/msg03716.html    (Marco) 

https://www.ietf.org/mail-archive/web/grow/current/msg03713.html      (Job)

https://www.ietf.org/mail-archive/web/grow/current/msg03715.html       (Brian)

I have added a new Section 3.2 “Operational Recommendations”.
Your examples involved not announcing any routes at all to 
one or more upstreams (transit providers).
However, feasible-path uRPF relies “on consistent route advertisements
   (i.e., the same prefix(es), through all the paths) propagating to all
   the routers performing Feasible RPF checking.” (BCP 84)
The proposed enhanced feasible-path uRPF requires less and still performs better
relative to feasible-path uRPF given the same scenario.
The corresponding guidelines are presented and discussed in the new Section 3.2. 
I have also included a version of your example in the discussion.

Thanks! Further comments welcome.

Sriram