Subject: Re: [GROW] New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 6 Mar 2018 17:14:19 +0000

[Posting on OPSEC and GROW lists. There has been interest in this work in GROW also.]

We (the authors) have gone through the draft carefully once again 
and made significant edits/rewrites  to carefully address the comments 
we received in the OPSEC meeting in Prague last summer and to make the draft read better.

https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03 
Diff: https://tools.ietf.org/rfcdiff?url2=draft-sriram-opsec-urpf-improvements-03.txt

Now the document specifies the two algorithms clearly: 
(1) for the not so challenging customer cone scenario (Algorithm A in Section 3.1.1); and
(2) for the challenging customer cone scenario (Algorithm B in Section 3.4).
Also, Section 3.6 (Summary of Recommendations) is new.

We've requested the chairs for a slot in OPSEC meeting in London to give an update.
We look forward to additional comments/discussion on the list anytime,
and also in person in London. 

Thanks.
Sriram
________________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, March 5, 2018 6:19 PM
To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Jeffrey Haas
Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-03.txt

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

Name:           draft-sriram-opsec-urpf-improvements
Revision:       03
Title:          Enhanced Feasible-Path Unicast Reverse Path Filtering
Document date:  2018-03-05
Group:          Individual Submission
Pages:          15

https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-03 

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 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.