Hi Yoav, My replies below. Thanks a lot for your thoughtful comments and I am sorry for the delays.
Section 4.1: > > Point #1: While less configuration required is better, I would like there > to be some absolute requirements. Like, changing or adding a spoke requires > no changes to other spokes. Or changing any node does not require changing > any other nodes where the static configuration does not include that node. > > Speaking of which, I think a good criterion for evaluating proposals is > the amount of required static (or "manual") configuration. > VM> I agree we need absolute requirements. The point we were trying to stress was that though we know not having any changes in some cases may not be possible it should be a requirement to minimize the changes in configuration. I will look at the various cases as you suggest and then put in more exact requirements. > Point #3: What is "tunnel binding"? > I have heard similar concerns from Steve Hanna on the requirements too. The idea here is that we should allow applications like OSPF, to work over the tunnels irrespective of the end point addresses.Let me know if I am clearer. > > Point #4 is unclear. If spokes talk to other spokes, in what way are they > spokes? Sounds like a mesh to me. If you mean that the administrator(s) > begin by statically configuring a star topology, and it automagically > morphs into a mesh, this should be said explicitly. > This requirement comes from the way Enterprise WAN architecture is. The branches connect to the data centers in a Hub-and-Spoke topology using IPsec tunnels. However spokes are optionally and temporarily allowed to connect to each other for traffic such as voice etc which does not gain from taking an extra hop to the data center. I will clarify the point. > Point #6: I'm not sure what a handoff is. If it's a single host moving > from behind one peer to behind another peer, I don't see how this can be > required. VPN gateways are often combined with stateful firewalls, which > typically refuse to allow a TCP connection to proceed. > It is for that purpose the draft says the protocol should avoid packet loss when possible. If there are external factors like firewalls, they need to be dealt with separately. > > Point #9: I think there's an expired draft for an IPsec MIB. But that's > not what I meant in Vancouver. We are adding dynamic changes to the > configuration. These changes should be logged and reported to facilitate > trouble-shooting. With static configuration, if you haven't touched the > configuration and things stopped working, you can look at gateways failing, > at network errors, expired certificates, or any number of other issues that > administrators know about and can look for. A dynamically changing > configuration is a new possible source for errors, one that is currently > not reported. So if gateway A believes that packets to host H should be > forwarded through gateway B, but gateway B applies a DROP rule to all such > packets, we need reporting of the configuration changes on both gateways to > see how this thing happened. > I agree this is a good requirement and I will update the draft with the same. Thanks, Vishwas > > Yoav >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
