Subject: Re: [lisp] EID Address space

From: [email-masked] (Noel Chiappa)
Date: Tue, 24 May 2011 15:39:59 -0400 (EDT)

> From: Ronald Bonica <[email-masked]>

    >> If the ETR makes a mistake, the map-server has to be in cahoots
    >> with it. So that has to happen. And then the upstream ALT box
    >> peering with the map-server has no ingress route filtering. And the
    >> upstream ALT from that ALT box the same.

    >> The bottom line is that bogus EID-prefix will not be registered
    >> into the mapping database.

    > What will prevent it? Some central authority?

Huh? That was just explained, in the message you're replying to!

If a rogue/broken/etc ETR tries to register that it is authoritative for,
say, 18/8, its MS will notice that it's not allowed to be authoritative
for 18/8, and reject the registration.

Similarly, if an MS and an ETR are both compromised, the MS's upstream in the
ALT will not accept the MS's attempt to inject 18/8.

Yes, it's not (yet) a full-blown crypto-based advertisment authorization
system, but the Internet seemed to do quite well without such a system for
routing for many years.

	Noel

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 May 2011 15:56:55 -0400

Noel,

I'm sorry, I should have articulated the question better. I realize that the ETR, MS and the upstream all need to be misconfigured (or as you say, compromised) for this to happen. But isn't that easy to do?

I assume that the owner of the ETR configures the ETR and sends registrations to the control infrastructure. How does the control infrastructure know that the registration is bogus? 

                                                           Ron

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2011 3:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lisp] EID Address space
>