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

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

Benson,

My comments below, thanks for your thoughts, I think they are very
interesting.

> 
> 
> On Thu, July 31, 2008 05:02, Erik Nordmark wrote:
> > From a security perspective there isn't an issue with 
> allowing an ETR 
> > who has authority to speak for /22 EID prefix to provide separate 
> > information (priorities, weights, even RLOCs) for different 
> sub-sets 
> > of that /22.
> 
> On the surface this would seem true. However, today an RIR 
> assigns a block to an ISP and the ISP sub-delegates from that 
> block to their customers.

Unless its PI space, in which case its directly from the RIR.

> The ISP has authority to speak (BGP-wise) for a /22 they've 
> been assigned, and I suppose any component of it that they 
> de-aggregate for routing regionalization etc (as long as 
> their peers will accept that). But do we want to allow an ISP 
> to indicate which RLOC, weights, etc, to use to reach the 
> sub-delegated end-network? I'd suggest that in LISP the 
> end-site which is paying for the bandwidth, and possibly 
> paying for one or more additional/resilient ISP connections, 
> should be the "authority" in this regard.

Exactly, that's why the end-site's ETR is authoritative
For mappings, this is by design.  

> 
> To address your point directly, there may not be an ETR that 
> is authoritative for a /22, but rather there may be a handful 
> of ETRs that are authoritative for smaller sub-blocks (i.e. 
> /24s). The delegating ISP may have the capability (say, as a 
> man-in-the-middle) to respond for shorter prefixes, but it's 
> not clear to me whether this is a good attribute from a 
> security perspective.
> 

I think you make a good case for why EID space should be
allocated by an organization independent from the provider,
if we want (and I think we do) the space to be used 
independently from the provider.

> >
> > (It might have an impact on scaling, but that is a 
> different matter.)
> 
> Indeed. The ALT topology puts a handful of providers in the 
> path of a map-request, 

In the path in the sense that they are delivering the tunnel
packets.  Note that the ALT does not limit the tunneling
format to GRE, IPSEC (auth or crypto) could be an option.

> whom may not be in the path of the 
> flow that follows the map-reply. I think we can expect this 
> to add latency to flow establishment. I'd hate to see a 
> delegation-security mechanism adds yet more latency.

I agree, I think we should let the ITR decide how much security
 (and therefore potential latency)they would like.  

> 
> On the other hand, some of those providers could pro-actively 
> respond with information about de-aggregation in response to 
> the initial map-request.

This assumes that providers are running the ALT.  If they don't,
then they would find it hard to answer a map request on behalf
of an ETR.  On the other hand, if we do want to implement some
form of caching in the alt to reduce initial latency, security
 of those cache entries is another matter.

> This would reduce establishment latency at the cost of 
> additional packet overhead. I'm not sure I like this approach 
> either, especially given that the additional traffic may have 
> to flow via paths (say, transit-provider
> connections) that I would otherwise avoid with my data flow 
> (say, by using peer connections).

I think the idea of trust until verify has some potential here,
See my earlier message about using lisp's gleaning technique.

> 
> I don't know for sure, but I suspect that we may never be 
> able to find a solution that scales exactly as well as the 
> current Internet and still provides the capabilities of LISP.
> 

Not sure either, but the best way I know to find out is by 
Trying, and seeing what happens. :-)

Regards,

Darrel