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

[Christian Vogt <christian.vogt@nomadiclab.com>]

Hi Noel!

Would public-key authentication of an ID/locator mapping really reduce
the overhead at the receiving side compared to a look-up of the mapping
in a global, trusted directory (or in a local copy of the directory)?

I don't think so because, for the receiving side to verify that the keys
used to sign the ID/locator mapping really belong to the ID owner, the
receiving side has to check the ID/public-key binding, and this requires
a look-up in a trusted directory (PKI in this case) as well.  So the
receiving side has to do a directory look-up in any case -- be it to get
the ID/locator mapping, or to verify an ID/public-key mapping.

>     > 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 meant in terms of required directory look-ups.  Computational overhead
of public-key authentication comes in addition to the overhead of
looking up the ID/public-key mapping.

> (And why would a receive be looking up mappings anyway? Surely it's the
> sender that has to look up mappings, no?)

In a world without evil, I would agree.  But since we have to combat
mapping spoofing, either we use self-certifying mappings (as in Six/One,
e.g.), or the receiver must do a look-up in some trusted directory, too.

- Christian

PS:  In all of the above, we are talking about the initial mapping
provisioning for the receiving side.  While the benefits of public-key
authentication are IMO limited in this case, public-key authentication
may very well be suited for mapping /updates/, which a sending side may
want to communicate to a receiving side for TE reasons.





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