Changes between Version 4 and Version 5 of Security01

Timestamp:

19/10/09 20:57:11 (13 years ago)

Author:

hartmans-ietf@…

Comment:

--

Security01

@@ -121 +121 @@
 === Denial of Service ===
 
+There are a few broad concerns with mapping denial of service:
+ * The mapping system could be used to  generate traffic that contributes to a denial of service attack.
+ * A vulnerability in the mapping system could allow an attacker to misdirect or blackhole traffic creating a data plane denial of service within LISP.
+ * The mapping system itself will be subject to denial of service attacks.
+
+Analysis is required on the first class of attack
+
+There is a conflict between mechanisms used to mitigate denial of
+service mounted against the mapping system and mechanisms that cause
+the mapping system to be a denial of service. Today there is an
+assumption that there will be rate limiting of mapping traffic at
+ITRs, ETRs, and at nodes in the mapping system core. These rate
+limiting may prevent a flood of mapping control packets from disabling
+the control plane of an ITR or ETR or causing damage to the data
+plane. However an attacker could easily flood these rate limits
+causing legitimate mapping traffic to be lost  and turning the mapping system into a denial of service on LISP. 
+
+Some things to note about this:
+ * We may be able to set up deployments where map resolvers and their clients have pre-existing relationships. If you're using your ISP's map resolvers or the map resolvers of your EID provider, you have a relationship with them.
+ * Map servers and ETRs already have a relationship
+ * It's not clear that nodes in the core of the mapping systems need to talk to people they don't trust at some level. This is dependent on the mapping system. However alt nodes have some level of trust because they share a BGP instance. 
+ * ETRs that are not part of the core of a mapping system only receive map requests from their map server or people who have previously received mapping data from them.
+
+GOAL: Investigate how these properties can be used to design requirements and defenses to protect the mapping system.  
+
+GOAL: Consider the lessons of DNS for denial of service protection.  DNS has developed a number of strategies for dealing with the large number of DOS attacks it faces.  In addition, the DNS community probably is aware of protocol changes they wish they could make that would reduce the attack surface.  We are much earlier in the design of LISP; we should learn from DNS.  One area that we currently duplicate that is problematic is that map resolvers are open and accept requests from anyone.  This has proven problematic for DNS.
 
 == Mapping System  In Specific ==
 
+When looking at mapping integrity we could treat the mapping system as
+a monolithic system. If mapping updates are cryptographically signed
+and if all ITRs and ETRs have the necessary keys, certificate
+revocation lists, intermediate certificates, authorization information, software and hardware resources to verify mappings then mappings could be verified end-to-end. Mechanisms like the nonce in map request messages would be unneeded and we could consider mapping integrity and end-to-end problem. 
+There are several drawbacks to this approach:
+ * Cryptographic verification of Internet-scale mapping information is likely to be difficult.  We probably do not want to require all ITR and ETR implementations to pay this complexity cost.
+ * We've found with other cryptographic protocols such as DNSSEC and SCVP (a certificate validation protocol) that  it is beneficial to offload this sort of validation so that not all clients need updated policy, certificates, etc.
+ * Specifying this sort of cryptographic verification will take significant time.  Meanwhile, we want to run experiments with sufficient security  that people feel comfortable using LISP for their traffic.  That requires a level of mapping integrity similar to today's Internet; significantly less mapping integrity would be unacceptable even for the experimental phase.
+ * If the only security provided  in the mapping system is end-to-end, we would probably have to mandate not just implementation of this security but actually use of this security for Internet deployments.  While we have designed protocols such as CAPWAP where control-plane security is mandatory-to-use, the necessary level of security for LISP would be very heavy-weight to mandate for all Internet deployments.  
+ * Depending on the deployment model, some nodes in the mapping system may be much more trusted than others.  For example in LISP+alt, LISP+alt routers have a relatively high level of required trust compared to ETRs not part of the ALT.
+ * Depending on the deployment model, some nodes may be much more vulnerable to on-path attacks than others.  One of the assumptions behind the security of today's Internet is that inter-core links are relatively well protected and we need not worry about on-path attacks. However on access networks we are more concerned about on-path attacks.
+ 
+In order to address these drawbacks, we  analyze the security of mapping at several points in the network.  Our goal is to:
+ * Use the map server and map resolver to isolate the ITR and ETR from the security details of the mapping system.
+ * Use this separation to permit security to be added in the core later or to permit the entire core mapping system to change.
+ * Take advantage of the trust relationship between the map server and ETR to provide better security.
+ * Analyze the role a trust relationship between the ITR and map resolver could have.
+ * Provide security as good as the Internet mapping system today without end-to-end cryptographic protection of the mapping core.
+
+
 === Between the ITR and the Map Resolver ===
 
@@ -131 +177 @@
 
 === Between the ETR and the ITR ===
+
+Today, the ETR sends a packet directly to the ITR including its mapping information. The ETR gets mapping information from the reply record in the ITR's packet.  The nonce in the map request and reply is used to provide protection against off-path attacks. 
+
+This system fails to provide delegation
+integrity. draft-bagnulo-lisp-threat-01 describes a critical attack
+where an ETR can claim a larger prefix than is delegated to it. That draft proposes that an ETR can claim a /0 prefix; even if that attack is prevented by placing a maximum size on the prefix that an ETR can claim, an ETR will be able to claim mapping for significantly more addresses than belong to it.
+
+REQUIREMENT: The LISP mapping system MUST provide the ITR with
+assurance that an ETR is not claiming a prefix larger than one it
+would be permitted to register.  The mapping system MUST provide
+assurance to an ETR that the prefix in a map reply from the ITR is not larger than the ITR would  be permitted to register.
+
+Justification: This prevents an off-path attack where an ITR or ETR can claim all traffic for large chunks of address space. In the case of an ETR claiming address space, it currently only needs to get the ITR to request mapping for some address within that space that legitimately belongs to the ETR.  In the case of the ITR claiming address space, a similar condition may apply.
+
+We also need to investigate the constraints that should be applied to
+additional map reply records in a map reply.
+
 
  == Data Plane ==