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 <[email protected]
<mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>] On Behalf Of IETF Chair
Sent: Friday, October 28, 2016 9:21 AM
To: IETF Announcement List
Cc: [email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lisp
<https://www.ietf.org/mailman/listinfo/lisp>
_______________________________________________
Ideas mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ideas
<https://www.ietf.org/mailman/listinfo/ideas>
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
