Seems like you have the same question as Job: Please see my response to him: https://www.ietf.org/mail-archive/web/grow/current/msg03713.html
Sriram ________________________________________ From: Marco Marzetti <[email protected]> Sent: Tuesday, November 15, 2016 7:17 AM To: Sriram, Kotikalapudi (Fed) Cc: Montgomery, Douglas (Fed); Nick Hilliard; [email protected] Subject: Re: [GROW] Fw: New Version Notification for draft-sriram-opsec-urpf-improvements-00.txt Siriam, I misunderstood. My apologize. Now i get what you're suggesting. How do you handle scenarios in which one ASn have two upstreams and announces its prefixes to only one of them, but send packets through both? For instance what if AS1 sends announces its prefixes to AS2 only, but sends packets to AS3? +-----+ | AS3 +-------+ +--+--+ | | | +--+--+ +--+--+ | AS1 | | AS4 | +-----+ +--+--+ | | +--+--+ | | AS2 +-------+ +-----+ Regards On Tue, Nov 15, 2016 at 4:31 AM, Sriram, Kotikalapudi (Fed) <[email protected]> wrote: > Marco, > > My responses Marked with [Sriram] below: > > [Marco] But it also goes further and suggest to amend the usual behavior by > advertising via BGP the source addresses of the traffic you want to > drop so that the routers can null route and trigger uRPF. > This is where i see problems. > > [Sriram] This is not at all what our proposed enhanced feasible path uRPF > does. > To clarify, the proposal does not require/recommend making any BGP > advertisements. > A good description of the proposal was just mentioned in a response to Nick, > which is copied here: > The ISP's AS creates a union of all announced prefixes that have a common > origin AS. > Those announcements have potentially been received > on various customer/ peer/ provider interfaces. > Take that union of prefixes and include it in Reverse Path Filter (RPF) > tables > on all interfaces on which one or more of the prefixes in the union were > announced. > > [Sriram] We are adding prefixes in the RPF table (with some more additional > intelligence built-in as compared to the current feasible-path uRPF), > and source addresses belonging in these are prefixes are permitted (not null > routed). > > Sriram -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
