Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP

[marcelo bagnulo braun <marcelo at it.uc3m.es>]

El 13/04/2007, a las 6:27, Dino Farinacci escribió:

> > > > so are you envisioning an hybrid system that has both the push and 
> > > > pull models? In such scheme there would be these mesh of high level 
> > > > routers that exchange the whole loc id mapping database and then 
> > > > smaller routers that use the pull model to query these high level 
> > > > routers?
> > >
> > > Yes, I think something like that.
> > >
> > > > the new protocol would then run between these high level routers, 
> > > > is that it?
> > >
> > > Yes, which will be trusted. As well as having a registration 
> > > procedure that is pub/priv key protected for the ETRs to register 
> > > EID-to-RLOC mappings.
> >
> > So are you using a trust model that is based on a closed set of 
> > participants that trust each other rather than a mean to certify that 
> > the actual information about binding is correct?
>
> Yes.

but considering current BGP attacks, this model seems to have serious 
limitations, especially, if you want to have a wider deployment, where 
even smaller sites want to deploy an ID loc split solution....

> > > I think we have a good demarcation design where the LISP-00 ID can 
> > > use various means to obtain the mappings. I can see any or all of 
> > > the following:
> > >
> > > o Static
> >
> > i don't think we should preclude this one, but i don't think it is 
> > general enough to solve our problems (i would leave it as a corner 
> > case for testing and exceptions)
>
> May be adequate in TE-ITRs.

agree

> > > o ICMP
> >
> > My take on this one is that much needs to change from its current 
> > form to be secured. In particular you will need a few more message 
> > exchange to achieve this.
>
> I realize that. That we can fix. Not worried about it too much.
>
> > Besides, you need a valid ID to locator mapping (with at least one 
> > working locator) to actually send the initial request, so this needs 
> > to be complemented with an additional mechanism. In LISP 1, the 
> > mechanism is the identity, since the identifier is also a valid 
> > locator.
>
> I don't understand your point here.

that if you move from LISP 1 the identifier is no longer routable as it 
is and you need some additional infrastrcutre to solve the initila EID 
to locator mapping
in LISP 1.5 it seems that this is achieved through this alternative 
routing infrastrucutre that is used to route packets containing 
idnetifiers. Actually this is part of the EID to locator resolution 
system in this case.

For the other two flavoers of LISP, the EID is not routable per se, so 
you will need to obtain the locators associated to a identifier 
somehow, before starting the communication, so you cannot get them from 
getting ICMP messages back as reply to the first packet (at least for 
the initiator)

You could get them from the DNS, along with the EID, when resolving the 
fqdn, but this only works for hosts having fqdn and there are 
additional situations when you need to solve the eid to locator mapping 
when you don't have the possibility of using the fqdn as i mentioned in 
another email recently

> > > o DNS
> >
> > not sure what do you mean here...
> >
> > the DNS as used in HIP? i.e. using the DNS to obtain both the 
> > identifier and the locator set associated to a fqdn
> > or the DNS system to retrieve identifier to locator mapping, like for 
> > instance using ULAs as identifiers and using the DNS reverse tree 
> > entry for the ULA for retrieving the locators associated with this 
> > identifier?
>
> The way we have been talking about it. Using DNS store mappings.
>
> > the DNS as a generic protocol independent of the current DNS system 
> > to make a directory service for retrieving Id to locator mapping?
>
> Right.
>
> > In any case, in order to answer this question, i guess that an 
> > important previous question is how do you think the identifier 
> > namespace will be? I mean, it seems that DNS type of approach will 
> > not scale to support an 128 bit unstrucutred identifier namespace. 
> > OTOH, if you are thinking of using ULAs or PI addresses as 
> > identifier, then this may work
>
> What will? 128-bits is a lot of addresses. Shouldn't even try.

not sure i understand what you mean here...
let me ask a few clarifying questions:
- what EIDs are you assuming? 128 bits long? 32 bits long? IPv4 
addresses? unstructured 128 bits? IPv6 addresses? which ones? globally 
routable v6 addresses? ULAs? other?
- what do you think we shouldn't even try? using the DNS reverse tree 
seems possible for doing EID to loc mapping whne the EID are ULAs or 
globally routable addresses, since they are structured imho

> > > o Push-only
> > > o Push-n-pull
> >
> > i like your argument that it is good not to require every ITR to have 
> > the full database, even in a push model. I think we should continue 
> > exploring this solution space
>
> Okay, sounds good.
>
> > > o Pull with new database
> >
> > again, i think this is closely related with the characteristics of 
> > the identifier namespace. If we have an existnet protocol like the 
> > DNS that can provide this feature, i don't see the need for this.
>
> How you pull and what you pull don't have to be related. I personally 
> like prefixes where the size of the prefix is based on the number of 
> systems you need assign IDs to.

ok, at least, you are assuming that IDs will be aggrgegatable in the 
sense that you can assign a block of them to an organization

regards, marcelo

_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram