Subject: [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Fri, 28 Oct 2016 23:39:52 +0000

The recent Denial-of-service attacks is a scenario we should have in mind when building robustness in the network mapping system.
In draft-padma-ideas-problem-statement-00.txt, there is a section on mapping system security requirements that specifically cover 
this case.

One of the questions that comes to mind is whether the robustness of such a mapping system should drop/throttle responses when it is 
Overloaded or should we expect it always to handle the load no matter what?
While we do propose to rate-limit the messages in the problem statement, isn't this playing into the hands of the attackers?

Requesting feedback from the list and ccing wg with expertise in the area or interest in mapping system technology.

Thanks in advance
Padma

Below an excerpt from the draft
6.4.  Mapping System Security

   The secure mapping system must have the following requirements:

   1.  The components of the mapping system need to be robust against
       direct and indirect attacks.  If any component is attacked, the
       rest of the system should act with integrity and scale and only
       the information associated with the compromised component is made
       unavailable.

   2.  The addition and removal of components of the mapping system must
       be performed in a secure matter so as to not violate the
       integrity and operation of the system and service it provides.

   3.  The information returned by components of the mapping system
       needs to be authenticated as to detect spoofing from
       masqueraders.

   4.  Information registered (by publishers) to the mapping system must
       be authenticated so the registering entity or the information is
       not spoofed.

   5.  The mapping system must allow request access (for subscribers) to
       be open and public.  However, it is optional to provide
       confidentiality and authentication of the requesters and the
       information they are requesting.

   6.  Any information provided by components of the mapping system must
       be cryptographically signed by the provider and verified by the
       consumer.

   7.  Message rate-limiting and other heuristics must be part of the
       foundational support of the mapping system to protect the system
       from invalid overloaded conditions.

   8.  The mapping system should support some form of provisioned
       policy.  Either internal to the system or via mechanisms for
       users of the system to describe policy rules.  Access control
       should not use traditional granular-based access lists since they
       do not scale and are hard to manage.  By the use of token- or
       key- based authentication methods as well as deploying multiple
       instances of the mapping system will allow acceptable policy
       profiles.  Machine learning techniques could automate these
       mechanisms.

-----Original Message-----
From: IETF-Announce [mailto:[email-masked]] On Behalf Of IETF Chair
Sent: Friday, October 28, 2016 9:21 AM
To: IETF Announcement List
Cc: [email-masked]
Subject: Technical plenary: Attacks against the architecture

The technical plenary in Seoul will be about the recent Denial-of-Service
attacks involving the use of compromised or misconfigured nodes or 
“things”, and the architectural issues associated with the network
being vulnerable to these attacks.

See

  https://www.ietf.org/blog/2016/10/attack-against-the-architecture/

and join us for the discussion on Wednesday 16:40-19:10, November 16,
2016 either in person or remotely. You can register for the meeting here: 

  https://www.ietf.org/meeting/97/index.html

Jari Arkko, IETF Chair

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Oct 2016 23:15:28 -0400

There are some preliminary thoughts on overload issues in the security 
considerations of draft-ietf-lisp-introduction.

I will also be curious to see what the presentations at the technical 
plenary in Seoul have to suggest on the issue, if anything.

There probably is more with considering.

Yours,
Joel

On 10/28/16 7:39 PM, Padmadevi Pillay Esnault wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 29 Oct 2016 08:40:36 -0700

Hi Joel

The security section has the following recommendations for overload issues
1. Rate limit the sending of messages to the mapping system.
2.To improve resiliency and reduce the overall number of messages
exchanged, LISP offers the possibility to leak information, such as reachabilty
of locators, directly into data plane packets
3. Using trustable Map-Servers that strictly respect [RFC6833] and the
lightweight authentication mechanism proposed byLISP-Sec
[I-D.ietf-lisp-sec] reduces the risk of attacks

Here are the potential problems I see with these
1. Rate limiting messages has the same result the DDOS attack was aiming at.
2. Leaking the information may have consequences for the privacy unless we
are using ephemeral EIDs
3. We can trick the system to legitimately make a lot of updates. For
example a large number of IDs distributed that keep on registering that
they have changed locations frequently and an equally large number of
devices trying to access them.

There has been a lot of digital ink about IoT devices being vulnerable to
be compromised and that the sheer number of devices (several billions) to
be the easy target for bonnets.  Discussions about use of rfc2728 or how
ISP could handle these attacks. It is a difficult problem to solve and in
the end we are pushing the responsibility to other entities to do the right
thing ...

In section 5 of draft-padma-ideas-problem-statement, there is a section in
the table which specifically discuss about the structure of IDs and whether
we should used them for specific classes or as the Network Mapping system
is proposing to attach metadata to ID.

I am inclined to think if we can give ID some inherent class which can
restrict what these devices can do. Why would a fridge ever try to access a
bank account unless something is seriously wrong? In the case of IoT, it
would have been possible to drop request from a camera or sensor requesting
to map netflix or twitter.

With IP addresses, it is difficult to differentiate who is what.
Structured IDs allocations or metadata in the NMS may be an opportunity to
simplify some of this operational complexity.

Thoughts?
Padma

On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern <[email-masked]>
wrote:

>> The recent Denial-of-service attacks is a scenario we should have in mind
>> when building robustness in the network mapping system.
>> In draft-padma-ideas-problem-statement-00.txt, there is a section on
>> mapping system security requirements that specifically cover
>> this case.
>>
>> One of the questions that comes to mind is whether the robustness of such
>> a mapping system should drop/throttle responses when it is
>> While we do propose to rate-limit the messages in the problem statement,
>> isn't this playing into the hands of the attackers?
>>
>> Requesting feedback from the list and ccing wg with expertise in the area
>> or interest in mapping system technology.
>>
>> Thanks in advance
>> Padma
>>
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 29 Oct 2016 12:03:13 -0400

Remember that with LISP, the mapping system is somewhat insulated due to 
the fact that queries are only accepted from MR, not directly from 
anything claiming to be an ITR.  And it is normally expected that the 
association between mapping system internals and MR/MS is authenticated 
(otherwise there are lots of other issues.)

This does not provide complete protection, as there are many situations 
where the MR does not have  an authentication relationship with the 
querying ITR.  Having said that, it can be noted that in many cases 
there is such a relationship.  Such a relationship prevents a random 
outside attack.

Even when there is no such relationship, and even if the MR does not 
rate limit, an effective DoS attack would have to target multiple MR to 
cause significant difficulty.

Also, it seems to me that if all you want to do is break a single MR, 
then rate limiting is irrelevant.  In the absence of limits on who can 
query a specific MR, you can bombard it with more queries than it can 
handle and you will take it out of service.  So a rate limit helps the 
system while harming the MR capability only slightly.

Trying to infer whether an entity is allowed to undertake specific 
operations without authentication, using information such as the IP 
address, seems fraught with failure.  Trying to classify all entities 
into types (onotology?) seems unlikely to produce correct results, as 
classes are not cleanly defined.

As I said, I look forward to the technical presentation at the IETF 
meeting to see if they have any ideas that can help.  Yes, there is work 
to be done.  Putting authorization into the identity seems to be asking 
for trouble.

Yours,
Joel

On 10/29/16 11:40 AM, Padma Pillay-Esnault wrote:
> 2.To improve resiliency and reduce the overall number of
> messagesexchanged, LISP offers the possibility to leak information, such
> as reachabilty of locators, directly into data plane packets
> 2. Leaking the information may have consequences for the privacy unless
> we are using ephemeral EIDs
> There has been a lot of digital ink about IoT devices being vulnerable
> to be compromised and that the sheer number of devices (several
> billions) to be the easy target for bonnets.  Discussions about use of
> rfc2728 or how ISP could handle these attacks. It is a difficult problem
> to solve and in the end we are pushing the responsibility to other
> entities to do the right thing ...
>
> In section 5 of draft-padma-ideas-problem-statement, there is a section
> in the table which specifically discuss about the structure of IDs and
> whether we should used them for specific classes or as the Network
> Mapping system is proposing to attach metadata to ID.
>
> restrict what these devices can do. Why would a fridge ever try to
> access a bank account unless something is seriously wrong? In the case
> of IoT, it would have been possible to drop request from a camera or
> sensor requesting to map netflix or twitter.
>
> Structured IDs allocations or metadata in the NMS may be an opportunity
> to simplify some of this operational complexity.
>
> Thoughts?
> Padma
>
>
>
> On Fri, Oct 28, 2016 at 8:15 PM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     There are some preliminary thoughts on overload issues in the
>     security considerations of draft-ietf-lisp-introduction.
>
>     I will also be curious to see what the presentations at the
>     technical plenary in Seoul have to suggest on the issue, if anything.
>
>         The recent Denial-of-service attacks is a scenario we should
>         have in mind when building robustness in the network mapping system.
>         In draft-padma-ideas-problem-statement-00.txt, there is a
>         section on mapping system security requirements that
>         specifically cover
>         this case.
>
>         One of the questions that comes to mind is whether the
>         robustness of such a mapping system should drop/throttle
>         responses when it is
>         While we do propose to rate-limit the messages in the problem
>         statement, isn't this playing into the hands of the attackers?
>
>         Requesting feedback from the list and ccing wg with expertise in
>         the area or interest in mapping system technology.
>
>         Thanks in advance
>         Padma
>
>         From: IETF-Announce [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of IETF Chair
>         Cc: [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/blog/2016/10/attack-against-the-architecture/>
>
>         <https://www.ietf.org/meeting/97/index.html>
>
>         Jari Arkko, IETF Chair
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/lisp>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ideas>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 29 Oct 2016 10:20:10 -0700

> In section 5 of draft-padma-ideas-problem-statement, there is a section in the table which specifically discuss about the structure of IDs and whether we should used them for specific classes or as the Network Mapping system is proposing to attach metadata to ID.

Maybe we can experiment with the EID-prefix block 2001:5::/32 from RFC 7954/7955 to allocate sub-blocks from large regions of the world. Yes, geographical allocations without the issue of the past, since EIDs are not injected into the underlay routing and are not based on Internet topology.

Do this first and then decide which, say continent block is registered to a regional mapping system. And if an ID needs to register to multiple mapping systems. The mapping systems should considered to be relatively local in scope and may overlap.

This could help mitigate DoS attacks to a smaller (but still scalable) part of the infrastructure.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 29 Oct 2016 10:27:48 -0700

> Also, it seems to me that if all you want to do is break a single MR, then rate limiting is irrelevant.  In the absence of limits on who can query a specific MR, you can bombard it with more queries than it can handle and you will take it out of service.  So a rate limit helps the system while harming the MR capability only slightly.

This is why it is important to anycast most of the MRs that will be deployed. So the attack sources are naturally sending, in spread out fashion, to a very large cluster-set of MRs. Only with a concentration of sources in the relatively same topoglical area with lots of bandwidth can be successful at a many-to-1 attack.

> Trying to infer whether an entity is allowed to undertake specific operations without authentication, using information such as the IP address, seems fraught with failure.  Trying to classify all entities into types (onotology?) seems unlikely to produce correct results, as classes are not cleanly defined.

And remember by doing signature verification or decryption, the problem gets worse for the MR. Because it has to use more resources when most of the packets are from unauthorized sources.

And white-listing 1 billion users to provide a public service minus the 1,000,000 attackers is a white-list management nightmare/challenge.

> As I said, I look forward to the technical presentation at the IETF meeting to see if they have any ideas that can help.  Yes, there is work to be done.  Putting authorization into the identity seems to be asking for trouble.

Definitely.

Dino

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 29 Oct 2016 10:38:34 -0700

On Sat, Oct 29, 2016 at 10:20 AM, Dino Farinacci <[email-masked]>
wrote:

> whether we should used them for specific classes or as the Network Mapping
> system is proposing to attach metadata to ID.
>
> Maybe we can experiment with the EID-prefix block 2001:5::/32 from RFC
> 7954/7955 to allocate sub-blocks from large regions of the world. Yes,
> geographical allocations without the issue of the past, since EIDs are not
> injected into the underlay routing and are not based on Internet topology.
>

> Do this first and then decide which, say continent block is registered to
> a regional mapping system. And if an ID needs to register to multiple
> mapping systems. The mapping systems should considered to be relatively
> local in scope and may overlap.
>

 <Padma> Agree.

Thanks
Padma

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 31 Oct 2016 16:31:10 +0000

Hi, one observation and one question. The observation is that anything on the open
Internet that provides a service can be subject to Denial of Service – and, I am not
just talking about the LISP mapping system. The question is how is it that we have
not yet seen DoS attacks take down critical Internet services such as online banking;
have we just been lucky up to now?

Thanks - Fred

From: lisp [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Saturday, October 29, 2016 10:39 AM
To: Dino Farinacci <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [lisp] [Ideas] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

 <Padma> Agree.

Thanks
Padma

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 31 Oct 2016 10:02:57 -0700

> have we just been lucky up to now?

Fred, it has happened. Just hidden to avoid headlines and fear.

Dino

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Mon, 31 Oct 2016 18:48:31 +0000

Hi Fred

Thanks for raising this interesting question.

Yes it has happened and will continue to do so. It will a very sensitive topic that none of the entities attack would want to be publicized at all cost.
That said, it is much easier for a private institution to keep it under the wraps.

Are they taking measures? Absolutely!
It is pretty recent that we now have authentication based on which computer is used to login using 2 step verification. The two
Step verification involving confirmation of code sent to mobile can be considered a tell tale sign.

I think the difference with the latest attack is that 
- it involved the DNS system or other services that cannot rely on the two step verification for instance which could potentially identify it the requests are from botnets. 
The larger and indiscriminate you are about users to your service, the higher the risk of a DDOS attack waiting to happen.
- It is harder to keep it under the wraps when you have multiple parties involved.

Coming back to the mapping systems, while it may be vulnerable just as many other components of the internet, now is time for rethinking. 
I am really looking forward to the technical plenary. The latest attack highlights the urgency to get started on working on it. 
The motivation for the IDEAS problem statement is to identify these critical issues and provide a framework leveraging properties in ID enabled networks.
IMHO, it is best to have a framework for all ID enabled networks rather than going about it in piecemeal, and this is the goal for IDEAS, or at least it is a starting point.

Padma

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Dino Farinacci
Sent: Monday, October 31, 2016 10:03 AM
To: Templin, Fred L
Cc: Padma Pillay-Esnault; [email-masked]; [email-masked]
Subject: Re: [Ideas] [lisp] FW: Technical plenary: Attacks against the architecture - implications for the Network Mapping System

Dino