Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
On Apr 22, 2004, at 6:36 PM, Lane Patterson wrote: Although someone mentioned using non-routable /30 or /31's on private eBGP peers, there hasn't been much broad-ranging discussion of keeping internal infrastructure addresses non-routable. I am thinking of a couple different things here: 1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.) If you use multi-hop peering with loopback0, why bother changing the traceroute replies? Alternatively, if you make all traceroute replies from loopback1, then why bother turning on multi-hop BGP? Hrmmm, would the GTSM work with loopback peering? ISTR it allowed a TTL of 254, which should make it to the loopback interface. 2. Public IX addresses: ISPs that do not redistribute the IX prefix into their iBGP or IGP and do not use external next-hops (except local to the connected border router), but instead use the loopback of the border router when propogating these routes within their iBGP mesh. This should not break traceroutes "through" the exchange, but will break any traffic such as ping, spoofed packets, etc. to the exchange from a non-connected router. Excellent idea. And one which is, I believe, being used by several people already. Perhaps more wide spread use would help? I like the second one more than the first since the first is more of a security-through-obscurity than anything else. But even obscurity is better security than nothing. OTOH, the best security measure right now would be to do something like OpenBSD's random ephemeral port algorithm into the router OSes. Then this "vulnerability" would be far, far less vulnerable. -- TTFN, patrick
Re: Winstar says there is no TCP/BGP vulnerability
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
Re: Backbone IP network Economics - peering and transit
On Apr 22, 2004, at 9:29 PM, Michel Py wrote: Deepak Jain wrote: But that structure doesn't vary vastly if you'd traffic out that gig via transit vs direct connect. It does vary (and add lots of infrastructure) if you don't aggregate your traffic at IXes and instead use loops to bring transit to you instead of going to it. (say a few 100Mb/s or OC3s in a few places instead of a GigE at an IX). Indeed. Perhaps we should (for technical reasons) describe peering as "direct connecting". This makes a lot of sense to me (although I would suggest a different name later). Since the beginning I have been trying to make the point that "direct connecting" was typically a no-brainer in terms of money. Peering when you have to buy the local loop is not such a slam dunk. Business reasons aside, technically the difference is that with transit you are expecting access via indirect connections to networks. I'm not so sure about this. There are lots of people that buy transit and are directly connected to their provider in an IX for example. With peering you expect direct connections into a network. If "direct connecting" != peering then definitely. Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering And agree that, by default, transit ~= remote transit peering ~= direct peering Michel. The kind of relative cost dynamics described in this thread leave a measurable geographic imprint on the Internet. Big network operators make deployment decisions explicitly to optimize capex/opex over a relatively short horizon, with proximate peering opportunities often justifying higher upfront costs. Conversely, there are plenty of places where lack of public IX facilities, and/or exploitive metro/regional infrastructure costs make remote interconnection not-economically-viable -- so very little peering or multihoming in general. Regions or countries fitting the latter description typically have very few autonomous networks, because there's really very little be gained from running your own network. Infrastructure (layer2, "basic telecom," etc.) was once highly regulated everywhere, and didn't/doesn't really become affordable anywhere unless/until someone in authority compels sharing or underwrites the development of competing infrastructures. I don't think it was just a coincidence that EGP was developed during the same period that Ma Bell was being broken up into regional and national "independent operating entities"... Voila: The origin and evolving structure of IDR is a product of layer 8/9. There's a time dimension to this dynamic as well, as infrastructure savings belatedly give rise to reduced transit costs; once and future operators jump into and out of the game at different points in the cycle. Anyone else notice how many "content providers" are now suddenly looking for peering coordinators? It's not because they expect other operators to come to their isolated data center(s)...they are building out, because that's what makes sense for them at this point in the cycle. Now I will go back to hunkering down until SF. Tom
Re: Winstar says there is no TCP/BGP vulnerability
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!
Re: Winstar says there is no TCP/BGP vulnerability
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.
RE: Backbone IP network Economics - peering and transit
> Deepak Jain wrote: > But that structure doesn't vary vastly if you'd traffic out > that gig via transit vs direct connect. It does vary (and > add lots of infrastructure) if you don't aggregate your > traffic at IXes and instead use loops to bring transit to > you instead of going to it. (say a few 100Mb/s or OC3s in > a few places instead of a GigE at an IX). Indeed. > Perhaps we should (for technical reasons) describe > peering as "direct connecting". This makes a lot of sense to me (although I would suggest a different name later). Since the beginning I have been trying to make the point that "direct connecting" was typically a no-brainer in terms of money. Peering when you have to buy the local loop is not such a slam dunk. > Business reasons aside, technically the difference is > that with transit you are expecting access via indirect > connections to networks. I'm not so sure about this. There are lots of people that buy transit and are directly connected to their provider in an IX for example. > With peering you expect direct connections into a network. If "direct connecting" != peering then definitely. Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering And agree that, by default, transit ~= remote transit peering ~= direct peering Michel.
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
> Couldn't we use 2 /30 subnets on PtP links? 1 /30 with real IPs for > ICMP, MTU, reachability etc. and one RFC1918 /30 as secondary for eBGP > sessions. I know when a router originates a packet (like with BGP) it > sets the source IP to the IP of the interface the packet leaves. Is > BGP smart enough when setting up BGP neighbors to use an IP in the same > subnet as the neighbor (the secondary interface IP)? in IOS bgp will bind source ip that is relevant to the subnet it is being peered with, even if it is a secondary ip. i am not sure if it binds the ip to primary ip for the first time, then fall back to secondary ip as primary fails though.. all i know is that when i've tried it by putting a bogus ip as primary, bgp session did turn up, but took a little longer than usual.. didn't investigate any further however. -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
> > no! these are so easy to find > > $ host 65.116.132.145 > 145.132.116.65.in-addr.arpa domain name pointer lo0.b1.box2.twdx.net. of course.. i wasn't saying i am one of those who are employing 'hide the loopbacks from public' practice :) heh but yea good point though, if you were to 'hide' them, reverse dns hostnames should be taken into consideration as well.. -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
On Thu, 22 Apr 2004, James wrote: > > 1. Backbone addresses: ISPs that hide interface addresses and/or primary > > loopback addresses, and best practices for doing so? (e.g. traceroutes don't > > break, but the router uses say Loopback1 address to respond to them, while iBGP > > uses Loopback0. All Loopback0 address blocks can be filtered at borders.) > > since ibgp's should be peered w/ loopbacks, loopback protection is all > needed as as far as this bgp hysteria goes. no! these are so easy to find $ host 65.116.132.145 145.132.116.65.in-addr.arpa domain name pointer lo0.b1.box2.twdx.net. > > so loopback0 with "secret" addresses for ibgp peering, use a loopback1 > to publish router ip addrs to public via looking glass, etc. > > next thing to protect is customer ebgp sessions. some providers don't even > route the p2p /30 links used between cust and their backbone (i.e. Sprint). > so that's up to you. > > some backbones even filter all traffic destined to backbone prefixes at > ingress points (border routers, cust edge routers)... for example.. att > being one. for example, here comes random test: > > starbucks blahdy $ traceroute -M 8 12.123.205.65 > traceroute to 12.123.205.65 (12.123.205.65), 64 hops max, 44 byte packets > 8 jfk-brdr-02.inet.qwest.net (205.171.230.21) 6.404 ms 6.138 ms 6.145 ms > 9 * qwest-gw.n54ny.ip.att.net (192.205.32.169) 6.465 ms !X * > > > all above options don't necessarily break traceroute as long as you implement > it with care... > > -J > > > > > 2. Public IX addresses: ISPs that do not redistribute the IX prefix into their > > iBGP or IGP and do not use external next-hops (except local to the connected > > border router), but instead use the loopback of the border router when propogating > > these routes within their iBGP mesh. This should not break traceroutes "through" > > the exchange, but will break any traffic such as ping, spoofed packets, etc. to > > the exchange from a non-connected router. > > > > Can anyone provide pro/con, better description of config templates for doing this, > > and/or discussion of major networks that choose to do this, or not do this? > > > > Cheers, > > -Lane > >
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
next thing to protect is customer ebgp sessions. some providers don't even route the p2p /30 links used between cust and their backbone (i.e. Sprint). so that's up to you. some backbones even filter all traffic destined to backbone prefixes at ingress points (border routers, cust edge routers)... for example.. att being one. for example, here comes random test: Couldn't we use 2 /30 subnets on PtP links? 1 /30 with real IPs for ICMP, MTU, reachability etc. and one RFC1918 /30 as secondary for eBGP sessions. I know when a router originates a packet (like with BGP) it sets the source IP to the IP of the interface the packet leaves. Is BGP smart enough when setting up BGP neighbors to use an IP in the same subnet as the neighbor (the secondary interface IP)?
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
> 1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback > addresses, and best practices for doing so? (e.g. traceroutes don't break, but the > router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. > All Loopback0 address blocks can be filtered at borders.) since ibgp's should be peered w/ loopbacks, loopback protection is all needed as as far as this bgp hysteria goes. so loopback0 with "secret" addresses for ibgp peering, use a loopback1 to publish router ip addrs to public via looking glass, etc. next thing to protect is customer ebgp sessions. some providers don't even route the p2p /30 links used between cust and their backbone (i.e. Sprint). so that's up to you. some backbones even filter all traffic destined to backbone prefixes at ingress points (border routers, cust edge routers)... for example.. att being one. for example, here comes random test: starbucks blahdy $ traceroute -M 8 12.123.205.65 traceroute to 12.123.205.65 (12.123.205.65), 64 hops max, 44 byte packets 8 jfk-brdr-02.inet.qwest.net (205.171.230.21) 6.404 ms 6.138 ms 6.145 ms 9 * qwest-gw.n54ny.ip.att.net (192.205.32.169) 6.465 ms !X * all above options don't necessarily break traceroute as long as you implement it with care... -J > > 2. Public IX addresses: ISPs that do not redistribute the IX prefix into their > iBGP or IGP and do not use external next-hops (except local to the connected border > router), but instead use the loopback of the border router when propogating these > routes within their iBGP mesh. This should not break traceroutes "through" the > exchange, but will break any traffic such as ping, spoofed packets, etc. to the > exchange from a non-connected router. > > Can anyone provide pro/con, better description of config templates for doing this, > and/or discussion of major networks that choose to do this, or not do this? > > Cheers, > -Lane -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)
Although someone mentioned using non-routable /30 or /31's on private eBGP peers, there hasn't been much broad-ranging discussion of keeping internal infrastructure addresses non-routable. I am thinking of a couple different things here: 1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.) 2. Public IX addresses: ISPs that do not redistribute the IX prefix into their iBGP or IGP and do not use external next-hops (except local to the connected border router), but instead use the loopback of the border router when propogating these routes within their iBGP mesh. This should not break traceroutes "through" the exchange, but will break any traffic such as ping, spoofed packets, etc. to the exchange from a non-connected router. Can anyone provide pro/con, better description of config templates for doing this, and/or discussion of major networks that choose to do this, or not do this? Cheers, -Lane
Re: Winstar says there is no TCP/BGP vulnerability
RT> Date: Tue, 20 Apr 2004 23:11:28 -0500 (CDT) RT> From: Rob Thomas RT> We manage well over 150 peering sessions with MD5 passwords RT> in place. This includes bogon peering, route-server peering, CYMRU bogon (et al.) route servers are an example of where MD5 or IPSec definitely is a good idea. However, most peer/peer and carrier/downstream BGP sessions aren't multihop spanning a network or three. Of course, if ingress SAV were universal... 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 : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Winstar says there is no TCP/BGP vulnerability
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
Re: IP economics morphed into (TCP/RST)
IvB> Date: Thu, 22 Apr 2004 18:03:33 +0200 IvB> From: Iljitsch van Beijnum IvB> Who says BGP sessions must run over IP(v4)? NetBEUI, anyone? No bickering over RFC1918 on WAN links... ;-) 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 : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: TCP/BGP vulnerability - easier than you think
EBD> Date: Wed, 21 Apr 2004 10:56:26 + (GMT) EBD> From: E.B. Dreger EBD> This is more appropriate for cisco-nsp, where it's already EBD> been covered, but the TTL 255 hack was introduced in EBD> 12.0(22)S and 12.3(7)T if memory serves me. Pretty sparse Memory did not serve me. s/12.0(22)S/12.0(27)S/ http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008020e6f5.html 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 : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: Winstar says there is no TCP/BGP vulnerability
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] > Sent: Tuesday, April 20, 2004 11:13 AM > To: xx > Subject: Re: *SPAM* MD5 implimentation on BGP > > x, > > 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. > >>> > >>>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 JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: Winstar says there is no TCP/BGP vulnerability
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:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 11:13 AM To: xx Subject: Re: *SPAM* MD5 implimentation on BGP x, 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. 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)
Re: Winstar says there is no TCP/BGP vulnerability
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:[EMAIL PROTECTED] > > > Sent: Tuesday, April 20, 2004 11:13 AM > > > To: xx > > > Subject: Re: *SPAM* MD5 implimentation on BGP > > > > > > x, > > > > > > 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. > > > > 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 JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
Re: Backbone IP network Economics - peering and transit
[EMAIL PROTECTED] wrote: where's the "lot of cost"? Stephen J. Wilcox This is private vs public.. Even if it's private, and assuming that you're clever enough not to peer for a modem's worth of traffic, the cost is a no-brainer, IMHO. Someone checks my math please: At $20 per megabit for transit (which I find very low, but let's go for it anyway) a GE link for peering with an average use of 10% means $24000 per year saved; pays for the xconnect. If you have a gig of traffic to peer out to a single AS, you need quite a bit of infrastructure to support the peering and that infrastructure does not come cheap. But that structure doesn't vary vastly if you'd traffic out that gig via transit vs direct connect. It does vary (and add lots of infrastructure) if you don't aggregate your traffic at IXes and instead use loops to bring transit to you instead of going to it. (say a few 100Mb/s or OC3s in a few places instead of a GigE at an IX). Perhaps we should (for technical reasons) describe peering as "direct connecting". Business reasons aside, technically the difference is that with transit you are expecting access via indirect connections to networks. With peering you expect direct connections into a network. Deepak Jain AiNET
Re: Backbone IP network Economics - peering and transit
> >> where's the "lot of cost"? > > > Stephen J. Wilcox > > This is private vs public.. > > Even if it's private, and assuming that you're clever enough not to peer > for a modem's worth of traffic, the cost is a no-brainer, IMHO. > Someone checks my math please: > At $20 per megabit for transit (which I find very low, but let's go for > it anyway) a GE link for peering with an average use of 10% means $24000 > per year saved; pays for the xconnect. If you have a gig of traffic to peer out to a single AS, you need quite a bit of infrastructure to support the peering and that infrastructure does not come cheap. Alex
Re: TCP/BGP vulnerability - easier than you think
On 21-apr-04, at 22:00, Paul Jakma wrote: Why would MD5 be more of a crypto DoS risk with IPSec AH headers than with bgp tcp-md5? Beats me. But why do you bring up IPsec? The paragraph is quoted is your advice against using IPSec, Unless I was really sleep-typing I didn't say anything about IPsec, just about "crypto", which as far as I'm concerned includes MD5, which we were talking about. I dont see why an MD5 auth header IPSec protected sessions would have more risk of crypto DoS than compared to the simple BGP TCP MD5 hack. The risk is due to MD5, not IPSec :). As Crist Clark just pointed out: the presence of the SPI and replay counter actually makes it harder to do a crypto DoS against IPsec than the TCP MD5 option (assuming the traffic can't be sniffed). Makes you wonder if those TDM guys weren't on to something with out of band signalling, doesn't it? Anyway, what needs to happen is a form of crypto where the expensive algorithms are only executed for good packets and not for all packets. So configure ipsec to authenticate packets between the peers allowing only md5 or somesuch. I dont know about other IOS, but other implementations do allow one to specify security associations on a per port basis. Another advantage of IPsec is that it allows for key changes in a sane way. I'm not sure I'd want my routers to run IKE, though. However, note that even a relatively light-weight check such as an HMAC-MD5 can blow away a typical router CPU at orders of magnitude below line rate, so it is essential that attackers don't get to bypass the non-crypto checks for than a tiny fraction of the packets they spoof.
Re: TCP/BGP vulnerability - easier than you think
David Luyer wrote: [snip] With ipsec, you have crypto overhead before you have any opportunity to do the basic sanity check. Minor point, but with IPsec, the 32-bit SPI and the 32-bit replay counter are very low cost ways to drop the majority of traffic from a flood of random junk with no crypto calculations. You actually have more bits with AH or ESP than with TCP. The 32-bit SPI must be an exact match like the two 16-bit port fields, and you have 32-bits of sequence number in both, but the TCP window is much larger than the IPsec window (usually 6-bit by default) leaving you more bits to check. -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
Re: IP economics morphed into (TCP/RST)
On 22-apr-04, at 16:11, Stephen J. Wilcox wrote: There are more protection methods available than just MD5 (as you allude to Steve). One mitigator is to use "non-routed" space for BGP peer connections. Hmm ok so assume for a moment that I dont want RFC1918 for my links, what are my options? : There isnt a "link-local" for IP altho this would be a great solution (surely this can be written for BGP??). Who says BGP sessions must run over IP(v4)? In theory it shouldn't be a problem to exchange IPv4 routing information over IPv6 BGP TCP sessions. (But it seems some of our favorite vendors didn't add this scenario to their regression tests.) Or I could use all eBGP addresses from a block which I dont route and filter internally.. I suspect this is a non-starter, I will have to include all my addresses given to me by peers and its gonna screw traces, monitoring etc. Can I use secondary IP addresses and then BGP with these addresses, this would be a form of "security by obscurity" but providing you can keep the info a secret thats surely going to do it? If you combine the two approaches above and filter all traffic to the primary address, traceroutes et al still work but people from the outside don't get to hit the route processor.
RE: IP economics morphed into (TCP/RST)
On Thu, 22 Apr 2004, Blaine Christian wrote: > > > > Can I use secondary IP addresses and then BGP with these addresses, this > > would be a form of "security by obscurity" but providing you can keep the > > info a secret thats surely going to do it? > > It will depend on your architecture in large part. In some cases there is > absolutely no need to route the prefixes that you use for your BGP sessions > beyond the devices doing BGP. This can reduce your exposure to MD5 related > cpu churn etc... Yes, but (1) its difficult and (2) as these are external sessions I need to ensure my peers are doing the same, as the chances are they wont and the chances are the attack comes in externally then I'm still at risk Steve
Re: IP economics morphed into (TCP/RST)
On Thu, 22 Apr 2004, Niels Bakker wrote: > * [EMAIL PROTECTED] (Stephen J. Wilcox) [Thu 22 Apr 2004, 16:11 CEST]: > > There isnt a "link-local" for IP altho this would be a great solution > > (surely this can be written for BGP??). > > 169.254/16 is not link-local and will be routed if you try. i was thinking link-local as in ISIS style > > Or I could use all eBGP addresses from a block which I dont route and filter > > internally.. I suspect this is a non-starter, I will have to include all my > > addresses given to me by peers and its gonna screw traces, monitoring etc. > > I've seen e.g. BT do this and public peering? or when viewed from their peers networks..? Steve > > > -- Niels. >
RE: IP economics morphed into (TCP/RST)
> Can I use secondary IP addresses and then BGP with these > addresses, this would > be a form of "security by obscurity" but providing you can > keep the info a > secret thats surely going to do it? It will depend on your architecture in large part. In some cases there is absolutely no need to route the prefixes that you use for your BGP sessions beyond the devices doing BGP. This can reduce your exposure to MD5 related cpu churn etc...
RE: Backbone IP network Economics - peering and transit
>> where's the "lot of cost"? > Stephen J. Wilcox > This is private vs public.. Even if it's private, and assuming that you're clever enough not to peer for a modem's worth of traffic, the cost is a no-brainer, IMHO. Someone checks my math please: At $20 per megabit for transit (which I find very low, but let's go for it anyway) a GE link for peering with an average use of 10% means $24000 per year saved; pays for the xconnect. Michel.
Re: IP economics morphed into (TCP/RST)
* [EMAIL PROTECTED] (Stephen J. Wilcox) [Thu 22 Apr 2004, 16:11 CEST]: > There isnt a "link-local" for IP altho this would be a great solution > (surely this can be written for BGP??). 169.254/16 > Or I could use all eBGP addresses from a block which I dont route and > filter internally.. I suspect this is a non-starter, I will have to > include all my addresses given to me by peers and its gonna screw > traces, monitoring etc. I've seen e.g. BT do this -- Niels.
RE: asymmetric/peer RPF [RE: TCP/BGP vulnerability - easier than you think]
From: Pekka Savola [mailto:[EMAIL PROTECTED] > When discussing RPF towards peers or w/ asymmetric > paths, I'd recommend to read RFC 3704 I have, this is a very good document. > If your prefix filter stops a neighbor from > advertising a prefix, maybe you would have to > revise your prefix filtering policy (e.g., > revise it more often, get notice if the peer > sends you something you're filtering, tell to > peers not to advertise anythnig that's not > properly in the routing DB's, etc.)? This > doesn't seem so bad to me... I agree, but there are many people that think it is very bad. Trouble is, using RPF has a great potential for problems as it will drop traffic (which is the reason it's not being used in the first place). The point I was trying to make is as follows: if you don't use RPF (which is probably the case) then there is no harm in prefix-filtering peers (if you are not a tier-1) even if the prefix-filters are not perfect. Needless to say, there is no point prefix-filtering if your filters are completely messed up. Michel.
RE: Backbone IP network Economics - peering and transit
On Tue, 20 Apr 2004, Michel Py wrote: > > Stephen J. Wilcox wrote: > > I assume Vijay meant the cost of a port for private peering, in which case > > if you private with all your peers and you have a lot of small peers thats > > going to be a lot of cost for a few kbps of traffic > > I'm having trouble parsing this. You connect your FE or GE port to an > ISL/802.11q trunk to the colo's/IX switch. Then either a)everyone is in > the same broadcast domain (dumb but no config), or there's a VLAN on > that trunk from/to you to your peer(s). Save for the colo's/IX > administrative/xconnect fee, where's the "lot of cost"? This is private vs public.. Steve
Re: IP economics morphed into (TCP/RST)
On Tue, 20 Apr 2004, Blaine Christian wrote: > > The other is our new hot topic of security, not sure if anyone has thought > > of this yet (or how interesting it is) but the nature of the bgp attack > > means that if you can view a BGP session you can figure things about a peer > > that would otherwise be hidden from you in particular the port numbers in > > use.. and I'm not entirely clear on the details but it sounds like when you > > hit the first session, you can take the rest out very easily. > > > > We cant take BGP out of band (yet!), perhaps we can keep it better hidden > > from view tho.. > > There are more protection methods available than just MD5 (as you allude to > Steve). One mitigator is to use "non-routed" space for BGP peer > connections. If you have the ability to filter on TTL 255 you are in even > better shape (arguably perfectly secure against all but > configuration/hardware failures). You have some vulnerability with > non-routed space if you do default routing or have folks who default towards > the device doing the BGP peering though. Source routing is also a potential > hazard for the non-routed solution (does anyone have this enabled anymore?). > > Apologies for the morph but this raised a great point. Hmm ok so assume for a moment that I dont want RFC1918 for my links, what are my options? : There isnt a "link-local" for IP altho this would be a great solution (surely this can be written for BGP??). Or I could use all eBGP addresses from a block which I dont route and filter internally.. I suspect this is a non-starter, I will have to include all my addresses given to me by peers and its gonna screw traces, monitoring etc. Can I use secondary IP addresses and then BGP with these addresses, this would be a form of "security by obscurity" but providing you can keep the info a secret thats surely going to do it? Steve
Re: Winstar says there is no TCP/BGP vulnerability
May be, it is reasonable to have a simple MD-5 key - I mean, without a rotation, use e-mail to exchange it instead of the phone, do not generate but use simple password, and so on. If this key is never changed, then risk to lost a session is very low, and I do not see _any_ reason to keep it on rotation plan (hacker must know too much and can damage too little, in this case). Even such keys as '415' or 'monday' will prevent TCP attacks in alll cases - if single attack require 5 - 30 minutes for the one hit, then no any way exists to use dictionary 'guess' for password cracking. Now, we can see a _histeria_ around this problem; but yes, when it will coll down (1 - 2 weeks), it will be a time to make a reasonable improvements. - Original Message - From: "Patrick W.Gilmore" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Patrick W.Gilmore" <[EMAIL PROTECTED]> Sent: Tuesday, April 20, 2004 8:49 PM Subject: Re: Winstar says there is no TCP/BGP vulnerability > > On Apr 20, 2004, at 11:29 PM, Michel Py wrote: > > > Please forgive me if I'm naive and/or ask a stupid question, but is > > there any reason (besides your platform not supporting it) _not_ to MD5 > > your BGP sessions? Geez, on my _home_ router all my v4 BGP sessions are > > MD5ed (v6 not there yet). > > There is serious operational overhead in maintaining sync'ed passwords > between separate organizations. IOW: Eventually someone will screw up > and lose the password. When they do, the session goes down, and > probably for far longer than if some miscreant tries to RST it via the > "vulnerability". > > Actual data: Over the past three plus years an organization with on the > order of a dozen MD5-ized BGP sessions has has multiple down sessions > due to, for instance, a peer doing standard (for them) password > rotation and forgetting to inform the organization. Each time incurred > a minimum of several hours downtime, once stretching into several days > as the peer could not figure out what was wrong and get the right > person with the password to give it to the organization. > > Over the past three plus years with over 1000 non-MD5-ized BGP > sessions, the same organization experienced exactly *ZERO* seconds of > downtime identified as due to RST-style attacks. And certainly no > prolonged outages due to it. > > > Add to that the additional CPU overhead some people have reported, > making it easier to packet the router to its knees, and MD5 looks like > a cure worse than the disease. > > > All that said, it is your router, your peers, your decision. I would > never dream of telling anyone who wanted MD5 to not do it. I just > don't understand people who want to do it. Especially when they could > be doing things like filtering at the leaf nodes and forcing their > vendors to support the TTL hack. > > But that's me. > > -- > TTFN, > patrick >
Re: Massive stupidity (Was: Re: TCP vulnerability)
Assuming that he do not know port number and must try 20 - 40 ports, it takes 200 * 10 = 2000 seconds to resert a single session... Useless except a very special cases 9such as a big community decided to knock down SCO, for example). > > At 05:09 PM 20/04/2004, Richard A Steenbergen wrote: > > >party to know which side won the collision handling. Therefore you need > >262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again > >worst case) * 2 (to figure out who was the connecter and who was the > >accepter) = 2084569088 packets to exhaustively search all space on this > >one single Juniper to Juniper session. Now, lets just for the sake of > >argument say that the router is capable of actively processing 10,000 > >packets/sec of rst (a fairly exagerated number) and still have this be > >considered a tcp attack instead of a straight DoS against the routing > >engine. This will still take 208456 seconds, or 57.9 hours. > > I dont understand why the large differences in claims > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > says > Modern operating > systems normally default the RCV.WND to about 32,768 bytes. This > means that a blind attacker need only guess 65,535 RST segments > (2^^32/(RCV.WND*2)) in order to reset a connection. At DSL speeds > this means that most connections (assuming the attacker can > accurately guess both ports) can be reset in under 200 seconds > (usually far less). With the rise of broadband availability and > increasing available bandwidth, many Operating Systems have raised > their default RCV.WND to as much as 64k, thus making these attacks > even easier. > > > Also, with the various 'bots' at peoples disposal, why the assumption the > attack would not be distributed. > > ---Mike >
Re: snmp vuln
On (2004-04-21 23:24 -0700), Alexei Roudnev wrote: > If you ever read SNMP specs, you can realize, that there is not any C or C++ > SNMP implementation without such problem. So, rule number 1 is _never > expose SNMP to Internet, and be careful to filter out any inbound packets, > forwarded to your SNMP ports. Which makes me wonder, why in most implementations services listen in each configured address. Provider might have lot of link networks, even from customers demand from his link network. This makes filtering in borders little less feasible. And for this particular attack two way comminication is not needed, so SNMP with ACL is not enought to mitigate this. With explicitly defined listen addresses, filtering in border would be easy. JunOS allows to set interfaces to SNMP, but according to netstat it still listens in *.161. -- ++ytti
Re: Winstar says there is no TCP/BGP vulnerability
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:[EMAIL PROTECTED] > > Sent: Tuesday, April 20, 2004 11:13 AM > > To: xx > > Subject: Re: *SPAM* MD5 implimentation on BGP > > > > x, > > > > 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. > > 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)
