Subject: [lisp] LISP for ILA

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Sun, 4 Mar 2018 06:39:03 +0000

Hi all,

We have just posted a draft describing how to use the LISP control-plane with the ILA data-plane. The document is in an early stage and any feedback is welcome. We hope to be presenting this at London.

https://tools.ietf.org/html/draft-rodrigueznatal-ila-lisp-00

Thanks,
Alberto

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Mar 2018 16:42:11 -0800

Thanks for posting the draft!

Overall, I think the approach straightforward, and it's very nice that
there is no change required to the ILA architecture.

I have some concerns about the LISP control plane in terms of
DOSability and scalability. Btw, LISP is not in Linux kernel because
of concerns about DOSability, so there was some prior discussion on
this topic in related mailing lists,

>From the draft: "When an ILA-N has to send traffic towards a remote
Identifier for which it does not have the associated Locator, it has
to obtain it first from a MS."

This is not actually true. The forwarding cache in the ILA-N is a
routing optimization, if there is no entry on the cache then the
packet is forwarded. If it needs to be transformed then that will be
done by an ILA-R in the path. Until the cache is populated the routing
might be sub-optimal but packets still flow.

This is reflected below in: "While the mapping is being resolved via
the Map-Request/  Map-Reply process, the ILA-N can send the data
packets to the underlay using the SIR address."

I think it should be assumed in ILA that not queuing packets and not
dropping packets because of resolution are requirements (too much
latency hit).

If the map request is sent and the packet is forwarded, that means
that a packet received at the ILA-N can generate two packets to be
forwarded in the network. An obvious DOS attack is for a host to send
random to destinations in the network to try to generate cache misses.
Section 8.2 discusses this, but the solution to implement heavy
hitters counters is not detailed. It would be nice to see more detail
how this would work and how it will mitigate the DOS attack.

In ILAMP, a redirect method is defined. On a chache miss the packet is
forwarded and no other action is taken. If an ILA-R does
transformation it may send back a mapping redirect informing the ILA-N
of a transformation. The redirects must be completely secure (one
reason I'm partial to TCP) and are only sent to inform an ILA-N about
a positive response. To a large extent this neutralizes the above
random address DOS attack. There are other means of attack on the
cache, but the exposure is narrowed I believe.

"LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP
transport, however the exact same signaling can be used over a TCP
transport without affecting the protocol operation."

What is the status of TCP support? I believe the trend in datacenter
control protocols is towards TCP and even RPC. Integrated security,
congestion control, authentication, and tooling are strong points in
favor of TCP. Is it reasonable to say that TCP is the preferred
protocol? Can the LISP message easily be converted to RPC (REST,
Thrift, GRPC, ...?

Looking at the map-reply message format, I am concerned about its
size. By my count, it's 40 bytes to provide one record with one
locator where record and locator are 8 bytes. If we need to scale a
system to billions of nodes this overhead could be an issue even if
it's the control plane. Is there any plan to have a compressed version
of this. For instance ,if there is only one RLOC returned wouldn't the
priorities and weights be useless?

Thanks,
Tom

On Sat, Mar 3, 2018 at 10:39 PM, Alberto Rodriguez Natal (natal)
<[email-masked]> wrote:
> Hi all,
>
>
>
> We have just posted a draft describing how to use the LISP control-plane
> with the ILA data-plane. The document is in an early stage and any feedback
> is welcome. We hope to be presenting this at London.
>
>
>
> _______________________________________________
> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Mar 2018 17:00:03 -0800

> priorities and weights be useless?

My comment about this spec is that you really don’t need a LCAF format to format the addresses. You can use AFI=2 and use IPv6 format. That will reduce the size.

But if you start compressing out fields, reality will set in and new features will be added and you’ll be back where we started. You want to multi-home, don’t you?

Dino

---

From: Tom Herbert <[email-masked]>
Date: Mon, 5 Mar 2018 18:23:58 -0800

> But if you start compressing out fields, reality will set in and new features will be added and you’ll be back where we started. You want to multi-home, don’t you?

There are a bunch of reserved and unused flag bits in the message
format. One could define flag-fields to make the messages extensible
and variable length (without resorting to TLVs!).

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 5 Mar 2018 18:33:48 -0800

The cost per EID-record is 12 bytes plus size of the EID address and for an RLOC-record is 12 bytes plus size of the RLOC address. This assumes you use AFI=2. Not what the draft is proposing.

Dino

#  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
#  |                          Record  TTL                          |            
#  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
#  | Locator Count | EID mask-len  | ACT |A|I|     Reserved        |            
#  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
#  |SigCnt |   Map Version Number  |            EID-AFI            |            
#  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            
#  |                          EID-prefix ...                       |            
#  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          

#    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
#   /|    Priority   |    Weight     |  M Priority   |   M Weight    |          
#  L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
#  o |        Unused Flags     |L|p|R|           Loc-AFI             |          
#  c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
#   \|                             Locator                           |          
#    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       

> On Mar 5, 2018, at 6:23 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 6 Mar 2018 18:36:23 +0000

Instead of LISP control plane, consider using IPv6 Neighbor Discovery (IPv6ND)
messaging for the control plane. RS/RA/NS/NA over tunnels is all the control
plane messaging that would be needed. IPv6ND is the control plane used by
the AERO proposal:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred

From: lisp [mailto:[email-masked]] On Behalf Of Alberto Rodriguez Natal (natal)
Sent: Saturday, March 03, 2018 10:39 PM
To: [email-masked]; [email-masked]
Subject: [lisp] LISP for ILA

Hi all,

Thanks,
Alberto

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Tue, 13 Mar 2018 19:28:58 +0000

Hi Tom,

Apologies for the delayed response. Thanks for your time reading the draft and for the feedback. See some comments inline.

On 3/5/18, 4:42 PM, "Tom Herbert" <[email-masked]> wrote:

    

    
As you point below, we're not saying otherwise in the draft. Sending the traffic to an ILA-R while the mapping is being retrieved is certainly an option. We'll update the text to be clearer on this.

IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping resolution has another set of tradeoffs to be considered. An operator should be able to decide which set of tradeoffs makes sense for his/her particular scenario.

Heavy hitters counters are a well-known technique to mitigate DOS attacks in the data-plane (used not only in LISP). There are several papers on that in the literature, see [1] for a recent example. Regarding LISP in particular, you can find some research on the modeling of the LISP map-cache in [2][3]. Following that work, we did some designs on how to apply heavy hitters counters to the LISP map-cache back in the day. We'll try to make that research also available. 

That model is supported in LISP via the use of Map-Notifies. However, moving the mapping resolution to the ILA-R comes at a cost. It's putting more load (in terms of both data and control plane) into an architectural component that it's not easy to scale out, since it requires (for instance) reconfiguring the underlay topology. 

    
LISP can run as it is over TCP. It can also be extended with the mechanisms described in [4] when a reliable transport is in place. If TCP makes more sense for your particular scenario, then you can make it your preferred transport. In general, which transport to use will depend on the characteristics of each individual deployment. On you last point, please note that OpenDaylight already supports LISP over REST [5].

One thing that we can (and should) discuss is the best way to encode ILA Identifier/Locators into LISP messages. Regarding removing fields from the Map-Reply, I'm unsure that the cost of reducing protocol functionality, increasing signaling machinery and adding parsing complexity is worth saving a few bits. Specially if you are planning to later use an RPC version of the protocol.

Thanks again for your comments Tom. This is an interesting discussion :)

Best,
Alberto

[1] https://arxiv.org/pdf/1611.04825.pdf
[2] https://arxiv.org/pdf/1312.1378.pdf
[3] http://personals.ac.upc.edu/fcoras/publications/2015-fcoras-scalability.pdf
[4] https://tools.ietf.org/html/draft-kouvelas-lisp-map-server-reliable-transport-04
[5] https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Architecture

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Tue, 13 Mar 2018 19:37:22 +0000

Dino,

On 3/5/18, 5:00 PM, "Dino Farinacci" <[email-masked]> wrote:

Using IPv6 format is something we considered while writing the draft. We went the LCAF route to have an explicit way to (1) distinguish ILA Identifiers/Locators from other addresses in the Mapping System, (2) specify the Identifier/Locator length and (3) include metadata bits. However, for simple scenarios (only ILA domain, no overlapping with non-local addresses, no multiple SIR prefixes, fixed Identifier length, no need for metadata bits, etc) things could work with AFI=2 format. If the rough consensus from the WG(s) is that a plain AFI=2 format is sufficient, we can certainly update the draft. I would like to know the opinion of others on this. 

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 13 Mar 2018 12:56:43 -0700

> Using IPv6 format is something we considered while writing the draft. We went the LCAF route to have an explicit way to (1) distinguish ILA Identifiers/Locators from other addresses in the Mapping…

Well identifiers can be encoded as ::<64-bits> and locators can be encoded as a regular prefix (leading bits and mask-length).

I have been running with some ILA addresses in my mapping system for a while now. I wanted to show Tom that it could be done easily. What I did was register a 128-bit EID which was the SIR-prefix plus identifier which mapped to a 128-bit RLOC that contained high-order bits as the routable locator and low-order bits as the identifier. I realize this is a bit redundant, but it could be done with no protocol or implementation changes.

Anyways,
Dino

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Mar 2018 13:05:47 -0700

> IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping resolution has another set of tradeoffs to be considered. An operator should be able to decide which set of tradeoffs make…
This is a hard requirement because caches are explicitly not required
for ILA to operate. They are *only* optimizations. If there is a cache
hit then packets presumably get optimized path, on a cache miss they
might take a subopitimal route-- but packets still flow without being
blocked! This means that the worse case DOS attack on the cache might
cause suboptimal routing; however, if resolution is required then the
worse attack case becomes that packets don't flow and it's a much more
effective attack.

> Heavy hitters counters are a well-known technique to mitigate DOS attacks in the data-plane (used not only in LISP). There are several papers on that in the literature, see [1] for a recent example…

As they say, the devil is in the details... :-)

> That model is supported in LISP via the use of Map-Notifies. However, moving the mapping resolution to the ILA-R comes at a cost. It's putting more load (in terms of both data and control plane) in…

I'm not see how this creates more load (i.e. the need for map request
packets are eliminated), but I really don't understand what
"reconfiguring the underlay topology" means!

Tom

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Tue, 13 Mar 2018 20:53:29 +0000

There is another option that we discussed when we were considering IPv6 encoding. Instead of being redundant with the low-order bits of the Locator, you could use those to encode a "special identifier" that you will use when sending control-plane messages to that Locator. This way, the ILA device at that Locator has a clear way to punt packets to control-plane processing.

Alberto

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Tue, 13 Mar 2018 22:50:38 +0000

Performing the mapping resolution at the ILA-N doesn't mean that you can't send the packets to the ILA-R to avoid the first-packet-drop. Those are two different things. Traditionally in LISP, a possible deployment model is to have a couple of RTRs with all the mappings in the site, so xTRs can use them as default path while they are resolving mappings. In this scenario, all the mapping resolution is done at the xTRs while the RTRs are only forwarding "first-packets". We have seen this model working really well even for large LISP deployments. 

    
Happy to try to clarify this. I'm talking about the load in the ILA-R. With a "redirect" model, the ILA-R has to (1) serve as the data-plane default path and (2) provide control-plane mapping resolution. This is centralizing the data-plane and control-plane into a single component, the ILA-R. Moreover, this will also require a lot of punts from the fast path to the slow path in the ILA-R which has also implications. With a request/reply model, the control-plane resolution is performed at the edges in a distributed fashion and the ILA-R only serves as data-plane default path to avoid dropping traffic. The latter model alleviates the load in the ILA-Rs, which reduces the need to scale them out.

One of the challenges associated with scaling out the ILA-Rs is that is based on sharding the Identifier space. This requires making the underlay aware of this sharding (so the SIR traffic is properly routed to the appropriate ILA-R). This is basically coupling the underlay and overlay rather than keep them separated. In LISP when you need to add a new Map-Server you just need to update (some) of the overlay components, the underlay is completely unaware of this change (which is probably a good thing).

Hope the above helps to clarify things. As you know, I'm not directly against a "redirect" model (which can also be done with LISP), but we need to be aware of the tradeoffs that we are choosing.

Alberto

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Mar 2018 16:27:06 -0700

> Happy to try to clarify this. I'm talking about the load in the ILA-R. With a "redirect" model, the ILA-R has to (1) serve as the data-plane default path and (2) provide control-plane mapping resol…
Yes, but you are ignoring the load on the mapping servers which also
needs to scale. Additionally, if ILA-N is both forwarding a packet and
sending a map request then this potentially doubles the packet load on
the network and exacerbates the potential DOS attack where someone
floods an ILA-N with packets having bogus destinations. There might be
mitigations to this DOS attack, like heavy-hitters you mentioned, but
we really need the details to see exactly how this works and how
effective they are. On the surface of it, it looks like
request/response model is susceptible to DOS especially when third
parties are allowed to drive the process.

Tom

---

From: "Alberto Rodriguez Natal (natal)" <[email-masked]>
Date: Wed, 14 Mar 2018 00:38:28 +0000

On 3/13/18, 4:27 PM, "Tom Herbert" <[email-masked]> wrote:

    needs to scale. 

I completely agree that the Mapping System needs to scale. The LISP community has extensively explored that over the years and has come up with several solutions. Another reason to let the data-plane and control-plane scale independently :)

Alberto

---

From: Florin Coras <[email-masked]>
Date: Tue, 13 Mar 2018 18:37:33 -0700

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 triggered by edge devices ITR/ILA-N. 

This then means that just rate limiting ITRs should be enough to avoid DOS-ing the control plane and the problem converts into one of trying to avoid providing sub-optimal paths to legitimate traffic due to attacker pressure. As Alberto mentioned, there are a number of solutions to determining both the attackers and the destinations set that should be protected against cache evictions. The former can be used to determine the set of requests that should not be punted, while the latter ensures that mappings for popular destinations cannot be evicted by attacks. 

Florin

> On Mar 13, 2018, at 4:27 PM, Tom Herbert <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
> lisp mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Mar 2018 22:25:19 -0700

On Tue, Mar 13, 2018 at 6:37 PM, Florin Coras <[email-masked]> 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 triggered by edge devices ITR/ILA-N.
>
ILA-Rs contain the all the mappings for the shard the service. If they
don't have a mapping for a packet, then the packet is dropped.

> This then means that just rate limiting ITRs should be enough to avoid
> DOS-ing the control plane and the problem converts into one of trying to
> avoid providing sub-optimal paths to legitimate traffic due to attacker
> pressure. As Alberto mentioned, there are a number of solutions to
> determining both the attackers and the destinations set that should be
> protected against cache evictions. The former can be used to determine the
> set of requests that should not be punted, while the latter ensures that
> mappings for popular destinations cannot be evicted by attacks.
>
Okay, but I still don't know where the details and analysis of these
solutions are. It's not enough to simply say that rate limiting is the
solution to the DOS threat. I looked at RFC7835, for instance, which
gives a nice analysis of the threat, but the suggested mitigations are
"careful deployment and configuration" and "Systematically applying
filters and rate limitation"-- that guidance is not particularly
enlightening or convincing. I am really hoping we can get something
more concrete for dealing with DOS threats in a control plane for ILA.

Thanks,
Tom

> IMHO, these should not be hard requirements. Leveraging ILA-Rs for mapping
> resolution has another set of tradeoffs to be considered. An operator should
> be able to decide which set of tradeoffs makes sense for his/her particular
> scenario.
>
> Performing the mapping resolution at the ILA-N doesn't mean that you can't
> send the packets to the ILA-R to avoid the first-packet-drop. Those are two
> different things. Traditionally in LISP, a possible deployment model is to
> have a couple of RTRs with all the mappings in the site, so xTRs can use
> them as default path while they are resolving mappings. In this scenario,
> all the mapping resolution is done at the xTRs while the RTRs are only
> forwarding "first-packets". We have seen this model working really well even
> for large LISP deployments.
>
> That model is supported in LISP via the use of Map-Notifies. However, moving
> the mapping resolution to the ILA-R comes at a cost. It's putting more load
> (in terms of both data and control plane) into an architectural component
> that it's not easy to scale out, since it requires (for instance)
> reconfiguring the underlay topology.
>
>
> Happy to try to clarify this. I'm talking about the load in the ILA-R. With
> a "redirect" model, the ILA-R has to (1) serve as the data-plane default
> path and (2) provide control-plane mapping resolution. This is centralizing
> the data-plane and control-plane into a single component, the ILA-R.
> Moreover, this will also require a lot of punts from the fast path to the
> slow path in the ILA-R which has also implications. With a request/reply
> model, the control-plane resolution is performed at the edges in a
> distributed fashion and the ILA-R only serves as data-plane default path to
> avoid dropping traffic. The latter model alleviates the load in the ILA-Rs,
> which reduces the need to scale them out.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: Richard Li <[email-masked]>
Date: Wed, 14 Mar 2018 05:46:29 +0000

》 enlightening or convincing. I am really hoping we can get something
》more concrete for dealing with DOS threats in a control plane for ILA.

Isn’t DOS a data plane problem?

Richard

From: Tom Herbert
To: Florin Coras;
Cc: [email-masked]; [email-masked];
Subject: Re: [lisp] [Ila] LISP for ILA
Time: 2018-03-13 22:25:44

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 13 Mar 2018 23:06:07 -0700

> Isn’t DOS a data plane problem?
Richard,

The potential attack is on the mapping cache that needs to be
maintained by the control plane. It's really the cache that is being
attacked via that packets sent by an attacker. The goal of the
attacker is something like exhausting the cache or other resources
such that legitimate traffic is blocked or severely degraded. The
recent Meltdown and Spectre exploits on CPU caches are a good reminder
of how generally how hard it is to make caches resilient to attack and
how the problem is never completely solved!

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 08:29:24 -0700

> mappings for popular destinations cannot be evicted by attacks.
Florin,

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.

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 10:38:33 -0700

> algorithm that is able separate the bad packets from the good packets

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.

Comments?

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 10:58:42 -0700

Dino,

I'm pretty confused by who "I" is, who "you" is, as well as what
constitutes "too often" or "too many requests". Is there a normative
descirption of this algorithm we can look at?

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 11:08:40 -0700

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.

Dino 

> On Mar 16, 2018, at 10:58 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 11:23:20 -0700

Dino,

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.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 11:41:41 -0700

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

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

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

> flow is blocked from making progress, then it would seen the DOS

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.

Dino

---

From: Paul Vinciguerra <[email-masked]>
Date: Fri, 16 Mar 2018 18:55:03 +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? 

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

Yep, that’s right.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 12:10:41 -0700

Dino,

Such complexity is why I am still keen on the redirect model for a
mapping system. An ILA cache is an optional element and the control
plane is never inline with packet forwarding and packets are not
dropped on a cache miss. Neither does the generate request packets for
bogus addresses that can't resolved. These properties bound the worse
case DOS attack to be that legitimate traffic takes an unoptimized
route but is not blocked nor dropped. Conservatively, this does
require provisioning ILA-Rs to handle the full load if necessary to be
robust.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 12:11:27 -0700

> 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 sou…

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

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 12:17:46 -0700

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

> dropped on a cache miss. Neither does the generate request packets for

We did that in the ITR as well. A cache missed meant to send a Map-Request and to encapsulate the packet to a PETR (proxy decapsulator) where the PETR usually had a full cache (how it got populated could be with pull or push mechanisms).

But this results in duplicate packets going to the destination as well as out of order packets.

> route but is not blocked nor dropped. Conservatively, this does

Yes, understand. But even in your constrained “domain”, there may be just too much state to push to all nodes. Especially in the 5G use-case. It wasn’t a problem in the LISP beta network because the proxy xTRs had relatively coarse prefixes that reached lots of EIDs.

> require provisioning ILA-Rs to handle the full load if necessary to be

Yes indeed.

Dino

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 16 Mar 2018 19:18:44 +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 [mailto:[email-masked]] On Behalf Of Paul Vinciguerra
Sent: Friday, March 16, 2018 11:55 AM
To: Dino Farinacci <[email-masked]>; Tom Herbert <[email-masked]>
Cc: David Meyer <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Ila] [lisp] LISP for ILA

Paul

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

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

> trying to prevent this determination. AFAIK this is a generally

Yep, that's right.

> flow is blocked from making progress, then it would seen the DOS 

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.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 12:33:35 -0700

> Yes, understand. But even in your constrained “domain”, there may be just too much state to push to all nodes. Especially in the 5G use-case. It wasn’t a problem in the LISP beta network because th…
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.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 13:10:19 -0700

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 13:11:07 -0700

> for which using a cache would be challenging.

What LISP-DDT suggests and specs.

Dino

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 16 Mar 2018 20:36:38 +0000

-----Original Message-----
            From: ila [mailto:[email-masked]] On Behalf Of Dino Farinacci
            Sent: Friday, March 16, 2018 1:10 PM
            To: Uma Chunduri <[email-masked]>
            Cc: David Meyer <[email-masked]>; [email-masked]; Tom Herbert <[email-masked]>; [email-masked]; Paul Vinciguerra <[email-masked]>
            Subject: Re: [Ila] [lisp] LISP for ILA

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

You can easily secure (origin auth, integrity protection, encryption, protection from reply attacks etc) all on the wire stuff with matured protocols from outside observers/from intermediate nodes in the network.

This is obviously not true w.r.t keeping the secured data anonymously. Remember the argument, how your provider itself is compromised (all bets are off)??

A great reference to the privacy topic to me though: https://tools.ietf.org/html/rfc6973

--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 16 Mar 2018 13:49:54 -0700

On Fri, Mar 16, 2018 at 1:36 PM, Uma Chunduri <[email-masked]> wrote:
> Cc: David Meyer <[email-masked]>; [email-masked]; Tom Herbert
> <[email-masked]>; [email-masked]; Paul Vinciguerra
> <[email-masked]>
> You can easily secure (origin auth, integrity protection, encryption,
> protection from reply attacks etc) all on the wire stuff with matured
> protocols from outside observers/from intermediate nodes in the network.
>
I can buy that, but then would wonder why you think Scalability is
easy :-) We're anticipating systems with many billions of mappings and
potentially high rates of change. No doubt were in the realm of some
seriously distributed databases!

Tom

> This is obviously not true w.r.t keeping the secured data anonymously.
> Remember the argument, how your provider itself is compromised (all bets are
> off)??
>

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 16 Mar 2018 20:56:24 +0000

Tom, 

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Friday, March 16, 2018 1:50 PM
To: Uma Chunduri <[email-masked]>
Cc: David Meyer <[email-masked]>; [email-masked]; [email-masked]; Dino Farinacci <[email-masked]>; Paul Vinciguerra <[email-masked]>
Subject: Re: [Ila] [lisp] LISP for ILA

> protocols from outside observers/from intermediate nodes in the network.
I can buy that, but then would wonder why you think Scalability is easy :-) 

[Uma]: I never said it's easy. But we have references on how to do this from long time research to deployed massively scalable systems (maturity in both aspects).

We're anticipating systems with many billions of mappings and potentially high rates of change. No doubt were in the realm of some seriously distributed databases!
[Uma]: Perhaps..

Tom

> Remember the argument, how your provider itself is compromised (all 
> bets are off)??
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 16 Mar 2018 17:53:00 -0400

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 be an issue.

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.

Yours,
Joel

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 16 Mar 2018 15:14:55 -0700

On Fri, Mar 16, 2018 at 2:53 PM, Joel M. Halpern <[email-masked]> wrote:
> issues.  Separating control load from data plane load is also a useful way
> to help keep things manageable.

Couldn't agree more.

Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Mar 2018 17:44:34 -0700

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 <[email-masked]> wrote:
> 
> 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 be an issue.
> 
> 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.
> 
> Yours,
> Joel
>

---

From: "jmh.direct" <[email-masked]>
Date: Fri, 16 Mar 2018 21:41:01 -0400

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, an AT&T 4G LTE smartphone
-------- Original message --------From: Dino Farinacci <[email-masked]> Date: 3/16/18  20:44  (GMT-05:00) To: "Joel M. Halpern" <[email-masked]> Cc: Tom Herbert <[email-masked]>, David Meyer <[email-masked]>, "Alberto Rodriguez Natal (natal)" <[email-masked]>, Florin Coras <[email-masked]>, [email-masked], [email-masked], Eliot Lear <[email-masked]> Subject: Re: [Ila] [lisp] LISP for ILA - scaling 
Copying Eliot.

Dino