Re: [lisp] [Ila] LISP for ILA

Tom Herbert <> Fri, 16 March 2018 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D334312D778 for <>; Fri, 16 Mar 2018 11:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Ky6iErmy5Wcr for <>; Fri, 16 Mar 2018 11:23:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F1B7127369 for <>; Fri, 16 Mar 2018 11:23:22 -0700 (PDT)
Received: by with SMTP id w128so4714725wmw.0 for <>; Fri, 16 Mar 2018 11:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YVNvVSfeDZv/peoBeNbw7r4eqxrCGz7vsKHjyMSlB8Y=; b=XQ+NfJughhIFaco5jSBCctpY9CzeZQ8TuMr5v30C0uLYgj+z43Syp4egdgjlcyxWAh zqGzGfbrZC9awNkF0KmX+hLNTId6nkyOl+6CyJbXeFgEC1JYYnp5HWU7gK9TiAnCqP0D eThkYyvY5VEAIQdO30aKiztwGh6rJ4RPVrInPRBgvj/VIhM51oPy79aGCX/vFaTfadpY HYLfGqqvbiNtQFMSjnLlpEZOr+f0Yc7C1gz36Bay7mfSUDN+ysPxeXVs+gB5lezb5IM8 qLyoN7Otw39xgB5On9SoWfkkyOXEzprh9cMhXSycpe43fokB5LRQ4x/FPv+oOi0tATDF lj/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YVNvVSfeDZv/peoBeNbw7r4eqxrCGz7vsKHjyMSlB8Y=; b=QuCGJsPxSLQckeajM464zy0LvYjXsfOWHtXsjykF8HfzNOCdF5IdN8y7WGygl+VUa5 MZv0eXztEh8vX+cSwmWZYVGD+jd3cjMExxiH/JxZTnfuR+atzF0e4GEkouKWINIm6vn9 venqa9PGatU8/ocSaCLn8xuPOwPgKDXyEpZLidOy7NhaUt0VsRomkERsNgtdUO42hZzf wKGo2oh5p0lJJA9giVJCJ7kFpI/T0SfVnHnubosTHHeYpU82rsJrkzf9RBvnbu40A4QS dKGg836rvAGm7s4Tk+hg+CcUIMUfBZIBhOzShsw5bO8AOlWlA5VxrsgLvX52ryMluQPZ /RYg==
X-Gm-Message-State: AElRT7FvGZhR9V3G/NOfTE3oITeBXWRdUHwSncL4NQH3Gr2Zfwvcw9dY NApOyi3cg13MnjW3ycekrMcHW7L3SSTV8D3nyM1JQA==
X-Google-Smtp-Source: AG47ELutjkLTHper8dqxs4R/3xPKUooj/5kPHvvJAx6GukNwiAe52JSOGk189AzyMiJa2qpndOm9LgiYdkh+i+gPch0=
X-Received: by with SMTP id c50mr2522185wra.196.1521224600845; Fri, 16 Mar 2018 11:23:20 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Mar 2018 11:23:20 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 16 Mar 2018 11:23:20 -0700
Message-ID: <>
To: Dino Farinacci <>
Cc: Florin Coras <>, "Alberto Rodriguez Natal (natal)" <>, "" <>, "" <>, David Meyer <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:23:25 -0000

On Fri, Mar 16, 2018 at 11:08 AM, Dino Farinacci <> wrote:
> 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).
> Better?
> 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.

Detecting that something is under DOS attack is not problem. It's
pretty obvious when a device is getting flooded which a bunch of
spoofed SYNs for example. The problem is trying to find that one SYN
packet in a thousand that is not part of the attack and is actually
legitimate. Again this is not easy because the attacker is purposely
trying to prevent this determination. AFAIK this is a generally
unsolved problem and probably impossible to fully solve. So if the
reaction to the attack is to stop all requests and that one legitimate
flow is blocked from making progress, then it would seen the DOS
attack is successful.