[nsp-sec] Juniper uRPF to Blackhole

Barry Greene (bgreene) bgreene at cisco.com
Fri Mar 21 15:51:35 EDT 2008


 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Funny as it seems, but sRTBH (uRPF Loose Mode with BGP triggering the
black hole) did work on Junipers. 

Now, their FIB coders might have broken it. We had a big cable company
whack on Cisco to change Null0 so it would not be an invalid adjacency -
which means Null0 was never added to the FIB. This code got into XR, our
lab people caught it, and we kicked off a SMU to fix it ASAP.

So the came could has happened to Juniper. Customer pressure to change
something which resulted in collateral impact on another function.
 

> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net 
> [mailto:nsp-security-bounces at puck.nether.net] On Behalf Of 
> Smith, Donald
> Sent: Friday, March 21, 2008 10:34 AM
> To: sa at rh-tec.de; JR Mayberry
> Cc: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] Juniper uRPF to Blackhole
> 
> ----------- nsp-security Confidential --------
> 
> I haven't tried this but recall juniper telling us that a 
> blackhole route to discard would cause a "zero" response from 
> the fib check so even with FULL routes a more specific route 
> to discard and loose mode urpf should still allow you to 
> blackhole a cidr block including rfc1918 space.
>  
> Can someone from juniper confirm this?
> If this is correct in what version of JUNOS is this supported?
>  
>  
> donald.smith at qwest.com giac
> 
> ________________________________
> 
> From: nsp-security-bounces at puck.nether.net on behalf of Sebastian Abt
> Sent: Fri 3/21/2008 11:16 AM
> To: JR Mayberry
> Cc: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] Juniper uRPF to Blackhole
> 
> 
> 
> ----------- nsp-security Confidential --------
> 
> * JR Mayberry wrote:
> > Isn't anyone actually using the feature and can speak to whether it 
> > works like Cisco or not?
> 
> In uRPF loose-mode Juniper only checks whether an entry for 
> the given prefix exists in the RIB; if that's the case, the 
> packet is accepted - even if the next-hop for the prefix is 
> discard.  At least that's what I remember when I tried to 
> configure this some time ago..
> 
> So, yes, I guess your colleagues are right and this behaviour 
> differs from Cisco's - unfortunately.
> 
> 
> regards,
> sebastian
> 
> --
> fon: +49 69 95411 15  e-mail: sa at rh-tec.de
> fax: +49 69 95411 45  mobile: +49 69 95411 55 rh-tec Business 
> GmbH, http://www.rh-tec.de/ Grosser Heidkamp 8, 32549 Bad Oeynhausen
> Geschaeftsfuehrer: Gerhard Roehrmann
> Registergericht: AG Bad Oeynhausen, HRB 8112
> 
> 
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
> 
> Please do not Forward, CC, or BCC this E-mail outside of the 
> nsp-security community. Confidentiality is essential for 
> effective Internet security counter-measures.
> _______________________________________________
> 
> 
> 
> 
> This communication is the property of Qwest and may contain 
> confidential or privileged information. Unauthorized use of 
> this communication is strictly prohibited and may be 
> unlawful.  If you have received this communication in error, 
> please immediately notify the sender by reply e-mail and 
> destroy all copies of the communication and any attachments.
> 
> 
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
> 
> Please do not Forward, CC, or BCC this E-mail outside of the 
> nsp-security community. Confidentiality is essential for 
> effective Internet security counter-measures.
> _______________________________________________
> 
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBR+QRx7/UEA/xivvmEQIAGwCgkOlBvxa6M505NIgKAlPTDZgbxxUAnihM
xsigSeqgsuJLuwfz+6Vr6bpW
=l1P+
-----END PGP SIGNATURE-----



More information about the nsp-security mailing list