Re: [lisp] [Ila] LISP for ILA

Uma Chunduri <> Fri, 16 March 2018 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 686241252BA; Fri, 16 Mar 2018 12:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wjquowHxllfY; Fri, 16 Mar 2018 12:18:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57BEF129515; Fri, 16 Mar 2018 12:18:50 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id BE86CAA2B9FB9; Fri, 16 Mar 2018 19:18:45 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.382.0; Fri, 16 Mar 2018 19:18:47 +0000
Received: from ([]) by ([]) with mapi id 14.03.0382.000; Fri, 16 Mar 2018 12:18:44 -0700
From: Uma Chunduri <>
To: Paul Vinciguerra <>, Dino Farinacci <>, Tom Herbert <>
CC: David Meyer <>, "" <>, "" <>
Thread-Topic: [Ila] [lisp] LISP for ILA
Thread-Index: AQHTvVhWEFyKOcHLDE2x54v999WwnaPTN8zg
Date: Fri, 16 Mar 2018 19:18:44 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>, <> <B5A8E79CDD2131468993EFC2426361DD9FB450C3@NYDC-EXCH01.vinci-consulting-corp.local>
In-Reply-To: <B5A8E79CDD2131468993EFC2426361DD9FB450C3@NYDC-EXCH01.vinci-consulting-corp.local>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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:18:52 -0000

Definitely helps from a regular adversary. But unfortunately by definition, adversary is intelligent and sophisticated for all practical purposes.

I agree with discussion below - dos attacks are effectively mitigated by all major cloud providers from outside view (though it's a constant struggle who is securing the same from inside). 
So there are references on how to deploy this. 

I see 4 pillars for any mapping system

A. Scalability
B. Security
C. Privacy
D.  Dos/DDOS Prevention

While one can relatively handle #A and #B 
IMO - #C* and #D are still the hardest problems (despite all the research).

Uma C.

*regardless of blockchain/federated stuff is on the raise, w.r.t overall complexity, cost effectiveness and manageability 

-----Original Message-----
From: ila [] On Behalf Of Paul Vinciguerra
Sent: Friday, March 16, 2018 11:55 AM
To: Dino Farinacci <>; Tom Herbert <>
Cc: David Meyer <>;;
Subject: Re: [Ila] [lisp] LISP for ILA

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? 

From: lisp [] on behalf of Dino Farinacci []
Sent: Friday, March 16, 2018 2:41 PM
To: Tom Herbert
Cc: David Meyer;;
Subject: Re: [lisp] [Ila]  LISP for ILA

> Detecting that something is under DOS attack is not problem. It's

I do think it is a problem. Because you can't tell sometimes if it is a high-rate due to high demand from good actors. From the mapping system's perspective, you don't know the traffic patterns so you don't know that if a source-EID wants to talk to 100 EIDs if that is a good actor or a bad actor. If that source-EID is my phone, then it may be suspect, but if it's a Google server talking to 100 phones, that is pretty normal.

> 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

Right, at cisco, we called that "the needle in the haystack problem". And it comes up when we talk about topics of "punt path" in routers and DoS attacks.

> legitimate. Again this is not easy because the attacker is purposely 
> trying to prevent this determination. AFAIK this is a generally

Yep, that's right.

> unsolved problem and probably impossible to fully solve. So if the

Agree. We should look at the honey-pot solutions that DNS has used. But its a different animal though than packet attacks.

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

That isn't what would happen with the frequency-hopping idea. If the map-resolver is aggressive in dropping and it drops the needles, those ITRs have a back-up or parallel plan to get their requests resolved from other map-resolvers in the mapping system. Be them part of an anycast group or not.


lisp mailing list

ila mailing list