[Babel-users] About an authentication extension

[Rodrigo Garcia]

El 08/09/17 a las 05:28, Toke Høiland-Jørgensen escribió:
> Rodrigo Garcia <strysg at riseup.net> writes:
> 
>> Hello, i've been working on an extension to the babel protocol to
>> authenticate updates using RSA. It's mostly an academic excercise and i
>> have planned the first functional versions in a month or so.
> 
> What are you trying to achieve? What is your threat model?
> 

Hi, i wanted to reduce the risk of ip spoofing as an academic excercise.

I tried 3 routers and two of them advertising the same network prefix,
at first 1st and 2nd router exchange routing information and established
a link then let them sending ICMP ping.

Secondly, the 3rd router starts advertising the same prefix as the 2nd
and, then the 3rd router is intetionally put closer than 2nd to make it
advertise a better metric.

After some time 1st router prefers to take the route to the 2nd network
prefix through 3rd. 2nd stoped to receive the ICMP packets from 1st, and
3rd started receiving ICMP packets from 1st instead.

Here some logs (Sorry I could't get time to translate this to english)
https://git.laotrared.net/LaOtraRed-dev/babeld-lor/src/master/doc-lorauth/spoofing-tests1.md

>> The main idea is to make that a *central entity* generates a set of
>> encrypted tokens using a RSA *private key*. The set of tokens is
>> unique to every node on the network and every node receives it's
>> unique set of tokens, a network prefix and the *public key* from the
>> central entity.
> 
> You're basically talking about signed tokens here, right? Why do they
> need to be encrypted? This sounds a little bit like you're rolling your
> own crypto (which is generally a bad idea). I'd suggest you make
> absolutely sure you have your primitives defined, and also define the
> problems you are going to solve (threat model etc).

The tokens are not signed, they're just encrypted with a *private key*
wich no single node owns. Instead a node must use the corresponding
*public key* of the private key (wich is only used by a central entity
to generate the encrypted set of tokens unique to every node)

>> Every decrypted token has the form:
>>
>> <network_prefix>_<randomnumber>
>>
>> example:
>>
>> 80.0.2.0/24_48003818
>> 80.0.2.0/24_41106879
> 
> So what you are authenticating is that this router is authorised to
> export this prefix? What's the purpose of the random number? How are you
> preventing an intermediate router from just grabbing a token from
> another router and reusing it?

Yes, on an update a node must send a token which shows that it really
owns the prefix it is being advertising.

To prevent a node to just capture a token then reuse it a node should
have a big ammount of encrypted tokens and send different ones, the
random number is just to make then different and to make it more
difficult to guess the private key.

> 
>> I was planning to use encrypted tokens of 512 octets.
> 
> Holy cow; you realise that on some mediums a single token will take up
> the entire available package size, right? And you presumably need a
> token for each prefix? Why do you need such big signatures? ed25519
> signatures fit in 64 bytes, for instance, and that will lower the
> computational cost as well...
> 

Yes it is, in practical terms i was planning that only a set of
important nodes use the authentication method.

>> Every node must send a token from it's unique set of tokens on every
>> route update. When a node receives an update, it tries to decrypt the
>> token using the *public key* of the central entity and checks if the
>> decrypted token contains the network prefix being advertised.
> 
> So the tokens are propagated across the entire network? That is *a lot*
> of extra traffic.

Yes it will be, but for flexibilty and network traffic sake, i think a
node could forward also not authenticated updates (without the encrypted
token) then if a node receives an update *with* the encrypted token it
should *prefer* that update over common ones and if it is valid then
forward it.

> Nope, implementations that don't understand your extension are going to
> choke on your TLVs...
> 

ok, (lol)

> Depends on what you are trying to achieve. I'd suggest taking a step
> back and defining this instead of jumping into an implementation.

Thanks, i think i'll give it a try.