On Fri, Jun 27, 2003 at 07:22:08AM +0400, kuznet@ms2.inr.ac.ru wrote: > > 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. Thanks, that's a much better way of stating it. > I guess you do not agree to the last sentence. Correct. In particular, I have problems when the additional transforms contain tunnel encapsulation. > > 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. This does make sense. However, it leads to the problem that I will outline below. > > 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. Alright, let's simplify this to that of a single host A with one Ethernet interface eth0. Now suppose that the local network to which A is connected is trusted to the extent that address spoofing is not possible. Now let's create a gateway G on the same network. G ensures that no packets enter the network from the outside bearing addresses local to it. Through G you can reach a remote gateway R which is not as trustworthy. Even so, A would like to communicate with a network N behind R. So we create an ESP tunnel between A and R with the remote subnet being N. As it is, R can send packets with any source address to A through the tunnel, including ones bearing addresses belonging to the network that A is directly connected to. Now this could be dealt with in the firewall if it had information about the security path. Unfortunately that does not seem to be the case right now. It also imposes extra burden on the IKE daemon as it needs to provide facilities for the appropriate firewalling to be set up. > 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. That sounds reasonable. Thanks. -- 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
