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

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



    > From: Christian Vogt <christian.vogt@nomadiclab.com>

    > Reverse mappings need to be secured.

That was my conclusion too. I spent a great deal of time working out an
efficient and tractable way of securing the reverse mappings (by signing
them, using public/private key pairs); not sure if all that has made it into
the LISP documentation yet.

It's somewhat complicated (as is any well-designed secure system, because you
have to deal with all sorts of cimcumstances), but it has the advantage that
whenever you get a binding (from any part of the namespace), you can tell if
it's a legit binding just from the data that comes along with the binding.

    > Verification will likely cause the same overhead at a packet
    > receiver as a mapping table look-up.

Not sure what you mean here; if you mean just in terms of computation, I
think verification will be more expensive than looking up a mapping,x but you
only need to verify a mapping when you get it in, not every time you use it.
(And why would a receive be looking up mappings anyway? Surely it's the
sender that has to look up mappings, no?)

	Noel

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