Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description)

Dino Farinacci <farinacci@gmail.com> Thu, 08 February 2018 02:48 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F8E127978; Wed, 7 Feb 2018 18:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wF5gpuXDPuSO; Wed, 7 Feb 2018 18:48:49 -0800 (PST)
Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E98A1242EA; Wed, 7 Feb 2018 18:48:49 -0800 (PST)
Received: by mail-pl0-x22c.google.com with SMTP id v3-v6so1348670plg.3; Wed, 07 Feb 2018 18:48:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zpSfI81NqKE2VU2KEVXi2jilCq6SdaKfpgrvAL+drm8=; b=fMNnP4mhke5f7u4mV+4I/N83NmpckFYgh73yQUk5VQYaGRY+Lp0KiOMUpVBBWIgd6A sDUhSx3QQmJwkb5GT5coOw7x1EzlhFxMRxDgo6kMTVyJLZzQco64H8TksG17oNrffEol vt6Da9HaEquptkMppBqOpM3WxaV5wjmeJF8aLXBzQn/wCiHsyGCV5uMi4qNQh4S0FtRV bjM+ABFNixh+Mi3ZFCH6iDWQ3RiN2lHWs6hGDdAyoSTbU6sv8n20+KHqKekOSdyYjkwL 93Tynhv4FitcGA9AimfbHyP7NXKW+75lkkjaJ2rLfncUKYuHB1yDD/ZF/X0kpxF+KOS4 XCeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zpSfI81NqKE2VU2KEVXi2jilCq6SdaKfpgrvAL+drm8=; b=gvMdFw1ZxmtiNSeC3hO5iT0HWSRGHixavBnDj06zZS9kSsGXbqdhJwlLdsPiN4xcTv seCOHYWJT5rlIn4RmonfRXjuLRL6ngm0HlF6pIOp2yLHX+xLxOR33qLkla5qKoyHAkXf /Jl73fEv0VygxKe9wOuCE2Skn+YAI8L5tKiYHItfES/SL7xBXIJBFMf6jLgeMGQQ+Tve FM00UZPtNg0j6KQ5/bjMzBKiZVbjT5vUbcTKItxQMRyc9drJaILSCXEwpmXiK20VdUjp +lnGOaBFpVMNgbPjTbyae8J35+JbTxzMfR4fvcc0N+s5jWp3SP+x7qZdARhGdwCjUl4I HlAw==
X-Gm-Message-State: APf1xPAqTydtmAzeYZIdD4h68/vlYYFseog2f1RM+uRxdj7fmXRHDsUW pGoGJ4K8oC+4FbQzTm0OCiw=
X-Google-Smtp-Source: AH8x227mQYnUv05gl7tT8ga0Rdt6jykJESHMo/OITpHtyZj4oGnZnVjojbBFleRC8bgAM3AFA9FhZA==
X-Received: by 2002:a17:902:b20b:: with SMTP id t11-v6mr8067189plr.348.1518058128844; Wed, 07 Feb 2018 18:48:48 -0800 (PST)
Received: from [10.127.13.200] ([59.29.98.4]) by smtp.gmail.com with ESMTPSA id c185sm6720933pfb.146.2018.02.07.18.48.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 18:48:48 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAPDqMeq9yWoEY7WvtX7v-p0UN01-BjERVUF0HNFTEqwD=P1X=g@mail.gmail.com>
Date: Wed, 07 Feb 2018 18:48:44 -0800
Cc: Tom Herbert <tom@herbertland.com>, 5GANGIP <5gangip@ietf.org>, Behcet Sarikaya <sarikaya@ieee.org>, ila@ietf.org, Alexandre Petrescu <alexandre.petrescu@gmail.com>, Lorenzo Colitti <lorenzo@google.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D518818A-B2DF-40EE-8880-1D1B8B67FADC@gmail.com>
References: <CALx6S37+1PK3ET7g+XsCHt6-CJrABLko0YbWgE12xFX=vL5OPA@mail.gmail.com> <5067FA81-B416-4A19-9F11-A08B35BB8B6D@gmail.com> <CAPDqMeqNkiOWHOVU0AsUzFfPH60pTdS2x9CePhvZDhVLGJoGmw@mail.gmail.com> <9C425F56-738C-4600-9DFF-9D30FC3872DC@gmail.com> <CAPDqMeoLPSGbFg_H-_yOPBguXhOmx8fXjzYd_ax1Qds56KibZQ@mail.gmail.com> <EF6D1220-510C-4A4A-A15E-CA7029B300F7@gmail.com> <CAPDqMeq9yWoEY7WvtX7v-p0UN01-BjERVUF0HNFTEqwD=P1X=g@mail.gmail.com>
To: Tom Herbert <tom@quantonium.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/FXXgK9zuI3EzK6N7mMmdwOd3XLM>
Subject: Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description)
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Feb 2018 02:48:51 -0000

> Yes. OOO packets are possible during a transition period. In order delivery is not a requirement of IP and the window for OOO packets is relatively small anyway.

Right but frequent out-of-order delivery does not make the system as a whole work well. And the “transition period” is for *every new destination” that is not cached. So this can be a steady state situation.

> > trianglular routing. Redirects must be secure so that they cannot be spoofed, so for that reason (and some others) the protocol is over TCP. The mapping cache is only an optimization and packets are never dropped or queued for pending cache resolution. If the cache weren't present, communications would
> 
> But the ILA router in the network needs to have the mapping. And if it does not, what happens then?
> 
> The ILA router is considered authoritative for its shard. If it doesn't have a mapping then the packet is silently dropped as having an unreachable destination.

Does the ILA router for the shard only route to destinations inside of the shard? And if so, it is kept small so you can push the mappings and make it scale at that level?

> > still be viable but sub-optimal; that characteristic establishes a bound for the worst case DOS attack.
> >
> > Any thoughs on this approach?
> 
> You’ll really need to put signatures in the Redirect messages if you want robust authentication.
> 
> The redirects are sent over an established TCP connection to an ILA-N so that deters message spoofing. For stronger security, TCP authentication option or TLS can be used.

Is it worth the state to hold millions of TCP connections only the occasion redirect message?

Dino