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

[Markus Stenberg <mstenber@cisco.com>]

On 17.1.2008, at 0.53, Noel Chiappa wrote:
> > Computational overhead of public-key authentication comes in addition
> > to the overhead of looking up the ID/public-key mapping.
> Right, but I am informed that checking authentication is a lot less
> computationally intensive than signing something - which is good for  
> us, and
> (helpfully) just the right direction for such an asymmetry!

Ok. I used to be paranoid for a living (=work with security stuff)..  
There are certain schemes where the verification of something is  
considerably more expensive (for example, check http://en.wikipedia.org/wiki/Hashcash) 
, but in public-key cryptography the cost of encryption, decryption,  
signing and signature verification are typically roughly of same  
minimum cost[1]. For example, with RSA, all four operations boil down  
to exponentiation + modulo operations with big numbers, give or take  
hashing along the way.

Looking at the 'success' of anything that involves something  
certificate-like (hint: https is only really successful 'open' system,  
and that works by ignoring half the security features such as key  
lengths, certificate revocation lists and so forth), I would really,  
really like to steer clear of any really secure public-key based  
scheme in this system.

Considering the BGP+TCP-MD5 is considered 'secure enough' by the  
people around these days, while it is in truth about as secure as  
sending data in envelopes made of clear plastic, I don't think this  
system needs to be more ambitious if it means orders of magnitude  
worse performance.

> > 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.
>
> Sorry, not sure that I followed that. Did you mean that if you  
> received a
> 'gratuitous' binding, piggybacked on a request for a binding that  
> you held,
> you'd have to do a query on that gratuitously-provided binding, to  
> verify that
> it was valid, and not a spoof?
>
> If so, I think the built-in authentication of bindings (above)  
> solves that one.

Unfortunately it is not computationally feasible.

> > While the benefits of public-key authentication are IMO limited in  
> > this
> > case
> On the contrary, it's the only way I can see to authenticate the  
> client's
> binding 'on the spot' (i.e. without additional network traffic) if you
> gratuitously provide it to the server, piggybacked on the client's  
> request
> for the server's binding.


I am not actually claiming all of this is completely impossible; the  
actual public-key infrastructure itself I find deeply depressing  
though, so I would prefer to avoid it if possible. For end nodes/edge  
routers, piggybacking+signature verification would still work  
reasonably well, given appropriate rate limiting, due to the extra  
processing power and potential slight performance savings involved.  
For anything in the core, 'not going to happen' sums what I think of  
the piggybacking schemes that involve anything else than blind trust.

Blind trust sounds slightly dangerous though..

Cheers,

-Markus

[1] This assumes _small_ data length; the sign+verify is faster than  
encrypt+decrypt over large blocks of data due to the fact that only  
hashing is performed on the data itself, but given small input data  
amounts, the costs are similar. Sign/verify stay same cost regardless  
of data size, however.


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