Re: [v6ops] [GROW] Deaggregation by large organizations

Iljitsch van Beijnum <iljitsch@muada.com> Sun, 26 October 2014 11:05 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333E31A7D82; Sun, 26 Oct 2014 04:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJo7aNlZ_Y7q; Sun, 26 Oct 2014 04:05:36 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D835D1A7D81; Sun, 26 Oct 2014 04:05:35 -0700 (PDT)
Received: from [192.168.178.23] (5356888C.cm-6-7c.dynamic.ziggo.nl [83.86.136.140]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id s9QB5IQi007726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 12:05:19 +0100 (CET) (envelope-from iljitsch@muada.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <544BB713.8000803@globis.net>
Date: Sun, 26 Oct 2014 12:05:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DDE5D8F-4B17-4D11-9F19-F94C38E7E749@muada.com>
References: <F5C06CAF-0AD2-4225-8EE7-FC72CE9913F0@muada.com> <755DE4C3-CDDF-41AF-BA9C-E8EC5B4DFC4C@muada.com> <011101cfe935$d0e8a600$72b9f200$@riw.us> <544BA11F.7050102@globis.net> <31FED6FF-5398-4793-87F3-AC873811FD64@muada.com> <544BB713.8000803@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/myMIn-zR6L0bP4qLanst0Az-nNA
Cc: Russ White <russw@riw.us>, v6ops@ietf.org, grow@ietf.org
Subject: Re: [v6ops] [GROW] Deaggregation by large organizations
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Oct 2014 11:05:38 -0000

On 25 Oct 2014, at 16:43, Ray Hunter <v6ops@globis.net> wrote:

> I'm not convinced your draft is in line with my own understanding of how multinationals I know either use, or want to use the Internet, and why the de-aggregation occurs in the first place.

> I'd thus like to see more data on where/why the de-aggregation is occurring.

Yes, that would be good to know. I guess when I have some time I'll take the Fortune 500 and see what they inject in the global routing table.

However, it's still early days for IPv6 so what we see today isn't necessarily a reflection of what's needed in the future.

> Internet "offload" is a common requirement for low value traffic, in conjunction with a private high quality internal Intranet for corporate apps like design tools, with both networks active simultaneously.

> My thinking is that SADR, and running multiple (PA) prefixes within an enterprise will address this requirement. So each sub unit would carry both the multinational/global PI space and one or more local PA space prefixes obtained from the local ISP. Only the local PA space would be advertised out of each break out. That would be and prevent the need for de-aggregate routes to be advertised back into the individual ISPs serving the sub unit satellite sites.

Do you have any examples of networks doing this? Using multiple addresses is not easy.

> Equally GRE tunnels or IPSEC tunnels over Internet are already common-practice to create virtual enterprise networks.

But that doesn't mean you want all your employees in Europe browsing the web through a tunnel to North America.

> > This way, deaggregates only have to be carried by ISPs providing the
>   aggregate of last resort service and the ISPs connecting subunits of
>   the organization.

> I don't think enterprises want to be tied to ISP's at all.

What do you mean? That they run their own network? Or that they can switch ISPs easily? No reason the latter couldn't be accomplished with the aggregate of last resort service.

> I don't know of any small set of ISPs that can economically provide service in 50+ countries in some sort of coordinated aggregate ISP manner.

Simple. Pay ISPs 1 and 2 to announce the aggregate. Then go look for ISPs 3 - 50 and tell them if they want your business, they have to interconnect with 1 and 2 (as customers or peers, you do't care). 1 and 2 need to be present globally or close to it but not necessarily locally, while 3+ need to be available locally but not necessarily globally.

> > In theory, a user in Tokyo could connect to the internet in Madrid. In practice, this is is exceedingly rare.

> I don't agree with this observation. I know of many cases e.g. where a break in/out for a 3rd party from China is made in Europe. Or where a US based company manages systems remotely in Europe, LATAM, Asia Pacific, and the US and has regional links to the customer (with a break in/out per region).

Can you provide IP addresses that can be tracerouted?

> My particular worry with aggregates of last resort would be that with longest prefix match matching, it's becoming increasingly easy for longer prefixes to hijack important enterprise aggregates. So advertising an aggregate of last resort, whilst allowing sub units to advertise longer prefixes to other ISPs, might not be such a great idea for security.

I guess the draft adds one issue here: an attacker could inject a longer prefix but add communities that cause it to be filtered before it reaches certain places so the hijacking is less obvious.

But unless you want the IPv4 table to be 14M /24s and the IPv6 table be some unholy number of /48s, the real solution to prefix hijacking needs to be found elsewhere.