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. _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
