Winstar says there is no TCP/BGP vulnerability
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)
Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is important on their BGP sessions either. Based on the ticket we filed last week, Managment does not feel its warranted to make these changes. On the other hand, SPRINT was willing and able to take MD5 session info right away. WAY TO GO SPRINT. On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
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)
On Tue, Apr 20, 2004 at 03:30:30PM -0600, John Brown (CV) wrote:
Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is important on their BGP sessions either.
Based on the ticket we filed last week, Managment does not feel its warranted to make these changes.
On the other hand, SPRINT was willing and able to take MD5 session info right away. WAY TO GO SPRINT.
While somehow I doubt that the likes of E.Spire and Winstar are doing it because they know it is the correct thing to do, in actual fact they are right. All the whining about how we all should have deployed MD5 years ago proves one very important point, it hasn't been deployed widely because it is a ROYAL PAIN IN THE !@#$%^&*. I haven't actually run the tests myself, but people who have are telling me that the implementations of TCP-MD5 on the major vendors do not take steps to check the sequence numbers (in the case of a rst) or wait for a syn|ack in the syn cookie/cache/whatever implementation (in the case of a syn) before doing the cpu burning MD5 hash. So congratulations, we all just made our routers trivially easy to bring down with even a minor SYN/RST flood and an MD5 key included in the packet, even an invalid one. Knee jerk security reactions don't always work out in your favor. :) BTW if someone wanted to actually implement this in a way which made sense, besides taking the opportunity to implement the checks I mentioned above before doing MD5 processing... I think the best way to go here is a public key authentication mechanism. Peers could post their public key on their peering websites or easily exchange the information in clear text offline, the other side could then install it on their devices when they turn up the peers, and it would then be used to automatically exchange MD5 keying information. Obviously you don't want this happening every time, but it would be easy enough to cache this data after an initial key exchange and authentication check, and only fall back to the public key exchange following a reboot (if you dont store keys in something other than ram) or following an MD5 key mismatch for whatever reason. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Hmm... Well as Randy pointed out... I did not have the correct tools when I configured this on all of Sprintlink in 1996, and I completed it in one nights maintenance window. All it takes is normal planning. It is not a pain in the ass... all of the problems you may have faced were corrected my Mr. Heffernan at Cisco when I ran into them first in 1996. I would say the rest is laziness.... or the belief it was unnecessary. jon
right. All the whining about how we all should have deployed MD5 years ago proves one very important point, it hasn't been deployed widely because it is a ROYAL PAIN IN THE !@#$%^&*. I haven't actually run the tests myself,
On Tue, 20 Apr 2004, John Brown (CV) wrote:
Seems Xspedius aka E.SPire aka ACSI doesn't feel that MD5 is important on their BGP sessions either.
Based on the ticket we filed last week, Managment does not feel its warranted to make these changes.
I dunno...to me, this falls on the side of "wait until I see my BGP sessions reset randomly before I get concerned". So I see where they're coming from. As far as I can tell, from the well reasoned responses from Richard and Patrick, it just won't get exploited quickly enough to cause a route to get dampened. And since no privileged access is gained, the chances of somebody actually bothering to write an effective exploit is minimal. As others have pointed out, you may as well just flood the router and kick it over that way, and they already have tools for that. I think MD5 violates the KISS principle for something as important as BGP. Not that it's difficult to implement on a small scale, just that it creates an additional knob for other people to break, and something else for the CPU to chew on (making it easier to take down, likely). Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 ---
I've left your entire message below so that one can see I've removed nothing. Winstar has made NONE of the statements you are interpreting from their response. They have simply stated that they don't support it at this moment in time. I'll grant you that they could have answered "when" or "why" or "what else". But they certainly didn't say anything you are suggesting that they have said. <joke>Should we ever meet, I'll remember to never turn down a beer. You might think I'm pro-prohibition or something...</joke> On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
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)
-- Joe Rhett Chief Geek JRhett@Isite.Net Isite Services, Inc.
Joe, Joe Rhett wrote:
I've left your entire message below so that one can see I've removed nothing. Winstar has made NONE of the statements you are interpreting from their response. They have simply stated that they don't support it at this moment in time. I'll grant you that they could have answered "when" or "why" or "what else". But they certainly didn't say anything you are suggesting that they have said.
The only network engineer who may NOT have been aware of the building BGP vulnerability issue over the last week has to be the engineer who is currently on his annual vacation in Mauritius, and who refuses to take his Blackberry, Palm, or Satellite phone with him. And given the frantic activity by every single major backbone to protect their connections by DEMANDING MD5 authentication, I think it is disingenuous to suggest that a network like Winstar is merely saying "They don't support it at this time" because they haven't gotten round to it. They have to also be saying: 1) We don't believe there is any threat. 2) We don't want to set up MD5 because it is against our religion 3) We don't know *how* to set it up. 4) Our machines can't support setting up MD5. 5) Our network cannot support the outage as we bounce the session. 6) Our customers cannot accept the outage as we bounce the session 7) We're just thinking about it, and our planning process is taking a long time. 8) We don't care about customer needs, even customers who spend $200k a year with us. 9) We don't care about customers and I am sure there are a slew of other possibilities. But for a network provider to respond to a request from a large customer who asks that their peering session be authenticated by just responding "We don't use MD5 for peering currently" shows un unusually ballsy attitude. There is more to it. Absent a specific, I chose to assume the first option. I'm happy to hear Winstar's alternative. I'm also interested in hearing if Winstar provided the same response to the other big backbones? MCI, Sprint, AT&T, Level3, Verio, etc. It seems to me that causing resets regularly forces the router to churn, dealing with inserting routes into FIB, deleting routes from FIB, recalculate FIB. Wash, rinse, repeat. Miscreants have no interest in a single reset. And it won't take 200 seconds after the first reset. You probably won't get out of the first window. I stand by my first comment - Winstar doesn't believe that this is enough of a threat to even craft a professional response.
<joke>Should we ever meet, I'll remember to never turn down a beer. You might think I'm pro-prohibition or something...</joke>
No. If you were standing in the way of a scheduled trainwreck, and I tossed you a schedule, a map, fed you live video of the approaching train, and tossed you a lifeline, and you said you didn't believe there was any danger I'd have to wonder.
On Tue, Apr 20, 2004 at 01:44:44PM -0700, Rodney Joffe wrote:
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)
-- Joe Rhett Chief Geek JRhett@Isite.Net Isite Services, Inc.
-- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)
On Tue, 20 Apr 2004, Rodney Joffe wrote:
The only network engineer who may NOT have been aware of the building BGP vulnerability issue over the last week has to be the engineer who is currently on his annual vacation in Mauritius, and who refuses to take his Blackberry, Palm, or Satellite phone with him.
Wouldnt anti-spoofing filters largely eliminate the need for all this panic about MD5? -Dan
Wouldnt anti-spoofing filters largely eliminate the need for all this panic about MD5?
egress filtering, yes... but not everyone does this and thats what poses the panic i guess :( ingress filtering... largely yes, but no? consider the scenario: someone runs traceroute to you (Joe ISP) doing bgp with your upstream (Blah Transit) 14. aggr10-fe-0-0-0.nyc.blah-transit.net (5.5.10.102) 15. joe-isp-gw.customer.blah-transit.net (5.5.254.130) assuming the usual setup, spoof the source ip to 5.5.254.129 and start fiddling with your router, or spoof to 5.5.254.130 and fiddle with your upstream aggr router. ingress filtering won't help in this situation. GTSM although... would... rather a very stupid workaround to think about: Haven't tested on other vendors, but at least in Cisco, you can half-way hide your single hop peering address showing up in traceroute by putting the assigned p2p address as secondary and spoofed/bogus ip as primary. However, users behind your network such as customers can still guess by looking at your upstream's aggr router showing up in outbound trace. i.e. interface Serial2/0 ip address 7.7.7.1 255.255.255.252 ip address 5.5.254.130 255.255.255.252 secon Anyhow the idea is that IOS replies icmp with interface's primary ip, not secondary. so traceroute would show 7.7.7.1 instead of 5.5.254.130. if i were you... i would only do that on ebgp interfaces, and not on any core/ internal interfaces..... I still think good way around is use different address other than what shows up in traceroute to maintain EBGP sessions. Not the best solution, but largely secure as long as you and your peer don't publicly provide such information. No need to worry about md5 implications or password management etc. If really concerned, supplement it with GTSM to make it bit stronger. For looking glass.. use a different loopback addr to peer up looking glass/ route server to your routers. use different set of non-publicly-known loopback addrs to maintain ibgp sessions.. Again, not The solution, but better than nothing compared with implications with md5 deployment. -J -- 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
DH> Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT) DH> From: Dan Hollis DH> Wouldnt anti-spoofing filters largely eliminate the need for DH> all this panic about MD5? But that doesn't push the short-term cost onto other networks. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
On Wed, 21 Apr 2004, E.B. Dreger wrote:
DH> Date: Wed, 21 Apr 2004 02:01:56 -0700 (PDT) DH> From: Dan Hollis
DH> Wouldnt anti-spoofing filters largely eliminate the need for DH> all this panic about MD5?
But that doesn't push the short-term cost onto other networks.
Not sure what you're saying. You don't need to deploy anti-spoofing filters everywhere. It needs to be done by those parties which are the ones setting up MD5 passwords. No more than that. (See my thread "Alternatives to MD5" for more.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
PS> Date: Wed, 21 Apr 2004 14:23:38 +0300 (EEST) PS> From: Pekka Savola PS> > But that doesn't push the short-term cost onto other networks. PS> PS> Not sure what you're saying. You don't need to deploy PS> anti-spoofing filters everywhere. It needs to be done by I was being sarcastic wrt networks not being good netizens. If networks egress-filtered spoofed traffic, it would be much more difficult for someone to send a spoofed SYN or RST. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
Joe Rhett wrote:
I've left your entire message below so that one can see I've removed nothing. Winstar has made NONE of the statements you are interpreting from their response. They have simply stated that they don't support it at this moment in time. I'll grant you that they could have answered "when" or "why" or "what else". But they certainly didn't say anything you are suggesting that they have said.
On Tue, Apr 20, 2004 at 10:01:52PM -0700, Rodney Joffe wrote:
And given the frantic activity by every single major backbone to protect their connections by DEMANDING MD5 authentication, I think it is disingenuous to suggest that a network like Winstar is merely saying "They don't support it at this time" because they haven't gotten round to it. They have to also be saying: (assumptions removed)
You do know how to spell assumption, right? They might have some very good reasons why they believe it isn't an issue, or that they have worked around. Why don't you ask, rather than spell? -- Joe Rhett Chief Geek JRhett@Isite.Net Isite Services, Inc.
Joe Rhett wrote:
You do know how to spell assumption, right?
They might have some very good reasons why they believe it isn't an issue, or that they have worked around. Why don't you ask, rather than spell?
We did. They repeated their answer: We don't do MD5 currently. So the customer is exercising his inalienable rights. And this loss of $200k+ in revenue helps Winstar how? BTW, I see you're right on top of the thread which I thought died some while ago. -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)
Date: Wed, 28 Apr 2004 10:22:56 -0700 From: Rodney Joffe <rjoffe@centergate.com> Sender: owner-nanog@merit.edu
Joe Rhett wrote:
You do know how to spell assumption, right?
They might have some very good reasons why they believe it isn't an issue, or that they have worked around. Why don't you ask, rather than spell?
We did. They repeated their answer: We don't do MD5 currently.
I recently discovered that one router vendor out there does not support MD5 authentication of BGP (even though it does for several other routing protocols). If you happen to be stuck with this product, you don't do MD5 authentication of BGP. No, I don't know who's product this is and I'd say that anyone using one for real work should replace it yesterday, but I also know the reality of fork-lift upgrades and corporate purchasing rules.
So the customer is exercising his inalienable rights.
And this loss of $200k+ in revenue helps Winstar how?
Education? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634
Kevin Oberman wrote:
And this loss of $200k+ in revenue helps Winstar how?
Education?
That was my point. Apparently not. A week or more ago, they knew that was the next stop. They ignored it. So they were not in need of education. Hence my original question - in the *real* world, was there another solution. In *this* specific situation where you were limited in forcing peers to do anything upstream. If there was an OT list, we should have been there already. So lets just kill it here ;-) -- Rodney Joffe CenterGate Research Group, LLC. http://www.centergate.com "Technology so advanced, even we don't understand it!"(R)
On Tue, 20 Apr 2004, Rodney Joffe wrote:
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.
1) Deploy correct ingress/egress filtering at all of your edges, and 2) Make sure your upstreams/peers do that as well at least for the p-t-p prefixes you use between you and them. If you can't assume 2), you need something like GTSM or MD5 for the BGP sessions between you and your peers/upstreams. Note that I assume that if customers don't do ingress/egress filtering for their p-t-p prefixes, they are shooting themselves in the foot, and are the only people suffering from the resets. Similar techniques as mentioned in the previous paragraph could be applied as well, of course. That is, a thing most people seem to be forgetting that for these TCP packets to be processed, they must be spoofed to come from a certain source IP address. If packets spoofed from that address are summarily discarded at appropriate places before reaching the infrastructure, you're pretty much safe. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
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)
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
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)
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
Is there any way to move BGP completely out-of-band? I know multihop may be out of the question but maybe someone should write up a proposal for PTP links. :-) -Dan
At 05:56 PM 4/22/2004, Dan Hollis wrote:
Is there any way to move BGP completely out-of-band?
I know multihop may be out of the question but maybe someone should write up a proposal for PTP links. :-)
BGP over PPP? Could be specified, but that'd require replacing the use of TCP. Might be a bit ugly to implement, especially on larger routers with separate control planes.
On Thu, 22 Apr 2004, Daniel Senie wrote:
At 05:56 PM 4/22/2004, Dan Hollis wrote:
Is there any way to move BGP completely out-of-band?
I know multihop may be out of the question but maybe someone should write up a proposal for PTP links. :-)
BGP over PPP? Could be specified, but that'd require replacing the use of TCP. Might be a bit ugly to implement, especially on larger routers with separate control planes.
wasn't there a PPP over SMTP spec? that sounds like a plan for this!
On Apr 22, 2004, at 10:18 PM, Christopher L. Morrow wrote:
BGP over PPP? Could be specified, but that'd require replacing the use of TCP. Might be a bit ugly to implement, especially on larger routers with separate control planes.
wasn't there a PPP over SMTP spec? that sounds like a plan for this!
I swear to ghod I was thinking of the telnet over SMTP spec when I read this, and wondering if we should use that and have the routers telnet to port 179 over SMTP. Then you could PGP sign the messages! Of course, you'd have to update your spam filters.... :) -- TTFN, patrick
participants (16)
-
Alexei Roudnev -
Andy Dills -
babylon＠egenius.org -
Christopher L. Morrow -
Dan Hollis -
Daniel Senie -
Deepak Jain -
E.B. Dreger -
James -
Joe Rhett -
John Brown (CV) -
Kevin Oberman -
Patrick W.Gilmore -
Pekka Savola -
Richard A Steenbergen -
Rodney Joffe