Dawid Ciezarkiewicz writes: > I'd be thankful for your opinions about that idea. Please forgive me any > nuances that I didn't know about.
* I suggest extending the documentation with some motivating examples of why someone would want to use this rather than IPsec for IP and/or in what scenarios you'd envisage someone wanting to encrypt ARP, PPPoE, ... etc. Perhaps, you can somehow mesh it with 802.1x to provide link-level encryption to augment 802.1x link-level authentication? * Your implementation allows the key to be changed but not in a way that allows both sides to do so without disrupting traffic i.e. you don't have something akin to IKE phase2 re-keying. Without that then if someone can sniff the traffic long enough they are going to get a big sample of data to try and crack the keys with. * You write "frames will be delivered in order, so on the other side IV can be always in sync." If any switches between the two linux boxes are running any kind of link aggregation then you can't guarantee that the frames will be delivered in order. IEEE 802.3ad requires that packets belonging to the same session travel down the same port to avoid re-ordering but implementations vary as to whether they actually guarantee it or not since most higher level protcols can survive some re-ordering. * Given your desire not to change the size of the payload you have no space for MAC. This makes it easier (but by no means easy) to alter the payload in such a way that it is still decrypted and considered valid. * For the same reason as above you don't have a sequence number. This combined with the lack of MAC weakens the defense against replay attacks i.e. where third party captures a packet and then re-sends it at a later time. The fact that IVs must be in sync for the packet to be accepted makes it harder for an attacker but since they know how the IV is calculated they know what message to look for before replaying a packet. * A variation of the above is that the attacker doesn't care about injecting packets per se, rather they use the above to cause packet loss by causing the receiver to update its IV based on a replayed packet thereby causing the next "real" packet to be dropped because the IV is out of sync. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
