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

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.


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 
We look forward to additional comments/discussion on the list anytime,
and also in person in London. 

From: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: Monday, March 5, 2018 6:19 PM
To: Sriram, Kotikalapudi (Fed); Montgomery, Douglas (Fed); Jeffrey Haas
Subject: New Version Notification for 

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


   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.

GROW mailing list

Reply via email to