Mark Duffy wrote: >> In this example the "interface" is a do-nothing pseudo construct >> that serves no other purpose than holding a tunnel mode SA (see >> section 3.2 of our ID for a discussion). This approach requires a >> different pseudo interface for each SA, and each SA associated >> with such an interface MUST be tunnel mode. > > I understand your words but I don't think I understand your overall > point here. The reason we create such a virtual interface, is > because *we want to* so that we can represent it as the next hop for > IP routes in a forwarding table, and also so we can run an IGP over > it. In fact, I think that is the basic problem we are trying to > solve here. > > Question: In the IIPtran implementation, are the IP-in-IP tunnels manifested > as virtual interfaces? They are whatever IP tunnel devices you have in the system. They are not virtual in the sense that they perform regular interface functionality (i.e., encapsulation). (But maybe I'm misunderstanding your definition of virtual.) >> Also note that the destinction between tunnel mode and transport >> mode begins to dissappear, since you tunnel mode SAs MUST be >> associated with non-encapsulating pseudo-interfaces, while >> transport mode SA MUST be associated with regular interfaces. >> Encapsulation is a function of the > > > Ah, this relates to section 3.2 of draft-touch, I believe. And this > is a point I have not understood during this discussion. I agree > that the virtual interfaces would use tunnel mode, for the needed > encapsulation. But I don't see why any other use of IPsec, such as > that applied pursuant to SPD policy for each conventional interface, > would be restricted in whether it could be tunnel mode or transport > mode. If you allow tunnel mode SAs on non-virtual interfaces, you again end up with the problem that you can't dynamically route over such a topology. If you allow multiple tunnel mode SAs on a single virtual tunnel interface, you must enforce strong consistency constraints on the SA set. For example, you must enforce that the SAs that match your routing exchanges are exactly the same ones that match all other traffic out that interfaces. As a start, this means that you can't use different encapsulation headers on the two sets. I'm sure there are others constraints. The point is that this becomes really complicated. > Restated, I should think "traditional" use of IPsec based on > per-interface SPD is and can continue to be free to use tunnel mode > or transport mode. And, quite separate from that, there is an > application for IPsec *tunnel mode* cast as a virtual tunnel > interface. BTW, IIPtran could equally be used for the virtual > tunnel interface. Makes sense? I'm not trying to argue that your approach cannot work - it can, and our ID discusses how and when it does. I'm trying to argue that a combination of RFC2003 and a simplified RFC2401 can achieve the same functionality while being significantly simpler. Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature