Re: Routing Suggestions
Date: Fri, 14 Jan 2011 01:50:40 -0800 From: Randy Bush ra...@psg.com Subject: Re: Routing Suggestions i'm with jon and the static crew. brutal but simple. if you want no leakage, A can filter the prefix from it's upstreams, both can low-pref blackhole it, ... One late comment -- OP stated that the companies were exchanging 'sensitive' traffic. I suspect that they di *NOT* want this traffic to route over the public internet -if- he private point-to-point link goes down. if they're running any sort of a dynamic/active routing protocol then -that- route is going to disappear if/*WHEN* the private link goes down, and the packets will be subject to whatever other routing rules -- e.g. a 'default' route -- are in place. This would seem to be a compelling reason to use a static route -- insuring that traffic _fails_ to route, instead of failing over to a public internet route, in the event of a link failure.
Re: Routing Suggestions
On Jan 18, 2011, at 4:54 PM, Robert Bonomi wrote: Date: Fri, 14 Jan 2011 01:50:40 -0800 From: Randy Bush ra...@psg.com Subject: Re: Routing Suggestions i'm with jon and the static crew. brutal but simple. if you want no leakage, A can filter the prefix from it's upstreams, both can low-pref blackhole it, ... One late comment -- OP stated that the companies were exchanging 'sensitive' traffic. I suspect that they di *NOT* want this traffic to route over the public internet -if- he private point-to-point link goes down. if they're running any sort of a dynamic/active routing protocol then -that- route is going to disappear if/*WHEN* the private link goes down, and the packets will be subject to whatever other routing rules -- e.g. a 'default' route -- are in place. This would seem to be a compelling reason to use a static route -- insuring that traffic _fails_ to route, instead of failing over to a public internet route, in the event of a link failure. That's why I always prefer to put this traffic inside an IPSEC VPN. Then, you gain the advantage of being able to let the internet serve as a backup for your preferred private path while still protecting your sensitive information. Then I use dynamic routing and take advantage of the diverse path capabilities. Owen
Re: Routing Suggestions
i'm with jon and the static crew. brutal but simple. if you want no leakage, A can filter the prefix from it's upstreams, both can low-pref blackhole it, ... randy
Re: Routing Suggestions
- Original Message - From: Joe Hamelin j...@nethead.com To: Randy Bush ra...@psg.com, NANOG list nanog@nanog.org Sent: Friday, January 14, 2011 6:50:05 AM Subject: Re: Routing Suggestions On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush ra...@psg.com wrote: i'm with jon and the static crew. brutal but simple. My name is Joe, not jon, Randy. I'm pretty sure Randy was responding to Jon Lewis... [...] Go fuck yourself. Happy Friday to you too. -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760
Re: Routing Suggestions
On Fri, 14 Jan 2011, Joe Hamelin wrote: On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush ra...@psg.com wrote: i'm with jon and the static crew. brutal but simple. My name is Joe, not jon, Randy. But what can I expect from a man that used the phrase tell him to go fuck himself when I put my hand out in greeting back at Atlanta NANOG in 2001, when your company sales person mentioned that I should meet you. (I was only the BGP driver and pipe buyer for Amazon at the time.) Don't mind me. I'm invisible. I'll be at NANOG Miami in two weeks...only my second time attending one. I'll have to try meeting Randy in person this time and see if I rate better than a fuck off. Even Vixie had a bit more class after I asked him a question at LISA Perhaps you had him confused with someone else. You Internet demigods need a clue stick to the head and understand My boss calls NANOG the Masters of the Universe conference. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Routing Suggestions
Randy, I know my solution was right. I don't need your blessing. Go fuck yourself. It's nice to see we've really elevated the level of discourse around here :) -dorn
Re: Routing Suggestions
My name is Joe, not jon, Randy. congrats. but i was speaking of jon lewis. randy
Re: Routing Suggestions
On 1/14/2011 7:49 AM, Jon Lewis wrote: My boss calls NANOG the Masters of the Universe conference. Beats Unruly kids with toys conference. ;) Jack
Re: Routing Suggestions
On Fri, Jan 14, 2011 at 8:54 AM, Dorn Hetzel dhet...@gmail.com wrote: Randy, I know my solution was right. I don't need your blessing. Go fuck yourself. It's nice to see we've really elevated the level of discourse around here :) yea... back to the coffee urn for me! (sometimes folks have hot-button-issues...) -chris
Re: Routing Suggestions
On Fri, Jan 14, 2011 at 8:20 PM, Randy Bush ra...@psg.com wrote: i'm with jon and the static crew. brutal but simple. Depending on how the interconnect is built, using the permanent keyword along with the static route may be worth investigating also if you want the static route to stay in place, if you wish to prevent the static being withdrawn if the interface goes down. Sam
Routing Suggestions
Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Cheers, Lars
Re: Routing Suggestions
On Jan 12, 2011, at 7:13 PM, Lars Carter wrote: Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B ... [ trimmed, but they want to interconnect directly, one does static, the other can do bgp] From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? I suggest using one of the reserved/private BGP asns for this purpose. ASNumber: 64512 - 65535 ASName: IANA-RSVD2 ASHandle: AS64512 RegDate:1995-04-06 Updated:2009-01-14 Comment:Designated for private use [RFC1930] - Jared
Re: Routing Suggestions
On Wed, 12 Jan 2011, Jared Mauch wrote: I suggest using one of the reserved/private BGP asns for this purpose. ASNumber: 64512 - 65535 It sounds to me like Company B isn't doing BGP (probably has no experience with it) and if there's only a single prefix per side of the cross connect, especially if the cross connect is going into routers smart enough to remove a route from the table if the destination interface is down, static would do just fine. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Routing Suggestions
On 1/12/2011 4:13 PM, Lars Carter wrote: Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Cheers, Lars Apply the KISS principle. Use a static route
Re: Routing Suggestions
On Wed, Jan 12, 2011, Jon Lewis wrote: On Wed, 12 Jan 2011, Jared Mauch wrote: I suggest using one of the reserved/private BGP asns for this purpose. ASNumber: 64512 - 65535 It sounds to me like Company B isn't doing BGP (probably has no experience with it) and if there's only a single prefix per side of the cross connect, especially if the cross connect is going into routers smart enough to remove a route from the table if the destination interface is down, static would do just fine. Unless you'd like to ensure the sensitive traffic doesn't cross an unsafer default rout path if the XC is down. (Assuming the prefixes are both public IPv4/6 space to begin with.) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: Routing Suggestions
Since it sounds like there is no alternate path, it sounds like the most secure, simplest to operate would be static routes. It's not sexy, but no need to toss in a routing protocol if it's such a static setup. --Original Message-- From: Lars Carter To: NANOG@NANOG.org Subject: Routing Suggestions Sent: Jan 12, 2011 7:13 PM Hi NANOG list, I have a simple, hypothetical question regarding preferred connectivity methods for you guys that I would like to get the hive mind opinion about. There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Cheers, Lars Sent from my “contract free” BlackBerry® smartphone on the WIND network.
Re: Routing Suggestions
On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote: From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Static routing - at least on the direct link. For extra security, you might want to make sure that the sensitive traffic won't take the internet path, but only the directconnection. Example: 192.168.0.0/24 being the prefix in question. Drop traffic for that /24 via a static Null0 (IOS et al) / discard or reject (JUNOS) route. Then add /25 statics for 192.168.0.0/25 and .128/25 via the direct link. On the BGP speaking network, make sure you don't accept 192.168.0.0/24 or more specifics of that via BGP from untrusted parties. In case the link goes down, the /25s should become inactive, and the /24 Null/discard/reject route prevents leakage of sensitive data in unintended (untrusted) directions (e.g. Internet) via default or covering aggregate routes. Of course all this assumes no dynamic redundancy etc. and some other things not further specified in your scenario. There are many ways to skin a cat. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- d...@ircnet -- PGP: 0xA85C8AA0
Re: Routing Suggestions
On Wed, Jan 12, 2011 at 07:13:53PM -0500, Lars Carter wrote: [snip] There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Company A has a small but knowledgable engineering staff and it's network is running BGP as its only routing protocol with multiple transit vendors and a handful of other larger peers. Company B is a smaller shop that is single homed behind one ISP through a default static route, they have hardware that can handle advanced routing protocols but have not had the need to implement them as of yet. There is a single prefix on both sides that will need to be routed to the other party. It is rare that prefixes would need to change or for additional prefixes to be added. From an technical, operational, and security standpoint what would be the preferred way to route traffic between these two networks? Use eBGP. Company B runs a mutually-agreed private ASN (at least from company A's unused list). This scales from the initial deployment to multiple cross-connects for failover [or even IPSEC tunnel over public interfaces]. Company B should have Company A provide some clues to their staff if needed (and get more out of the deal). Simple static solutions wind up being entrenched, so move/add/change becomes convoluted. And how many times has one prefix really stayed that way? :-) -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Routing Suggestions
On Thu, 13 Jan 2011, Adrian Chadd wrote: On Wed, Jan 12, 2011, Jon Lewis wrote: On Wed, 12 Jan 2011, Jared Mauch wrote: I suggest using one of the reserved/private BGP asns for this purpose. ASNumber: 64512 - 65535 It sounds to me like Company B isn't doing BGP (probably has no experience with it) and if there's only a single prefix per side of the cross connect, especially if the cross connect is going into routers smart enough to remove a route from the table if the destination interface is down, static would do just fine. Unless you'd like to ensure the sensitive traffic doesn't cross an unsafer default rout path if the XC is down. BGP would have that same issue since B is default routing to their provider. [config for B] ip route A's prefix mask gw to A ip route A's prefix mask null0 250 ip route 0.0.0.0 0.0.0.0 B's provider problem solved. If the gw to A is reachable, traffic goes via the cross connect. If the gw is down, traffic goes nowhere. -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Routing Suggestions
There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Second NIC on a secure server at A wired with a crossover cable to a second NIC a secure server at B. Use an RFC1918 /30 that is null routed on both companies routers. KISS. Hand it off to the developers. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
Re: Routing Suggestions
On Wed, Jan 12, 2011, Jon Lewis wrote: Unless you'd like to ensure the sensitive traffic doesn't cross an unsafer default rout path if the XC is down. BGP would have that same issue since B is default routing to their provider. [config for B] ip route A's prefix mask gw to A ip route A's prefix mask null0 250 ip route 0.0.0.0 0.0.0.0 B's provider problem solved. If the gw to A is reachable, traffic goes via the cross connect. If the gw is down, traffic goes nowhere. I was just making the observation; the solution is pretty simple. (Yes, I've seen secure network cross-connects get bitten by this. :-) Adrian -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: Routing Suggestions
What Joe Said. Static with 1918 space. If they NEED global space, explain 1918 space will work and tell them to use it. -jim On Wed, Jan 12, 2011 at 9:02 PM, Joe Hamelin j...@nethead.com wrote: There are two companies, Company A and Company B, that are planning to continuously exchange a large amount of sensitive data and are located in a mutual datacenter. They decide to order a cross connect and peer privately for the obvious reasons. Second NIC on a secure server at A wired with a crossover cable to a second NIC a secure server at B. Use an RFC1918 /30 that is null routed on both companies routers. KISS. Hand it off to the developers. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
