Re: US/Canada International border concerns for routing
It seems to me the original question was asking about it more from a legal perspective, in other words does Canadian traffic have to stay in Canada. IANAL (or a Canadian), but the answer is "mostly, no, especially as related to publicly routed traffic" as should be evidenced based on what's already been discussed here. In other words, there is restricted traffic but unless you're making a play for MAN/WAN type service on owned infrastructure, those requirements are unlikely to arise. To support the macro point, there is some big-boy level peering in Toronto but not really much else outside that, but there are plenty of routes that don't cross the border if you don't have to jump networks to your destination, for example going to an AWS on ramp in Canada using a native partner network, especially in the Toronto-Ottawa-Montreal. Dave Cohen craetdave@gmail.com
Canadian here who's evaluated service providers and dealt with legal requirements for our customers... Generally we weren't worried about data travelling through the US based on normal internet routes, as long as it was encrypted. The thing we usually specified in RFPs was that the data could never be stored in the US. On Tue, 8 Aug 2017 at 17:52 Dave Cohen <craetdave@gmail.com> wrote
That is what our lawyers are starting to figure out, too. Very glad to see them converging on the tribal wisdom. Cheers, David -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Andrew Kerr Sent: Tuesday, August 08, 2017 6:03 PM To: nanog@nanog.org Subject: Re: US/Canada International border concerns for routing Canadian here who's evaluated service providers and dealt with legal requirements for our customers... Generally we weren't worried about data travelling through the US based on normal internet routes, as long as it was encrypted. The thing we usually specified in RFPs was that the data could never be stored in the US. On Tue, 8 Aug 2017 at 17:52 Dave Cohen <craetdave@gmail.com> wrote
---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
On 2017-08-09 10:11, Hiers, David wrote:
That is what our lawyers are starting to figure out, too. Very glad to see them converging on the tribal wisdom.
late to discussion. You might get some organisations which require you to provide intra-canada routes for privacy reasons. But at the moment there are no laws that require it. Also, you need to consider that the way the Internet is designed, should a Montréal-Toroonto link go down, traffic will automatically reroute Montréal-New-York-Chicago-Toronto. So it becomes hard to *guarantee* intra-Canadian routes. (such arrangements do exist for military type of classified private networks). It is consumer pressure and advocacy groups who are raising the issue of intra-Canada routing. (Patriot Act in USA gets NSA to listen to any/all intl traffic, and Canada-USA-Canada traffic is considered such by USA). But from a regulatory poimt of view, the most one could expect would be a requireement to openly peer at exchanges where a netowrk has a presence. (as opposed to garanteeing intra-canada routes). And even that isn't on horizon at the moment. Note that normal businesses want to peer because it reduces costs. The old incumbents such as Bell work on a monopoly mentality of forcing people to buy transit from them, so allowing peering is against their philosophy of forcing yo to buy transit. (and if you don't buy from them, you then have to buy extra capacity to USA to connect to them). Some US transit providers, after having been here for a while, start to get their own intra-Canada links (such as Montréal to Toronto) where traffic warrants. reduced latency is likely the biggest winner in this.
I can't thank everyone enough for their input and insight! It sounds like my discovery didn't miss some glaringly obvious form, checkbox, agreement or community (NO-US-EH, for instance <snark> ) to keep traffic from crossing the border. Data *storage*, on the other hand, is a very different thing, and even a drunk intern can find the rules around that kind of thing. Thanks again, David -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Dave Cohen Sent: Tuesday, August 08, 2017 5:53 PM To: Bill Woodcock <woody@pch.net> Cc: nanog@nanog.org Subject: Re: US/Canada International border concerns for routing It seems to me the original question was asking about it more from a legal perspective, in other words does Canadian traffic have to stay in Canada. IANAL (or a Canadian), but the answer is "mostly, no, especially as related to publicly routed traffic" as should be evidenced based on what's already been discussed here. In other words, there is restricted traffic but unless you're making a play for MAN/WAN type service on owned infrastructure, those requirements are unlikely to arise. To support the macro point, there is some big-boy level peering in Toronto but not really much else outside that, but there are plenty of routes that don't cross the border if you don't have to jump networks to your destination, for example going to an AWS on ramp in Canada using a native partner network, especially in the Toronto-Ottawa-Montreal. Dave Cohen craetdave@gmail.com
---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
participants (4)
-
Andrew Kerr -
Dave Cohen -
Hiers, David -
Jean-Francois Mezei