Hi Praveen, I suppose it would be convenient for you to minimize DMVPN to a "routing solution" however draft-detienne covers more than that.
The remote access client case is fully covered. Without routing protocol. This point was clarified sometime in November (I believe) and draft-detienne was updated accordingly. Now back to the discussion, I think I now do understand precisely how you see the negotiation going. It turns out we support all these methods already and we know the complexity of it. I would like to verify a few more points because it is not trivial at all. What I am exposing here is that draft-sathyanarayan will quickly grow out of control as it tries to encompass all possible negotiation methods. In practice, it means only a couple vendors will be able to implement it decently and will likely clash quite hard. All this at the expense of users who are lured by failed promises. More inline on this topic then I will slowly move on to the next points. Thanks, Fred (sent from mobile) > On 06 Feb 2014, at 00:31, "Praveen Sathyanarayan" <[email protected]> > wrote: > > Hi Fred, > > I see draft-detienne¹s view of discovery of tunnel-peer is a routing > issue. So DMVPN solution predominantly a routing solution. So, > draft-detienne may work good for routing vendors. > But it is not a solution for non-routing vendors. As an example, mobile > devices increasingly can do more features like FaceTime/Skype/Hangout, > Airdrop. To do these, expecting mobile devices to run BGP protocol, to > discover a direct tunnel is not a reasonable expectation. Or for that > matter expecting a firewall device to run routing protocol, is not a > reasonable expectation either. > > More comments inline. > > > Thanks, > Praveen > > > > On 2/5/14, 5:45 AM, "Frederic Detienne (fdetienn)" <[email protected]> > wrote: > >> We can no longer call that a simple solution. There are pieces that meet >> some of the requirements but are in contradiction with others. > >> Similarly, draft-sathyanarayan offers multiple implementation or >> deployment systems (policy based or tunnel based) which are not >> compatible at protocol level. It means implementations have to cover BOTH >> methods to guarantee interoperability. > > [PRAVEEN] I disagree. How will a spoke running OSPF and other spoke > running BGP interop in draft-detienne? Your answer was, (previously in > virtual conference) was that it does not matter. Because, as long as Hub > supports both routing protocols, there is no issue. The same thing applies > here. If you have route based implementation on a SpokeA and Policy based > implementation SpokeB, it can still open a direct IPSec tunnel without > causing any interoperability. And of course, there is no need of running > routing protocol between the spokes, even in our solution. The big difference is here: domain1 can deploy a routed based network only by picking a vendor focusing on that method only. In this case, the TSi TSr may be 0.0.0.0/0 0.0.0.0/0 Domain2 may deploy a pure policy based implementation. Now how does domain 2 accept domain1's proposals ? And vice versa ? As you explain below, the route based method probably has to fall back to a policy type negotiation. If domain1 admin made that choice, one can assume there is a reason. Now we end up with a double negotiation method. Also how does spoke domain 1 initiate to hub domain 2 ? How does that hub know how to narrow down the TSi to ? It does not know that spoke yet... What now if domain 3 wants GRE/IPsec ? I remember an early email saying it can be negotiated too. Draft-sathyanarayan possibly allows any protocol to be negotiated but it focuses on the policy based method and does not mention at all how interop is achieved. > To take a practical example: one domain may initially be rule based, the > other tunnel based. What happens when those domains must now cooperate ? > > > Both issues above will prevent proper cross-domain interoperability. In > particular, a "policy-based" spoke will not be able to talk to a "tunnel > based" hub as per this draftŠ it would take a decision as to which is the > fallback mode and a dual implementation on at least one of the devices. > > > [PRAVEEN] No issues here. As long as you support rfc5996, and you exchange > TSi and Tsr payloads, you are ready to setup a tunnel and forward the > traffic. On route based VPN side, you get TSi and TSr payload that defines > the SPD entries. These SPD entries are bound to your tunnel interface. > Route that exist before the shortcut tunnel, still points to tunnel > interface. As this tunnel-interface is now has dynamic SPD entries, it now > knows how to forward all/selective traffic to the shortcut tunnel. And of > course the Policy based domain side it is straight forward. Where do you > see the issue? So I presume TSi TSr of the routed spoke will be 0.0.0.0/0 0.0.0.0/0 ? This then gets narrowed down by the policy spoke ? We would create a tunnel per peer to achieve that. Your comment is interesting however as it raises a complexity. On a policy spoke1, the initial policy is 10.0.0.0/24 10.0.0.0/8 to hub Then spoke2 is discovered hosting 10.0.1.0/24 Now the SPD says 10.0.0.0/24 10.0.0.0/8 to hub 10.0.0.0/24 10.0.1.0/24 to spoke2 I know implementations that will not behave well in this case. The SPDB does not guarantee a best match or sorted search. What should they do ? Thanks, Fred > Thanks, > Praveen > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
