RE: [lisp-interest] LISP-ALT and security

["Darrel Lewis (darlewis)" <darlewis@cisco.com>]

> 
> If the ETR for 240.1.2.0/24 is compromised I can see that it 
> is ok if that has an effect on packets destined to 240.1.2.0/24.
> 
> But having it affect packets destined to a shorter prefix like
> 240.1.0.0/16 seems like a new security problem.
> 


Erik,

Thanks for raising this issue, I think it's a pretty serious one.  

I agree that an ETR being able to reply with an arbitrarily shorter
prefix is a security problem.  It seems that this could come about
through either inadvertent misconfiguraiton, or through maliciousness.

An implementation could possibly limit the impact inadvertent
misconfiguration in a number of ways(as Dino suggested in another
email).  However this does not prevent the malicious case.

One possibility is to return map-replies across the ALT.  This would
allow for the possibility for ingress filtering of the ALT Aggregator
router to filter the map-replies along the lines of how it might filter
the xTRs route announcements.

This doesn't seem practical to me for two reasons.  First, its been a
design goal to minimize the traffic on the ALT.  Adding reply packets to
it will move away from this and potentially add further delay to the
map-request/map-reply exchange.  Second, and perhaps more important, the
ALT routers will need special filtering mechanisms, preventing them from
being 'off the shelf' router implementations by requiring ALT specific
code.

Another, in my view, more practical possibility follows:

First, an approach like SIDR can allow for a secure binding between the
an organization and it's prefix length.  An ITR can then check against
the registries PKI infrastructure to verify the validity of the binding.
Of course, this depends on the (near) universal adoption of the SIDR
technology.

While we wait for the above to happen, a way to implement a simple
version could be as follows, it uses a modified version the gleaning
mechanism used by LISP mobility (LISP-08 section 9.3).

1)  The ITR gets a map reply from the remote ETR, and insert's the /32
(or configurable longer) prefix for the destination in the data cache.
This lets the traffic for the dest-IP to get flowing.  The ITR could
also insert or not insert the shorter EID prefix of the map-reply
pending verifification, described in step 2). 

2)  Then the ITR takes the EID prefix from the map-reply and initiates a
new map-request to the an RIR server reachable the ALT (a well known,
configured destination).  The EID-RIR server replies with a map-reply
packet with no RLOCs, it merely matches the length of the EID prefix
from the EID-RIR database.  If the length of the EID prefix returned in
this map-reply is the same or longer than the original ITR-ETR map-reply
then the mapping is validated and therefore inserted into the ITRs
data-cache.

So this requires a bit more mechanisms in the alt (a new server called a
reply verification server) that the EID-RIR would operate, but no new
protocol messages.  It could be a viable work around until SIDR is
deployed.

What do you think?  Comments welcome.

-Darrel


P.S. thanks to Dino, Dave, and Vince for their ideas on this during
breakfast.