Hi Fred, Comments inline.
Thanks, Praveen On 2/5/14 8:44 PM, "Frederic Detienne (fdetienn)" <[email protected]> wrote: >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 ? [PRAVEEN] Hmm… May be you should re-read our draft. What our draft says that the suggester/hub will suggest what traffic-selctor should be used for establish the tunnel. So each spokes knows exactly what Tsi and Tsr being negotiated. > >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. [PRAVEEN] Again in Tsi and Tsr payload carry that information shortcut suggestion from Hub. If GRE is supported in a particular domain, it should be able to switch to GRE/IPSec. > >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. [PRAVEEN] Sure if needed we will update with the information that is required. This is why we are having discussion isn’t it? ;-) > > >> 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. [PRAVEEN] This is described in Section 5. It explains with example. Please take a look. > >What should they do ? > >Thanks, > > Fred > >> Thanks, >> Praveen >> >> > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
