Re: [lisp] [Ila] LISP for ILA

Dino Farinacci <> Fri, 16 March 2018 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D2EC1252BA; Fri, 16 Mar 2018 12:11:31 -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 7ZeJktdfZfMi; Fri, 16 Mar 2018 12:11:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14690120727; Fri, 16 Mar 2018 12:11:30 -0700 (PDT)
Received: by with SMTP id q13so4520235pff.0; Fri, 16 Mar 2018 12:11:30 -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=CzQNdzDt+FioqUuNtzCsI+UGhrIwVA9acCMf0q994cs=; b=JUAcdGWY2Z8WxNJ6a894PdroLDMOst9PRiremoX5oBE2vYhPLGFBw6wLxxk7FbGNGv i4VywEQsoi7XxO1e+bF8N6qzabc1iQbM4OZM3YPlG4PP6t2/0Jw61N9jJdRSYPb2BQxO zRLPQQH1CR5p+Z+CCYtfK2lBnZVAfY32ZAUdeGZ9B+5y/sE6HHG1+VSgLW4aVgc29+W4 GcPQDPUwpwfYjV2pSATz/KFZGcwUDnlt5zmvrfu0br8CMY+ajDC5THOLMl52d8Sd2dGt 4N0Irkp8aMaf0dUZz5tVVqeJlzm6wz8gdq+iFvwWnzwEzfc7V/huCNCYNz++EL/mp6dH 2+yA==
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=CzQNdzDt+FioqUuNtzCsI+UGhrIwVA9acCMf0q994cs=; b=DuTsdwTcvTIZ2Smsw/SnimqFKtjPKzTI+gxEfemSHxHp8EcD9NDEeCDy1FXoY3FCGq 4Fpobqy/f379cuRBFatCoEDDa2F54jeTVQ2qVNHrWKLAC+k286j8JJ3H1p7eAvq0fN8h eDx58Y7zl7wAW5azznvPbQ/bqaj5GFHwJwjmWgneph/L+El7xEcSLm8tADKVXVpI68ZT O2pX4jw1ZbEe9XyS0tCFJNDAXzroPy/EOBXHRuK56V/TqHy7P4eIHOGBgHZg7SsqW7Ba pP4KQYTP4aAJJyODnXBI4okSG5SqNqrKj7sMws30X88smY6Y/7GRsigKfB9LZKhee+sh 91AQ==
X-Gm-Message-State: AElRT7F1LQ1fp39gAu7IYPki0IbDXYGAdKeNrcMplShMyve21j3R/fn8 /VD6UX5VRVSz6C5ieooB7vY=
X-Google-Smtp-Source: AG47ELsmulqe7M3wUjjY62ELu3wzNucFZbTni94qjGeIVYtRV2DUgds7Pctc/uQziyaY80pTu5qLNA==
X-Received: by with SMTP id g2mr2307674pgp.425.1521227489654; Fri, 16 Mar 2018 12:11:29 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a65sm9217900pfg.170.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 12:11:29 -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: <B5A8E79CDD2131468993EFC2426361DD9FB450C3@NYDC-EXCH01.vinci-consulting-corp.local>
Date: Fri, 16 Mar 2018 12:11:27 -0700
Cc: Tom Herbert <>, David Meyer <>, "" <>, "" <>, Dino Farinacci <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <B5A8E79CDD2131468993EFC2426361DD9FB450C3@NYDC-EXCH01.vinci-consulting-corp.local>
To: Paul Vinciguerra <>
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 19:11:31 -0000

> Would it be practical to have the map server, having detected an attack, simply send a cookie back in its reply to the spoofed address and then stop replying for a period of time to the spoofed source address unless subsequent requests from that source address contained the cookie in an opaque LCAF or some other LCAF type? 

Thanks for the comment Paul. A couple points/comments here:

(1) I would hope that the Map-Request doesn’t go all the way to the Map-Server. That is the first time a Map-Request hits the mapping system is at the Map-Resolver node. We probably should put logic there on what is sent along the DDT route or how much is sent to the Map-Server if the Map-Resolver has the EID in the referral-cache. This is just a side comment.

(2) If the Map-Request is being spoofed, it isn’t a problem. When I say spoofed, I mean if the source address in the IP header is spoofed. It turns out the “ITR-RLOC” field in the Map-Request is where the Map-Reply goes to. But it depends what the bad actor looks like. If its a mis-configured spec-compliant xTR, then this could work. If this is a python hacker, it won’t do anything with the responses. Because its sole point is to disrupt the mapping system.

But this reminds me of a funny story a friend told me about 10 years ago when he was sick and tired of receiving physical junk mail at his house. What he did was collect all the junk mail, put it in one big envelope and put his address as the destination and put the source of the junk mail as the sender field. He then went to the post office and dropped it in the bin WITHOUT a stamp. So the heavy package was returned to sender. LOL.  ;-)

So maybe this story could be a solution to the problem. Why don’t we DoS attack the bad actor. Kill its bandwidth and CPU so it can’t attack us?  ;-) Of course the Map-Resolver would have to detect the situation, create a VM to be the attacker and launch it.  ;-)

I don’t know if I’m joking or serious about this. But the cloud providers would love this.  ;-)