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

["Joel M. Halpern" <[e-mail]>]

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:
> 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
> messagesexchanged, 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 <[e-mail]
> <mailto:[e-mail]>> 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.
>
>     There probably is more with considering.
>
>     Yours,
>     Joel
>
>
>     On 10/28/16 7:39 PM, Padmadevi Pillay Esnault 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
>         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:[e-mail]
>         <mailto:[e-mail]>] On Behalf Of IETF Chair
>         Sent: Friday, October 28, 2016 9:21 AM
>         To: IETF Announcement List
>         Cc: [e-mail] <mailto:[e-mail]>
>         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/
>         <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
>         <https://www.ietf.org/meeting/97/index.html>
>
>         Jari Arkko, IETF Chair
>
>         _______________________________________________
>         lisp mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/lisp
>         <https://www.ietf.org/mailman/listinfo/lisp>
>
>
>     _______________________________________________
>     Ideas mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ideas
>     <https://www.ietf.org/mailman/listinfo/ideas>
>
>