Mark Duffy wrote: > I think what you mean by "use a virtual device for each ... tunnel" is that > the IPsec tunnel is modeled in the system as a point to point link, onto > which the system has an interface, correct? With IIPtran, doesn't the > IP-in-IP tunnel have to be modeled in exactly that same way? Maybe I am > being thick but I don't see the gain there. We assumed that RFC2003-compliant IP tunnels are implemented as proper interfaces. You're right that it would be conceivable to implement them differently (divert socket hacks, etc.), and on such platforms they would need to be fixed just like SAs would need to be so they are present in the routing table. (I wouldn't want to use such a platform, however :-) > In either case I would see motivations following from one other in the same > order: > a. I want to create a point-point link in the overlay network > b. I need an "overlay" interface at both routers of the overlay network. > c. I create a tunnel connecting those overlay interfaces Yes. Note that neither of these steps has involved security yet. So far, what you have described is setting up an IP tunnel in a virtual topology, and can be done soley with RFC2003. With IIPtran, you then have d. secure the new tunnel using IPsec transport mode which is a orthogonal step (modulo inbound processing as described in the ID). The nice thing about IIPtran is that it decouples security from topology. Deploy your topology with IP tunnels. Then, if you want it secure, turn on transport mode; if not, just leave it. The nice thing about tunnel mode is IKE, actually. There is no comparable protocol to set up IP tunnels. (There should be, however, and tunnel negotiation should be stripped from IKE - but that's a topic for another thread :-) > Both IIPtran, and tunnel mode IPsec with 0.0.0.0/0 selectors can accomplish > this; the latter just seems more direct. (At least, when implementing from > certain starting points -- I understand you are working within the > constraints of an existing platform/stack.) 0.0.0.0/0 selectors seem to require a certain order of operations during outbound processing (forwarding over physical interfaces before IPsec matching), otherwise you could get encapsulation loops. IIPtran does not depend on implementation side effects. >>These two solutions are equivalent in function, but different in >>complexity. #2 implies that all SPDs have either one or more transport >>mode SA, or exactly one tunnel mode SA (and no transport mode SAs). This >>ends up treating tunnel mode as a special case w.r.t. association with >>devices, for an indirect (routing) reason. > > I don't follow that. I think #2 by definition involves tunnel mode SAs; > that is how it is isolating the overlay traffic. Each virtual link would > *typically* consist of a single bidirectional SA pair. However, it could > conceivably consist of an aggregate of any number of SA pairs, so long as > a) they all go to the same overlay next hop, and b) the union of all their > selectors is 0.0.0.0/0, i.e. between them all they will admit any packet. > In any event, what is the special case with respect to devices you mention? You must enforce that your SA pseudo tunnels are only ever associated with exactly one tunnel mode SA (or a non-overlapping combination as you said), otherwise you'd see encapsulation loops. You then need to furthermore enforce that all non-tunnel devices only ever get associated with transport mode SAs, otherwise you again get tunnels that aren't represented in the routing table, and you're back at square one. These seem like strong indications that encapsulation is an interface capability, not an SA one. Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature