Hello! > Could someone provide a rationale behind the algorithm in > __xfrm_policy_check? In particular, it seems that it is based > on the principle that the longer the security path, the more > trustworthy the package. No. The principle is that required transformations must be present and exactly in correct order. If additional transformations were applied, they are ignored as not presenting any interest for policy. Hence, there is no "more trustworthy". There is "trustworthy" and "not trustworthy". Additional transformations cannot increase or decrease degree of our trust. I guess you do not agree to the last sentence. > One application of this is that any > packet with a non-empty security path is allowed through if > there are no explicit policies forbidding it. Hmm... If there are no forbidding policy, _any_ packet is allowed, without secpath or with it. It is sorta sense of absence of forbidding policy, is not it? If you are going to forbid IPIP or something, it is some forbidding policy already. > Now perhaps that idea is that anyone creating a tunnel should > use firewall rules to protect themselves. But it seems that for > that to work, we need to provide information about the security > path to the firewall subsystem. Is that possible today? ... > that it imposes on the IKE daemon. I am sorry but I understood nothing... What tunnels do you mean? Maybe, it is worth to draw some picture. If the system looks flawed, it is better to fix it. If it is just praanoia sort of not allowing to tunnel through hell a packet authenticated end-to-end, it should go to firewall. > I'd also like to know the > intended purposes of optional transforms. If the state is present, do it. If it does not, do not care. Useless for security, though still well defined. Valid use is f.e. ipcomp. Alexey - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
