On 11/1/11 4:53 PM, "Mark Boltz" <[email protected]> wrote:
>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. Having been working for the same vendor for 10 years, I've gotten used to our marketing jargon. Anyway, I'd like to have some short term for "the set of addresses that are behind a certain gateway", or "the set of addresses that you can reach through a tunnel to gateway x". I'm used to calling that "x's encryption domain", but I'm open to suggestions for a new catchy term. > >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. That is the original motivation. Some vendors have some way of doing this as long as all gateways are from that vendor, but some government users (represented by Chris Ulliot) are not willing to lock their entire government infrastructure to a single vendor. > >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. Good. So will you be in Taipei and attend the side meeting? Yoav > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
