Mark Duffy wrote: ... > The draft describes using IP-in-IP tunnelling and securing the result with > transport mode IPsec (IIPtran). Why choose this approach over simply > negotiating tunnel mode IPsec with wild-card selectors (i.e. 0.0.0.0/0) and > then at a higher level using the routing decision to choose which tunnel to > use? Mainly because current IP routing daemons already work over IPIP tunnels, while you'd have to re-implement them at that higher level and make them aware of IPsec SAs. IP routing is based on the notion of directly connected interfaces - the problem with some IPsec tunnel mode implementations is that their SAs are not interfaces. > IIPtran may appear to retain more vestiges of IPsec policy (i.e. the policy > being to apply transport mode IPsec to all traffic between the tunnel end > points) but I believe this is illusory as in fact the same packets get the > same IPsec treatment with IIPtran as with the wild-card selectors approach. > In the final analysis, both approaches make the entire decision based only > on the overlay forwarding table. As Joe said, IIPtran allows current protocols to work on overlays without modifications. Of course you can reimplement them all to be aware of IPsec SAs, but why would you? > I get a hint from reading the draft that the proposal may be motivated by > an implementation environment where there is already a platform with an IP > stack and IPsec embedded in it, and it is desired not to change the IPsec > implementation or its relationship to the rest of the IP stack. Is that > the reason for this choice of approaches? We are mostly based on KAME right now, which IMO is an excellent implementation of the IPsec specs, including tunnel mode. We're not hacking around a broken stack; we really believe that IIPtran is the right thing to do :-) Lars -- Lars Eggert <larse@isi.edu> Information Sciences Institute http://www.isi.edu/larse/ University of Southern California
S/MIME Cryptographic Signature