Hi Denis, > An implementor of an authenticated Babel network is left with the > following options:
> * Authenticate all packetes in the network (e.g. WPA). Yes. > * Selectively authenticate Babel packets with IPSec policy. I don't think that can be made to work, at least not without some protocol changes. IKE doesn't work for multicast, while statically-keyed IPSec is vulnerable to replay attacks. > * Implement Babel packet-level authentication using trailing data. > * Implement Babel packet-level authentication using TLVs. Yes and yes. > The TLV option, to my opinion, makes the most sense. I personally prefer an authentication trailer approach. Note first that the authentication trailer is variable size -- it can be anywhere between one octet and (MTU - 60) octets. So the TLV approach is no more flexible than the trailer approach. Second, note that the digest in the Hash-Digest (HD) TLV ranges over the HD TLV itself. I find that confusing, and it is difficult to implement -- you need to make an initial HD-TLV, append it to the packet, compute the digest, then walk back over the packet and fill-in all the HD TLVs. Similarly, on reception you need to walk the TLVs of a packet before you authentify it -- and then you need to walk the packet a second time in order to parse it (you don't want to be parsing an unauthenticated packet). None of these are issues with an authentication trailer (AT). You generate your packet as usual, just making sure you have enough space left for the AT. You then compute a hash of a pseudo-header and the packet, and append the AT to the packet. Similarly, on reception, you jump directly to the AT, extract the data, compute the hash, and accept or drop the packet before you ever walk the packet data itself. Third, AT code can be shared by multiple protocols, even if the have different packet structure. In particular, at first glance it would appear that RFC 6506 can be adapted to Babel with little trouble. That means that we can use a mature spec (11 IDs!) without having to develop one ourselves, or even share code between OSPFv3 and Babel. For all of these reasons, I would like to encourage you to work on adapting RFC 6506 to Babel rather than on an approach based on TLVs. No problem with having TLVs 11 and 12 for your purposes, however. -- Juliusz P.S. I might be away from the Internet from 25 May until 4 June. _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
