From an technical, operational, and security standpoint what would be the
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. preferred way to route traffic between these two networks? Cheers, Lars
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
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_________
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 -
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_________
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 -
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
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: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
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
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
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 <joe@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
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
On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush <randy@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.) Even Vixie had a bit more class after I asked him a question at LISA 96 and all he said was "RTMfF. Next!" in his receiving line for questions about BIND.. (The same LISA where Larry was selling his first PERL book, signing shirts with Tom and Randal.) Six years later in Seattle he gave thoughtful consideration and an insightful answer to another question. (He had a bit of a cold that day and may have been off-game.) You Internet demigods need a clue stick to the head and understand that not all of us are as smart as you and we need your advice at times. We would much appreciate you not talking down to us when you do decide to send words from above. BTW: Do the clouds under Mt Olympus filter out caps? Randy, I know my solution was right. I don't need your blessing. Go fuck yourself. -Joe Hamelin PS: Thank you Jim. Always a pleasure working with (or interviewing) you. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
----- Original Message -----
From: "Joe Hamelin" <joe@nethead.com> To: "Randy Bush" <randy@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 <randy@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
On Fri, 14 Jan 2011, Joe Hamelin wrote:
On Fri, Jan 14, 2011 at 1:50 AM, Randy Bush <randy@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_________
On Fri, Jan 14, 2011 at 8:54 AM, Dorn Hetzel <dhetzel@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
On Fri, Jan 14, 2011 at 8:20 PM, Randy Bush <randy@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
Date: Fri, 14 Jan 2011 01:50:40 -0800 From: Randy Bush <randy@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.
On Jan 18, 2011, at 4:54 PM, Robert Bonomi wrote:
Date: Fri, 14 Jan 2011 01:50:40 -0800 From: Randy Bush <randy@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
participants (17)
-
Adrian Chadd -
Christopher Morrow -
Daniel Roesen -
Dorn Hetzel -
Jack Bates -
Jared Mauch -
jim deleskie -
Joe Hamelin -
Joe Provo -
Jon Lewis -
Lars Carter -
Matthew S. Crocker -
Owen DeLong -
Randy Bush -
Robert Bonomi -
Roy -
Sam Silvester