I agree with Paul H. that the term "encryption domain" is not really fully correct for this problem set and its scenarios. I also apologize for lurking for quite some time before chiming in. I'd also rather avoid marketing-related jargon of any given vendor.
Before I make further comment, let me state that I do agree there is an aspect of the large scale mesh VPN problem that is not covered by RFC 4322, and I don't think DNSSEC resolves matters. In other words, I do think there is a problem set for certain scenarios for which a solution is still needed. One that is vendor agnostic. On Oct 29, 2011, at 3:34 PM, Yoav Nir wrote: > OK. So DNSSEC is off the table. At least for now. > > At least with Chris's scenario, we can assume that there's an > "administrative domain" that includes a "hub" and some "spokes". This > "hub" has information about the addresses protected by each of the > "spokes", so it makes sense that it will do the "introductions". (BTW: all > the terms in quotes will need a proper definition in the draft). > Alternatively, the "introductions" can be done by yet another node that's > dedicated to these introductions. > > So the administrator of this administrative domain may not need to > configure a lot of tunnels, but he or she still needs to configure all of > the encryption domain of all the spokes on the introduces, but at least > that's only one place. The concept of the trusted introducer and the hub with some knowledge of the architecture of the spokes is one part of the set. I think that there are use cases where a large scale mesh VPN would be desired between hosts that actually encompass more than this, however. Were we to assume a basic hub-spoke, we come back to the way the problem has attempted to be addressed. But the issue was that we were trying to remove or negate the overhead added to the hub to coordinate introductions and/or facilitate the actual IPsec work, creating more tunnels, configuration mess, etc. Right? I'd like to see a way, without having to muck with a client configuration, for example, where the client may want to query multiple hubs. The mesh may be several layers of hub and spoke, and there may be different trust levels between them. This could be because there are networks that are handled by one or more of the gateways for redundancy (e.g., gateway bob isn't available, because of a natural disaster; go talk to gateway alice over there instead and she can get you connected to the spoke you seek. And said multi-hub/multi-spoke is not only useful for redundancy, but also for partner, customer, employee, etc. at different trust levels. I've got to wrap up for the moment, but I will endeavor to flesh it out a bit more tonight. Bottom line, I agree the vendors need a standard way to address the challenges as outlined in the draft and as discussed so far. Hopefully there will at least be consensus in Taipei to continue the exploration and refine the -00 draft. Mark Boltz, CISSP, CISA Stonesoft Inc. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
