[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Darrel,


1)  The ITR gets a map reply from the remote ETR, and insert's the /32
(or configurable longer) prefix for the destination in the data cache.
This lets the traffic for the dest-IP to get flowing.  The ITR could
also insert or not insert the shorter EID prefix of the map-reply
pending verifification, described in step 2).
2) Then the ITR takes the EID prefix from the map-reply and initiates a 
new map-request to the an RIR server reachable the ALT (a well known,
configured destination).  The EID-RIR server replies with a map-reply
packet with no RLOCs, it merely matches the length of the EID prefix
from the EID-RIR database. If the length of the EID prefix returned in this map-reply is the same or longer than the original ITR-ETR map- reply 
then the mapping is validated and therefore inserted into the ITRs
data-cache.
I believe it is good hack, well though!. I wonder if it is a good idea to off load the cryoto check from the ITR to another box inside the ITR network.
Here is what I though, the CMS signed matierial with the certificate key could contain: 
	- All my IPv4 an IPv6 prefixes with their valid prefix lengths.
	- All the RLOC that I may be using.
These info should be pretty long term. So you can download the Signing material once a day such as you are doing with the ROAs. 

Roque
So this requires a bit more mechanisms in the alt (a new server called a 
reply verification server) that the EID-RIR would operate, but no new
protocol messages.  It could be a viable work around until SIDR is
deployed.

What do you think?  Comments welcome.

-Darrel


P.S. thanks to Dino, Dave, and Vince for their ideas on this during
breakfast.






-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiRtmEACgkQnk+WSgHpbO7ncACfainQSvHjzDgd1KHhNiC4gbZn
RasAoNwEhNzXEEd81eqUVoLdLds4f4Fh
=l9LE
-----END PGP SIGNATURE-----