Hi Fred, My comments inline.
Thanks, Praveen On 2/5/14, 5:42 AM, "Frederic Detienne (fdetienn)" <[email protected]> wrote: Hi Praveen, Sorry about the delay. I am just back from our EMEA company event and have been a lot busier than I planned. > [PRAVEEN] For one-liner question, we could only imagine the scenario that > you are trying to solve. And this is what we could come up. May be you >can > provide more detailed question on what scenario you would like to solve. > We could help in answering those scenarios. > > When admin changes the prefix of a spoke, spoke¹s existing static tunnel > with Hub, gets re-negotatiaged for updated prefix in Tsi/TSr payload. >This > event updates the Hub about changed prefix information. Is that what you > wanted to know? Yes, this is the information I was looking for. So in a nutshell, when a prefix in spoke network is changed, it takes an additional change in the central DB and a tear down of the tunnels. This is not very attractive compared to a routing protocol which can do it instantly and without affecting the other prefixes. Especially in the presence of a large number of prefixes behind spoke(s). Also, I am taking it that there is one such file per spoke ? Or is it one big file containing all the spoke prefixes ? [PRAVEEN] I think you didn’t get my answer. What I was trying to say is, if there is a network prefix change on the spoke side, Spoke renegotiates with Hub (Child SA rekey has TSi and Tsr payload to convey about the address change). Thus Hub would know about the change, without any administrator intervention. There is no file/database to be edited. This is quite similar to what routing protocol would do. I want to re-stress the point. Our solution is not against using routing protocol. If vendor thinks that is the best approach deploy, he/she can do so, just like many vendor already do today. >> >> Before going any further, is this resource exclusively exchanged between >> hub & spoke or also between spokes ? > > > [PRAVEEN] ³resource² you means ADVPN_INFO payload or Subnet information? > ADVPN_INFO exchanged between spokes. Subnet information exchanged part of > Tsi and TSr during IKE negotiation (which means between hub & spoke and > between spokes as well). I mean the ADVPN_INFO pointing to the URL with the list of prefixes. The question is now: who has access to those resources ? Who can update the file(s) on the fileserver(s) ? This raises the whole question about role based management. It also means the change management is now quite complex since in order to update spoke prefixes you also have to change the central prefix files. One of the requirements which was "no change on the central devices when adding a branch" is in contradiction with this method. OTOH, I am pondering that the spokes could automatically update the central file(s) in which case it would not be very different from a routing protocol… [PRAVEEN] It all depends on how you implement. It can be automated as well, if you like to do so. For example, each spoke when establishes a tunnel with the Hub, Hub already knows about the prefixes that spokes protects. This information can be populated to PROTECTED_DOMAIN database automatically. You don’t need any administrator intervention, if you really want to trust such changes. Also, if an administrator would like to prevent such changes, before reviewing it, that can be done as well. Again it depends on how vendor wants productize this neat security feature. Hey, remember that, a south asian ISP advertising I have YouTube (in intention of blocking YouTube in his country), that lead to falsely advertising rest of the world? Don’t you think administrator of a domain want to prevent such things happening in his/her domain? The problem with routing protocol is, it comes with implicit assumption of trust. Yes this good thing in most scenario, but not always. There are administrators who would like to have a better control over their network than just automated way of deploying. Again, if you don’t think that is the case, you can choose to implement with our solution with routing protocol, similar to most vendor (including Cisco and Juniper) who already do that with IPSec today. That provides flexibility that an administrator want out of routing protocol. thanks, fred >> >> thanks, >> >> fred >> _______________________________________________ >> IPsec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
