Hi all,
In the DMM call this week, some people asked about the scalability of the
Mapping System. The LISP community has delivered different solutions to
address that challenge over the years. Here are some pointers to different
Mapping System implementations, I'm sure that the folks at the LISP W
Am 16.03.2018 um 09:19 schrieb Alberto Rodriguez-Natal:
> Hi all,
>
> In the DMM call this week, some people asked about the scalability of
> the Mapping System. The LISP community has delivered different solutions
> to address that challenge over the years. Here are some pointers to
> different
To all presenters of the meeting,
Can you please send us the slides by Sunday evening at latest?
This will give the chairs the time to upload them in time for our meeting
Monday afternoon.
Have a safe trip to London.
ciao
Luigi
___
lisp mailing list
On Tue, Mar 13, 2018 at 6:37 PM, Florin Coras wrote:
> Not sure about ILA-R but typically when deploying LISP, RTR/Proxy-ITRs have
> enough memory to store most, if not all, of the identity to location
> mappings. Therefore, once in steady state, most of the requests to the
> mapping system are tr
> 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
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 separat
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 M
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
> oth
> 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
sourc
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 L
> 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
On Fri, Mar 16, 2018 at 11:41 AM, Dino Farinacci wrote:
>> 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 d
> Such complexity is why I am still keen on the redirect model for a
I hear you loud and clear. But we do the redirect model in LISP in many forms
as well.
> mapping system. An ILA cache is an optional element and the control
> plane is never inline with packet forwarding and packets are not
> d
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
On Fri, Mar 16, 2018 at 12:17 PM, Dino Farinacci wrote:
>> Such complexity is why I am still keen on the redirect model for a
>
> I hear you loud and clear. But we do the redirect model in LISP in many forms
> as well.
>
>> mapping system. An ILA cache is an optional element and the control
>> pl
> 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).
Was there a reason you singled out privacy and just didn’t include it under
security?
Dino
> The state would need to be sharded. You'd probably need to do this
> anyway for mapping-servers or high thoughput Internet facing routers
> for which using a cache would be challenging.
What LISP-DDT suggests and specs.
Dino
___
lisp mailing list
lis
-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Friday, March 16, 2018 1:10 PM
To: Uma Chunduri
Cc: David Meyer ; i...@ietf.org; Tom Herbert
; lisp@ietf.org; Paul Vinciguerra
On Fri, Mar 16, 2018 at 1:36 PM, Uma Chunduri wrote:
>
>
>
> -Original Message-
> From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Friday, March 16, 2018 1:10 PM
> To: Uma Chunduri
> Cc: David Meyer ; i...@ietf.org; Tom Herbert
> ; lisp@ietf.org; Paul Vinciguerr
Tom,
In-line [Uma]:
--
Uma C.
-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Friday, March 16, 2018 1:50 PM
To: Uma Chunduri
Cc: David Meyer ; i...@ietf.org; lisp@ietf.org; Dino Farinacci
; Paul Vinciguerra
Subject: Re: [Ila] [lisp] LISP fo
From the analysis Eliot did many years ago for a LISP push solution,
for any constrained solution (a data center, a mobile operator, a fixed
service operator) the number of entries is probably not a problem. Even
for a conventional router. Churn rate, in its various manifestations,
could well
On Fri, Mar 16, 2018 at 2:53 PM, Joel M. Halpern wrote:
>
> Sharding is but one of several ways to divide and conquer to avoid those
> issues. Separating control load from data plane load is also a useful way
> to help keep things manageable.
Couldn't agree more.
Alberto
__
Copying Eliot.
I don’t remember Eliot analyzing the data-plane. But he did see how far the
mapping database could scale with push and don’t recall he saying 1 billion
would be achievable either.
Dino
> On Mar 16, 2018, at 2:53 PM, Joel M. Halpern wrote:
>
> From the analysis Eliot did many y
His analysis of the control push size did not go to 1 billion. That is why I
stated that for any constrained environment push would work. I do not know of
a use case for 1 billion entities in those constraints.Internet-scale is a
different problem.
Yours,Joel
Sent via the Samsung Galaxy S® 6
24 matches
Mail list logo
