[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Generic requirements on mapping mechanisms
- To: rrg <rrg@psg.com>
- Subject: [RRG] Generic requirements on mapping mechanisms
- From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
- Date: Tue, 11 Mar 2008 15:15:43 +0100
- Domainkey-signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date:from:reply-to:mime-version:to:subject:content-type:content-transfer-encoding; q=dns; s=selucl; b= R4M2M0SCtItWgLYYar3TDLf598Z1VPj9KfcaepN6K7+M5uzeLBzu1h5CQhEpe+PG Rww1GnKQ6spCvBzIDNmzIPg7Ih6tGM9xoUix+EjsuCyNXrIHaKIj8a3n/e18yhnI 9A+xZu+ERwzzF2qzVswGhY7UKNPa45aFWjkOrKFeILk=
- Reply-to: Olivier.Bonaventure@uclouvain.be
- User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
Hello,
Today, there is a generic discussion on mapping during the RRG meeting.
Unfortunately, I'm not in Philapdelphia, but I would like to list a few
requirements that I consider important. These requirements are
independant of the particular mapping mechanism used.
Comments are welcome
Olivier
---------------------------------------------------------
The mapping mechanism will be used to map a (set of) identifier(s) on a
set of locators, formally
{EIDs} -> {Loc1, Loc2, Loc3}
From a generic/abstract viewpoint, I think that the following
requirements are important :
1. Locators and EIDs
Locators and EIDs will be allocated by a central authority, such as IANA
or deleguates like RIPE, ARIN, APNIC, ... This central authority is
important to ensure uniqueness of the locators and of the EIDs.
I assume that locators will be IPv4 or IPv6 addresses. EIDs could be
something else.
2. For scalability reasons, the mapping mechanism must allow to map a
(preferably large) set of identifiers on a set of locators.
This implies that EIDs will need to be allocated in contiguous blocks
and not individually. The size of the EID set will affect the
scalability of the system. Using large EID sets will make the mechanism
more scalable. Thus, the central authorities should allocate large EID
blocks.
To avoid the scalability problems that we have today with interdomain
routing, the owner of the EIDs should support the cost of using small
EID sets. A possible way to ensure this would be to force the an owner
of an EID block to always reply with a mapping that is valid for the
entire block and optionnally add mappings for subsets of the EID block,
e.g. for traffic engineering purposes.
3. There should be a way to secure the mapping replies
It should be possible for an entity that requests a mapping to verify
the validity of the reply. Some entities may assume that any received
reply is by definition valid, but such a behaviour raises serious
security issues. The mapping mechanism should allow an entity to verify
that a reply is correct and valid. This could be a cryptographic
verification based on signatures or an online verification where a
server responsible for the EID block is contacted to validate a mapping.
4. A mapping will have a limited lifetime.
No mapping can be permament and the mapping reply should contain the
lifetime of this mapping. This is similar to the TTL in the DNS. A long
lifetime will favor scalability while a shorter lifetime will ease
traffic engineering by allowing a site to update regularly its map
replies. As for requirement 2, the cost of using short lifetimes should
be supported by the site that is using those short lifetimes, not by the
entire mapping system.
--
http://inl.info.ucl.ac.be , Universite catholique de Louvain, Belgium
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg