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

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

Jeff:

I am responding to your comments from November 2016 (copied below):

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

Thanks for your comments. I have tweaked your wording to
add a new Section 3.4 in the new version -01,
https://tools.ietf.org/html/draft-sriram-opsec-urpf-improvements-01  ,
which reads as follows:

3.4.  Implementation Consideration
   The existing RPF checks in edge routers take advantage of existing
   line card implementations to perform the RPF functions.  For
   implementation of the proposed technique, the general necessary
   feature would be to extend the line cards to take arbitrary RPF lists
   that are not necessarily tied to the existing FIB contents.  For
   example, in the proposed method, the RPF lists are constructed by
   applying a set of rules to all received BGP routes (not just those
   selected as best path and installed in FIB).

Thank you. Further comments welcome.

Sriram

Jeff Haas wrote Wed, 16 Nov 2016 00:17:39
>On Thu, Nov 10, 2016 at 04:19:14PM +0100, Gert Doering wrote:
>> On Wed, Nov 09, 2016 at 06:59:53PM +0000, Sriram, Kotikalapudi (Fed) wrote:
>> > The data plane would perform the usual uRPF check: Does the SA in the data packet 
>> > belong in a prefix in the RPF list for the interface it was received on?
>> 
>> This, actually, is not "the usual uRPF check".
>> 
>> Having implementations that could tack arbitrary "RPF lists" to an 
>> interface would be very nice, but this is more like "auto-generate ACLs
>> based on prefix info" than "RPF" which stands for "reverse path filter"
>> (not sure about the "filter" bit, though)
>
>This summarizes my hallway feedback to Sriram.
>
>As noted during mic chat, the existing RPF checks take advantage of existing
>line card implementations to do their thing.  The general necessary feature
>would be to extend the line cards to take arbitrary lists that may have
>nothing to do with the existing FIB contents.
>
>-- Jeff
>