|Main Archive Page > Month Archives > ipsec archives|
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.
What is a "crypto contract"?
Also, my company calls the addresses protected by a particular IPsec node
an "encryption domain". Can we use this term, or is it too vendor-specific?
On 10/29/11 6:16 PM, "Jorge Coronel" <firstname.lastname@example.org> wrote:
>I agree DNSSEC cannot be assumed, its deployments have been marginal.
>I also agree with the need of an ad-hoc peer-to-peer VPN bypassing
>gateways. While there are implementations from multiple vendors,
>including the one I work for, there is no standardized/scalable solution
>for the problems associated with these scenarios. Key challenges are:
>- Discoverability of suitable peers
>- Discovery of the set of crypto contracts required if allowed
>I wonıt be able to attend the IETF meeting in Taiwan, however once the
>date and time is settled Iıll coordinate with someone representing my
>company to attend the BOF meeting.
IPsec mailing list