[Babel-users] About an authentication extension

[Rodrigo Garcia]

El 08/09/17 a las 07:37, Toke Høiland-Jørgensen escribió:
>> Hi, i wanted to reduce the risk of ip spoofing as an academic excercise.
> 
> I'm all for academic exercises, I'm just suggesting that it'll be
> helpful to define (on the protocol level) what you are trying to protect
> against. I.e., which nodes should be prevented from doing what?
> 

> Right, I see. Are you familiar with the HMAC extension to babel
> (RFC7298)? That does something different (it prevents nodes that don't
> know the shared secret from participating in the network at all, but
> does not restrict which prefixes each node can export). However, it may
> be useful to read at least parts of it to help you formulate the
> requirements for your own scheme.
> 

I reviewd the HMAC extension but not in detail because i realized that
as you say it does not protect nodes against ip spoofing.

> But if everyone knows how to decrypt all the tokens they are not really
> secret; so it basically becomes the same as a signature, no? Except if
> it's *not* signed you may be able to spoof other values by changing the
> ciphertext of a valid token you already own (not sure how susceptible
> public crypto is to this)...
> 

Yes, but a node does not have the private key, so it can't create *new*
encrypted tokens by its own.

> 
> So why not put that into a sub-TLV of the update?
> 

To tell the truth i saw how HMAC did and thougth it was a good idea to
define a new TLV, but not really considered about sub-TLV.

>> 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.
> 
> So what happens if a node runs out of tokens? How is another node
> supposed to deal with an update that has no corresponding token? Always
> ignore it? For how long?
> 

If a node runs out of Tokens and a malicious node got all of them that
is a problem.

I was planning that a node should select a token from it's set of tokens
based on the seqno and prefix, the former should change in time so a
different token is to be send every time the seqno changes.

> How does this interact with the other preference rules of Babel? Loop
> avoidance in particular; if there's an non-feasible signed route but a
> feasible unsigned route, is a node allowed to pick the unsigned one?

To tell the truth i haven't analized the efect on loop avoidance, but i
guess for flexebility sake a node should consider feasibility first than
authentication. So it is a condition that a route proves to be feasible
before even trying to check if it is correctly authenticated.