Hi Deepak, Yes you are correct, but really... getting all your peers to do this new security policy gets into politics. the fact that you don't control your peer's security policy is the problem.. The issue here is that you have to make sure you protect your peer for traffic origined from your network, whether via filter or blackhole, and your peer has to do the same for traffic originating from theirs. What if someone at either end by mistake mess up the filter? It's a royal pain in the #@$%%. running bgp session over a /30 that's invisible from traceroute and obscured from public knowledge is a better idea, although it is security by obscurity, it is a better practice, and easier to manage than having both sides abide to a filtering / mutual protection policy. -J On Thu, Apr 22, 2004 at 04:34:34PM -0400, Deepak Jain wrote:
You can add a RPF-flavored filter like:
Make core-facing network interfaces drop or not route the /30 or /24 your peering interface is on. Many NAP fabrics IPs are blackholed at borders like they should be.
Or you could move your peers to 10.x.x.x addresses and NOT route them inside your network, or have them destined to your blackhole community..
Better still. Just have all of your border routers announce the specpfic address blocks you have peers or directly connected interfaces on with your blackhole community. The routers with directly connected interfaces shouldn't mind the exported route and the routers that receive it shouldn't be routing it anyway.
Deepak Jain AiNET
James wrote:
anti spoofing filtering won't help you with your ebgp peer if the packet is spoofed to your peer's address and hits the peering interface. try adding GTSM with anti-spoofing. makes it far harder..
-J
On Thu, Apr 22, 2004 at 12:14:55AM -0700, Alexei Roudnev wrote:
If they make proper anty-spoofiing filtering, no need in MD5.
Perhaps we are all making too much of this...
It appears that Winstar feels that there is no need for MD5 authentication of peering sessions. One of our customers has just had the following response from Winstar following a request to implement MD5 on their OC3 connection to Winstar. My first suggestion is to locate another upstream provider (they have 3 already).
However, perhaps someone from Winstar would care to help us all understand what the alternative solution is to securing the session via MD5? I would *love* an alternative to the 5 days of work we've just gone through.
-----Original Message----- From: Justin Crawford - NMCW Engineer [mailto:jcrawford@winstar.net] Sent: Tuesday, April 20, 2004 11:13 AM To: xxxxxx Subject: Re: *****SPAM***** MD5 implimentation on BGP
xxxxx,
Winstar does not currently run MD5 authentication with our peers.
Thanks
Justin
Thank you for your time and business
Justin Crawford Winstar NMCW Ph: 206-xxx.xxxx
Has anyone else run in to this with Winstar?
-- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(SM)
-- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net