Michael, "I don't like that DMVPN does not let http traffic continue to travel via HQ's virus/trojan/netnanny while RTP takes the shortcut."
While I do appreciate that the following could represent a valid used case, it would be inaccurate to say DMVPN doesn't allow this. It does allow but not using the IPSec tools; the protocol programming the forwarding layer(could be policy based) controls what goes via the hub as opposed to what goes on the shortcut tunnel. Also, I would see this more as a path selection problem more than 'the kind of security treatment a certain class of traffic needs' - it's another matter that different paths provide different security services/treatment. Since, the network topology information and hence the path that a class of traffic may take is not privy to IKE/IPSec, it's only appropriate that a protocol aware about this takes this call. This is the reason I don't concur with your other comment about doing this in IKE. Cheers, Manish On 03/11/13 12:47 AM, "Michael Richardson" <[email protected]> wrote: > >{Sorry about that, the email configuration my tablet had a \n in a header >that did not belong} > >I have read all three proposals, although I missed the Q&A in Berlin. >I am looking forward to further Q&A in Berlin. > >When I read the NBMA protocol (DMVPN, I think) version what I saw was a >very >brilliant hack that managed to take two code bases (IPsec and ATM) that >were >likely already present in that vendor's firmware and connect them. >Likely, >it took only a few weeks of brilliant hacking, and it was ready for >customer use. > >I find that this solution for anyone else involves the most amount of new >code, >and I think it will the most difficult to support on various mobile and >laptop >platforms as it requires new encapsulation modes. > >draft-mao-ipsecme is architecturally the closest to me, and I like the ADS >idea: it seems that it be implemented without any new kernel code, and I >think that if we are trying to get remote warrior and branch office RTP >traffic to take a more direct route, then eliminating the need for a more >network plumbing, and just doing things in IKE is the right answer. (%) > >I don't like having a new protocol: I want it in IKE. While it can and >should run inside the tunnel, I don't see why adding a new port to my IKE >daemon makes my life easier. > >I *do* like the way that DMVPN uses probe packets to discover the end >points of >the shorter routes, and I would look forward to including that mechanism >somehow. I don't know how to do that without hacks to the data plane, >which >I'd like to avoid. I can imagine some ways to do this with a traceroute >process, but it seems kludgy and brittle. (really, that's still dataplane, >but it's using an existing mechanism) > >I don't like that DMVPN does not let http traffic continue to travel via >HQ's >virus/trojan/netnanny while RTP takes the shortcut. > > >(%)- the plumbing might need a way to sample 5-tuple flows to see if there >is traffic that should be shortcut. However, various schemes to put more >specific SPD entries in that cause key requests might accomplish this >without >new kernel code. > >-- >Michael Richardson >-on the road- > >-- >Michael Richardson <[email protected]>, Sandelman Software Works > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
