Hi Chris, Thanks a lot for your comments, my points inline:
On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris < [email protected]> wrote: > Apologies for the delay in replying... > > I think the Gateway to gateway use case (para 2.2) doesn't cover the > problem I'm suffering. What if the use case was reworded such that it says > something along the lines of: > > -- start -- > > A typical Enterprise traffic model is hub and spoke, with the gateways > connecting to each other using IPsec tunnels. > > However for the voice and other rich media traffic that occupies a lot of > bandwidth or is performance sensative, the traffic tromboning to the hub > can create traffic bottlenecks on the hub and can lead to an increase in > cost. A fully meshed solution is would make best use of the available > network capacity and performance but the deployment of a fully meshed > solution involves considerable configuration, especially when a large > number of nodes are involved. For the reasons of cost and manual error > reduction, it is desired that there be minimal configuration on each > gateway. VM> I agree adding the point of Full mesh having more configuration is an issue and will add it to the text. However another issue we see is that in a Full Mesh we need connectivity between all nodes which means that the weakest link is the Branch device, that is another reason we have a hub and spoke with the mesh cross connections on demand. It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration) VM> I agree we should state this in the requirement explicitly and is critical to the solution. When two gateways communicate, they must use a mechanism for authentication, such that they do not expose themselves to the risk of impersonation by the other entities. VM> Sounds good. -- end -- In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical. VM> Agree.We call it star with temporary mesh connection, I agree we can call it dynamic mesh connectivity instead. In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed? VM> I am ok with that, my point was we need to configure profiles when a device is added, we do not need to reconfigure if we find devices of the same profile. For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much. VM> I think the problem of network cost is that of routing. We need a way for policy to determine when to transfer a connection from one gateway to another. The solution should allow for such signalling though. Thoughts? VM> Great comments, which I can see come from real world usecases. Thanks, Vishwas Chris > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Paul Hoffman > Sent: Saturday, September 08, 2012 5:31 PM > To: IPsecme WG > Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements > > This appeared on the list over two weeks ago and it has received no > comments since. This is supposed to be the WG's main work item, folks. > > --Paul Hoffman > > On Aug 23, 2012, at 9:02 AM, Stephen Hanna <[email protected]> wrote: > > > Vishwas and I have updated the AD VPN Problem Statement > > and Requirements draft to address the comments received > > on the previous version and remaining comments from > > earlier email discussions. The new version is available at > > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem > > > > A summary of the changes in this version is included at > > the end of this message. > > > > Please review this document and provide any comments on > > the existing requirements or suggestions for new ones. > > > > For requirement 3, Vishwas will be starting an email > > thread soon so that the WG can discuss what this text > > means, whether we want to keep it, and how it can be > > made clearer. > > > > Thanks, > > > > Steve > > > > ------------ > > > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > > > * Changed draft name from p2p-vpn to ad-vpn. > > > > * Added a paragraph for each requirement, explaining how > > that requirement is driven by the use cases. > > > > * In requirement 1, defined what we mean by minimizing > > configuration changes. > > > > * In requirement 2, explained that this requirement implies > > that SPD entries and other configuration based on peer > > IP address will need to be automatically updated when > > the peer's IP address changes. > > > > * Split requirement 4 into two requirements (now 4 and 5). > > > > * In requirement 6 (formerly 5), explained what we mean > > by "easy handoff of sessions": avoid TCP session breakage > > and packet loss, when possible. > > > > * In requirement 8 (formerly 7), acknowledged the difficulty > > of handling cases where gateways are behind NATs or where > > two endpoints are both behind separate NATs. In those cases, > > we may need to use workarounds such as port forwarding by > > the NATs or falling back to a hub and spoke architecture. > > > > * Added new requirement 9 around manageability. > > > > * Added new requirement 10 around cross-organization use. > > > > * Added new requirement 11 saying that administrators should > > be able to limit topologies for security and other reasons. > > > > * Fixed typos and other minor wording issues. > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > **************************************************************************** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify [email protected]. > > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > GCHQ on 01242 221491 ext 30306 (non-secure) or email > [email protected] > > > **************************************************************************** > > > The original of this email was scanned for viruses by the Government > Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide > in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On > leaving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored and/or > recorded for legal purposes. > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
