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

["Benson Schliesser" <bensons@riot.queuefull.net>]

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.
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.

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.

>
> (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, 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.

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 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 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.

Cheers,
-Benson