Siriam, I wasn't at the meeting, so pardon me if you've already discussed that there. So you are suggesting that every customers can send packets that other customer's IPs in the source field? Is that correct?
Anyway: Have you considered the additional burden on routers to handle that? And what about those network operators that use default at the edges? Regards On Tue, Nov 15, 2016 at 11:26 PM, Sriram, Kotikalapudi (Fed) <[email protected]> wrote: > 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 -- Marco _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
