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

Tom Herbert <tom@quantonium.net> Wed, 07 February 2018 19:14 UTC

Return-Path: <tom@quantonium.net>
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 2D8B612D84D for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 11:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 LfUcVi_Ji-e7 for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 11:14:11 -0800 (PST)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 951DD127275 for <ila@ietf.org>; Wed, 7 Feb 2018 11:14:11 -0800 (PST)
Received: by mail-wm0-x243.google.com with SMTP id v71so5429919wmv.2 for <ila@ietf.org>; Wed, 07 Feb 2018 11:14:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uk3ahkTCFsbZYJfa2YQnC2TMPlvDU0yZOtYu+/oAif4=; b=tQ9DCq2yUv5SBhheibQ74HwAuriukd0fhF1dK32AzwrBmzKnesxRDjGXbcfxk7/BKN Qy/IrOJYTjl/1k3cTYmaHYzC1ygp7tqKh2cXcq8CHHrsypJjnHrV+ombc+jIYiCf1Zpt ghCm7EMGMnKyoN7Zt06JKqDbIhwgE6a5lTAD8q8zOVkzTkahPJ1XNGQGC1/15zO5wlc/ MvcCDVqxo5xVvN3i0set/iv4OU57TJRfi9lLRjlz7g/es5BEV+PXtAT9NJzFIbrUkF0A pKQ3RzJ7xI5+RSOj7jw8Db+HERoUeMJPABheftsMU9Fcy8i8IElJFtD4/Kt0vSzSBHUt aSmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uk3ahkTCFsbZYJfa2YQnC2TMPlvDU0yZOtYu+/oAif4=; b=Ig5REJvMvH7vXPM92bK9W2tN3CYjRuq9kbEnypb97jmw3EA/GWrTjjPf3PBhxtL6I6 vuKs6NN718nrQkXv8LngN1XzOTrE1HfzwjfKuDOHa0/uk5X52KwFtLvPs5giRvR4CRfu +WoPqqTGj5q52SHnQSXyNlTz+V80IN2paULiHG38hCyKP7/J0nYfLuWwqnA/9QyBd8It 7sHRAADMakjZEdNdrzDOHE2LuwfIAkqPdECUHYYlWA4ehdWuSIZxU9z6gDTFna51poWQ v57YbLVOGm3QVKbPAzMloJrB1pWxtLwOaMZcN4jW4xrcaJdRapHQY2W76dX7hyLvBoGb H4cQ==
X-Gm-Message-State: APf1xPBSw/lHwTS1vAopc9SZKlmdJiEEeHSUqyXz49R/o+fLvW598gvJ rfPv7faGsYLyCsA1hQUKqiipp9P5LANCy6DutNqcFQ==
X-Google-Smtp-Source: AH8x227gMulY99oWP5E2a9nONftWbEeFuVT0PI3vMfLxwIGRIHkZs8nKR36P5nfUARHU10RXad/4QX0v6QYdUkJRnAo=
X-Received: by 10.28.241.14 with SMTP id p14mr5524625wmh.20.1518030849991; Wed, 07 Feb 2018 11:14:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.173.66 with HTTP; Wed, 7 Feb 2018 11:14:09 -0800 (PST)
In-Reply-To: <EF6D1220-510C-4A4A-A15E-CA7029B300F7@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>
From: Tom Herbert <tom@quantonium.net>
Date: Wed, 07 Feb 2018 11:14:09 -0800
Message-ID: <CAPDqMeq9yWoEY7WvtX7v-p0UN01-BjERVUF0HNFTEqwD=P1X=g@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
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-Type: multipart/alternative; boundary="089e082f9ab4927a980564a41934"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/J-nP5b--rQuVOssTbM6T-6pSolw>
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: Wed, 07 Feb 2018 19:14:14 -0000

On Wed, Feb 7, 2018 at 6:16 AM, Dino Farinacci <farinacci@gmail.com> wrote:

> > In ILAMP (https://tools.ietf.org/html/draft-herbert-ila-ilamp-00)
> secure redirects are defined to be the primary means of populating a cache.
> On a cache miss, a packet is forwarded into the network and routing should
> forward the packet to an ILA router that contains the complete set of
> mappings for the
>
> In LISP, we have PITRs that do roughly the same thing. But it comes at an
> expense that EIDs need to be advertised into the core routing system. I
> guess in your case, it is on the SIR-prefix that is injected and a packet
> destined for any ID with a SIR-prefix goes to the closest ILA router. Is
> that right?
>
> Yes. The packet is routed to an ILA router based on a prefix that contains
the shard index.


> > associated shard. The router performs the transformation and can send a
> redirect back to the caching node. The redirect can be cached so that
> subsequent packets take a direct route and avoid the
>
> But you will get some out of order packets. Until the cache is populated,
> packets are still in the network, either packets that have not reached the
> ILA router, or packets that have been transformed. So if the ILA router
> near the source, or the source itself, sends directly, there is a chance it
> is a shorter path. So new packets arrive to the destination before packets
> in flight.
>

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.


> > 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.


> > 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.

Tom