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

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Tue, 1 Nov 2016 00:18:19 +0000

This work has been submitted to OPSEC WG.
Posting here also since it may be of interest to GROW WG members as well.
Comments/suggestions on this draft are welcome -- here or on the OPSEC list.
Thank you.

Sriram

________________________________________
From: Sriram, Kotikalapudi (Fed)
Sent: Monday, October 31, 2016 7:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

We (the authors) would like to request comments/suggestions on this draft.
We would like to request the chairs for time on  the agenda
for presenting this work in the Opsec WG meeting in Seoul.
Thank you.

Sriram
________________________________________
From: [email-masked] <[email-masked]>
Sent: Monday, October 31, 2016 7:32 PM
To: Montgomery, Douglas (Fed); Sriram, Kotikalapudi (Fed)
Subject: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt

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

Name:           draft-sriram-opsec-urpf-improvements
Revision:       00
Title:          Enhanced Feasible-Path Unicast Reverse Path Filtering
Document date:  2016-10-31
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-sriram-opsec-urpf-improvements-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sriram-opsec-urpf-improvements/
Htmlized:       https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-00

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