Re: BCP 38 addendum

I have a router that takes a long time to converge after reboot. To fix that I do not want to advertise my prefixes until the router is fully ready. But I still want to establish the BGP sessions otherwise the router will never be ready. So we program in a delay until advertising after BGP session

Re: BCP 38 addendum

Le 2018-03-07 16:19, Saku Ytti a écrit : Hey, How would this work? ISP1--ISP2---ISP3 || +---ISP4-+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out

Re: BCP 38 addendum

Hey, > This is exactly my idea : why should I allowed uRPF passing traffic from > routes not learned on this port ?? Why if I have Cogent + Level3 and I > denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get > spoofed traffic from Level3 ranges over Cogent peering port ?

Re: BCP 38 addendum

Hey, How would this work? ISP1--ISP2---ISP3 || +---ISP4-+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4 ISP1 will receive traffic from ISP3

Re: BCP 38 addendum

Le 2018-03-06 19:39, Barry Greene a écrit : >> On Mar 2, 2018, at 1:53 PM, Fabien VINCENT (NaNOG) >> wrote: >> Hope one day the 3rd mode of uRPF will be something else than a plan ... >> uRPF is not very usefull when multi homed. And as far as I know, multi >> homed

Re: BCP 38 addendum

Le 2018-03-02 22:07, Barry Raveendran Greene a écrit : > Hi Todd, > > What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. > Russ White and I worked on it while at Cisco. > > Given that you are setting up prefix filters with your peers, you can add to > the peering

Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

Hi Todd, What you are describing is uRPF VRF mode. This was phase 3 of the uRPF work. Russ White and I worked on it while at Cisco. Given that you are setting up prefix filters with your peers, you can add to the peering agreement that you will only accept packets whose source addresses

Re: BCP 38 addendum

On 3/1/18 10:57 AM, Todd Crane wrote: > Question: > Since we cannot count on everyone to follow BCP 38 or investigate their > abuse@, I was thinking about the feasibility of using filtering to prevent > spoofing from peers’ networks. > > With the exception of a few edge cases, would it be

Re: BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

- Original Message - From: "Todd Crane" <t...@toddcrane.com> To: "NANOG list" <nanog@nanog.org> Cc: "Job Snijders" <j...@ntt.net> Sent: Thursday, March 1, 2018 12:57:53 PM Subject: BCP 38 addendum (was: New Active Exploit: me

BCP 38 addendum (was: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

Question: Since we cannot count on everyone to follow BCP 38 or investigate their abuse@, I was thinking about the feasibility of using filtering to prevent spoofing from peers’ networks. With the exception of a few edge cases, would it be possible to filter inbound traffic allowing only