---- On Mon, 27 Jun 2016 14:53:54 +0100 Denis Ovsienko wrote ---- >Hello all. > >Regarding the paper titled "Securely-Entrusted Multi-Topology Routing for >Community Networks" by Axel Neumann (CC'd) et al., I failed to find which of >the mailing lists the PDF link was posted to originally (and by whom), but now >I have looked through my hard copy of the paper and would like to note a >couple things of interest. >
Found the link to the PDF: http://bmx6.net/news/22 Originally suggested by Dave: https://www.ietf.org/mail-archive/web/babel/current/msg00312.html >My current understanding of SEMTOR mechanism is that it uses an explicit >pre-agreed list of node IDs that belong to a trusted sub-graph. This list >would then be provisioned into each node, which would then filter non-trusted >nodes out when routing a specific set of network prefixes of concern. > >I have thought about it and it seems to me as the size of the trusted graph >grows, the total combined size of the deployed configuration will grow faster >(n*n). This makes it much more difficult to add the 100th node to a 99-node >graph than it is to add 10th node to 9-node graph. Also as far as I understand >it, the pre-agreed list of the trusted nodes cannot be amended online without >losing the association with the peer nodes because the set is represented by >the hash value of its contents and as soon as one has changed it in one place, >the old [different] hash will be filtered out. In other words, compared to a >pre-shared key method I see operational disadvantages and don't see a gain. If >anyone can point me in a better direction to understand, that would be nice. > Well, obvious things sometimes take time to be understood. In SEMTOR the advantage is each trusted sub-graph only protects its own prefixes of interest. After some thinking this interesting property does not seem to be exclusive to SEMTOR, however. In particular, the RFC7298 authentication mechanism could pass to the main protocol instance the details of successful check together with each accepted Babel packet. Then the main protocol instance could keep a note of which neighbours have successfully worked which security associations and make this information available to the route filtering layer, which then would provide the operator with means to shape the trusted sub-graph using the terms similar to SEMTOR: * accept prefix P1 or longer if worked SA 123 * accept prefix P2 or longer if worked SA 123 * reject prefix P1 or longer * reject prefix P2 or longer The description is not technically accurate but the idea should be clear. I am not sure how much practically useful it can be, but anyway. >Another thing, as the paper explains, is the same old link spoofing attack and >the same attacks things a rogue node can do on the transit payload. For this >SEMTOR doesn't itself claim to be a solution and doesn't refer to some other >ultimate solution but does include a discussion of possible detection by means >of monitoring. So the good news is problem statement is consistently >understood by different people. That said, the solution is still unknown. I >would be glad to hear if anyone has to add to this. > -- Denis Ovsienko _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
