Re: [lisp] [Ila] LISP for ILA

Dino Farinacci <> Fri, 16 March 2018 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A11112D953; Fri, 16 Mar 2018 11:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c6VwJMQfx7mE; Fri, 16 Mar 2018 11:08:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A6AE12D870; Fri, 16 Mar 2018 11:08:42 -0700 (PDT)
Received: by with SMTP id g8so1255655pgq.13; Fri, 16 Mar 2018 11:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2fDfDEh3PiJnYapOGIoybKokcVs54by29ko0dVOE+zY=; b=il1YXLqeu3xTtBTi7oex5piOf7hA/vz1PYd6ZnQwUkR8qefwEhVEyhtPszLloJDSaA V4X9wvvwr8lh9pW2yoq+p5qcEA/zlVMegB+1W2sUo5Dd+myDmVw2+qjbtd2mHu0hmMpq 6+HCcyD8hsuBkTV/4lC7+teGLVjlRsgZFtB25xG/ya55HaI2/ShBFKrDNQBp8tN8YjG8 CCPIIei91oyXXP5o3XFDnAL+EHHiq8MZw7StJCI7TRWCAnR3so/pxr1wvmzjBsDFmWUa bvobradZ21FaEpT6A87FUhmrd4jBvhL8dU+ViMyyWwYL85ABCRTr+sN+2YMYm8P2FUsY owhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2fDfDEh3PiJnYapOGIoybKokcVs54by29ko0dVOE+zY=; b=azPKYvxCTu0X1qwEDPw8gUA0FGjREwwbLNOTzLTwTMA4TFnjXj3V6RPr0PzL/JD3pl JhrGyKD9W2nU+sAOxumdh4lGGak/TkpXH7ep+/XdGYVigNGA1LWd5R+Lw+UoGkXuG7nu P6p3LPhzqP4XTlCNmGx6cDMlmJC2N9pAVgn7Wdh89r4gJGpo85IfstyDS45/T7zRcH1j Fu7YT7ghQTlTyM6z1t1Py1kJYihNbmo07tA/4VHZbtWvgVIj/ZlGysnWrPRa0lnI6kO6 X6yj2MFGHBrsoogzO6nnLw7V2LaWmZYUEN7fS0cVY9b5WyaxYyeMAStww6IG4us7Uopy eI7w==
X-Gm-Message-State: AElRT7H0LZChcFIvp3FUwYBefEmH9mxyPuSdHofMA6W7l6pzLHBt+02F YILND45EdefaWm8vVCAsAp7gcV7G
X-Google-Smtp-Source: AG47ELvNQiUPz3bIXgQobRrPKU1/TH8Qb5OMeHwyjfnVobkh46xadCHy+jVZsqiD6b+mzTGvRl5YkQ==
X-Received: by with SMTP id y188mr2114732pgb.277.1521223721849; Fri, 16 Mar 2018 11:08:41 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p12sm13973628pgn.91.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 11:08:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 16 Mar 2018 11:08:40 -0700
Cc: Florin Coras <>, "Alberto Rodriguez Natal (natal)" <>, "" <>, "" <>, David Meyer <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [lisp] [Ila] LISP for ILA
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Mar 2018 18:08:50 -0000

Sorry about that but I did say from the Map-Resolver perspective. That is, the node that receives Map-Requests from good acting ITRs/RTRs as well as bad actors. “You” are the good and bad actors where we can’t tell one from the other (other than good actors follow the spec in rate-limiting the Map-Requests they send).


The “too …” depends on bandwidth and processing power into and in the map-resolver. 

No normative description yet. Just ideas that I have been talking to people about. Dave Meyer has thought about this and how ML can help tell us when we have deviated from a baseline of “normal behavior”. So we can go into frequency-hopping mode when we deviate by %x.


> On Mar 16, 2018, at 10:58 AM, Tom Herbert <> wrote:
> On Fri, Mar 16, 2018 at 10:38 AM, Dino Farinacci <> wrote:
>>> Attackers don't typically set the evil bit in packets and will
>>> otherwise try to make their packets indistiguishable from legitimate
>>> traffic. Can you provide a reference to a specific solution with an
>>> algorithm that is able separate the bad packets from the good packets
>>> wrt the cache.
>> All you can really do to solve this problem is (from the perspective of a LISP Map-Resolver):
>> (1) You sent a request for an EID too often, I’m dropping future requets from you.
>> (2) You sent a request for any EID too often, I’m dropping future requests from you.
>> (3) I am getting too many requests for an EID from many sources, start dropping them.
>> (4) I am getting too many requests on this specific map-resolver address, I’m going to deconfigure it. If its an anycast-address, the requests will start going to the next closest map-resolver.
>> (5) I am getting too many requests on this specific map-resolver address, I’m going to deconfigure it. If it is not an anycast-address, packets are dropped by my penultimate hop. Good actors know other map-resolvers to send to, to get their requests resolved.
>> (6) Do (4) and (5) by withdrawing the route from BGP. So the high-rate of requests get dropped closer to the bad actors.
>> In (4)-(6), I have referred to this as “solving DoS attacks with frequency-hopping techniques”. And I was thinking of doing it *with no signalling*. So good actors have to be robust to send to other map-resolvers, either serially or in parallel.
>> Comments?
> Dino,
> I'm pretty confused by who "I" is, who "you" is, as well as what
> constitutes "too often" or "too many requests". Is there a normative
> descirption of this algorithm we can look at?
> Thanks,
> Tom
>> Dino