cyrill-k
commented
4 years ago I agree that an encryption/integrity protection property is quite difficult to define as we would also have to specify which entities hold en-/decryption keys and on which subpath traffic is encrypted (e.g., two local networks connected via encrypted tunnel then all nodes in the local network essentially share the keys). It may be easier to say that encryption/integrity protection depends on the link layer/network/transport protocol used and is thus orthogonal to path properties. So if two nodes establish a VPN connection then they have encryption/integrity protection for all packets sent between them according to their respective thread model.
I added PR #34, which mentions these points in the security considerations.
We could maybe define a more generic tunnel property that provides "security" properties such as secrecy (e.g., based on encryption or isolation) or integrity protection (e.g., based on MACs or isolation) using arbitrary means. A tunnel could be defined over a subpath. But this still needs a (generic) thread model...
renghardt
At IETF 106, Joachim Fabini asked whether we wanted to add a property saying something is encrypted [on a specific layer], or maybe also protected by a signature. I'm sceptical, as "encryption is not the same as encryption" - different protocols or algorithms have very different security properties, even though they might both "encrypt" a certain header or payload. In TAPS, we were heavily criticized for sounding like we can define a generic feature like "this protocol offers encryption", and I think defining such a path property would be the same. So, I'm against such a property. Also, we don't have to define every property that someone can possibly think of.