Pawel Foremski writes: > First, ccrypts task is to secure Ethernet, not IP.
Understood, but the vast majority of traffic running over Ethernet that a user cares about is IP and so IPsec does the job. Obviously IPsec cannot handle non-IP traffic but the question is what non-IP traffic do users want encrypted? > Secondly, IPsec won't decrease MSS in TCP encapsulated in PPPoE > traffic, for example. Various, commercial, IPsec products decrease the MSS for TCP encapsulated in PPPoE. I've not checked the Linux 2.6 IPsec code to see if it does or if it can easily be made to. > > b) what traffic other than IP traffic needs to be encrypted. > > PPPoE; Ethernet in general. PPPoE carrying IP can be handled by IPsec as noted above. That leaves Ethernet in general. > > If the keying is done manually an attacker won't know when the keys > > are changed. However, if keying is coordinated over the same link via > > a protocol (as is done with IKE for IPsec) then the attacker can see > > (or at least guess) the packets carrying the keying protcol thus know > > re-keying is going to occur. > > Only if the rekeying traffic is the only being transmitted. IMHO a border > case. Unless you mask the size of your (re-)keying traffic by randomly padding the packets then they can be detected even in the middle of other traffic. > > Indeed, in IPsec, the equivalent of ccrypt is ESP and that's rather > > straighforward. The complicated part is IKE, the userspace component > > that handles keying. It is certainly possible to create something > > simpler than IKE (e.g. IKEv2 is somewhat simpler) but the devil is in > > the details. > > Sure, but that's IMHO little bit off-topic in regard to ccrypt, which is > just an encryption back-end (eventually the rekeying daemon will sit in the > userspace). Sure. However, there has to be a user<->kernel API and the question is whether what you have now is sufficient when a daemon is added or whether it will need to change? If it does need to change it will need to be backwards compatible or need to be a separate API? Also at least for IPsec, the kernel knows something about IKE in that generally IKE traffic is not encrypted by IPsec. Instead IKE has its own encryption which it bootstraps using shared-secrets/certificates/public&preivate key pairs. In the case of ccrypt either the ccryptKE protocol would need to bypass ccrypt or you need to way to start off with known keys, but not the same keys every time or that can be exploited. - 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
