Hi: 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. 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. This principle looks OK at first glance. However, I have encountered some cases where it becomes a problem for the IKE daemon. I believe that this principle is broken when tunnel states are present. For example, imagine that you have a security gateway connected directly to a trusted network. On the same interface an IPsec tunnel is established to a remote host that is less trustworthy. In the absence of the tunnel, the security gateway can afford to accept packets with addresses from the trusted network. However, with the presence of the tunnel, this is no longer possible as packets can arrive inside the tunnel bearing an address belonging to the trusted network. 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? It also seems to me that tunnel verification is more naturally done inside the IPsec system as the information needed to do so is already present, in the form of the incoming or forwarding policy. Optional security transforms though do pose a problem to enforcing this. To summarise, I'd like to find out the possible applications of the principle I outlined earlier so as to justify the costs that it imposes on the IKE daemon. I'd also like to know the intended purposes of optional transforms. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - : 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
