Re: [lisp] [Ila] LISP for ILA

Dino Farinacci <> Fri, 16 March 2018 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BBF71273E2; Fri, 16 Mar 2018 10:38:39 -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 y8GIxWgRUehr; Fri, 16 Mar 2018 10:38:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7AD212D0C3; Fri, 16 Mar 2018 10:38:37 -0700 (PDT)
Received: by with SMTP id h19so4405168pfd.12; Fri, 16 Mar 2018 10:38:37 -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=89oK3rKtVOdOjQcJ+2F7A+FreN1QfZKHX/VRPvI4xuw=; b=dF3Y3rLDlateTzlStWioT+0P8W1Tn0jAqpVqrAQqHT96tH4bZvhGByBZPbJzftLNRF jTF0lyyU7O2C+RFDboXwBJs2vX25zheaT4kHdMRvQltOspRnL56MywEVCtv25qcm/Rla 4wjt92VpMs81As0dOtQYSGXdQ4L0TwwF56pKqY5aVgfG9gYynZCISoFtvGdzprwfK760 3NZVmnnqO+TitelUwtDw9xbln6Mg1KdKa1P56nC7IWVgcQM4l6Z3aY+5T6cPw+PfBWlK eo/O5GWsj5H4Lv088wcJpeqNBb25OeSPRpeWVSb1m6XkHU84b1B1YA/Zdw34/tBWo7i4 MfgQ==
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=89oK3rKtVOdOjQcJ+2F7A+FreN1QfZKHX/VRPvI4xuw=; b=ZA4ivE15t0TY+LAnUFL9K0YU4Dwx7UP+9mprW2KoH8oUqt0QBy9nt4UhEnS0QLGV6F UvVtuYIs/xo5cDkk817GhtFFT1sDmoULtH1eiszHRR/gulJVw+/tdWe0QAjwTUeZY4LW 0VjPNtwFamANVplgD/raPjxhuwB0SG4dT+JhT/HovcvCLjvcmLUgu4ArofWvT3OQ232n 7WrsfzP/wgz3UJUOsV71DA3tBJmFDuWSVfGM0ClV/1wPYgOI3cCsMCptnb00xVCEa/lM JBejEIgv6OMmkU5fp4AZgOe8Y+RAt6oPLPmUSYlBvWcw80a91BWojGqNwF+9fKw+8REt HoNg==
X-Gm-Message-State: AElRT7F8JSgd/jNUorGqfPId8iE9Q3leSi1cugB0WNTVToRQOR/rVO2H BYokJHtZiApK2x+xKKhRS1c=
X-Google-Smtp-Source: AG47ELsv/0TWQHomn2FJ9iBb+TtUiKL9xyS1AzjZdnDSX1YchLBfWrw4KOlXI3coo2kgwI3uRZwGeQ==
X-Received: by with SMTP id f6mr2055081pgu.178.1521221917233; Fri, 16 Mar 2018 10:38:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id f23sm15558435pfn.132.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 10:38:36 -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 10:38:33 -0700
Cc: Florin Coras <>, "Alberto Rodriguez Natal (natal)" <>, "" <>, "" <>
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 17:38:39 -0000

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