On Tue, 1 Nov 2011, Yoav Nir wrote:
On 11/1/11 4:53 PM, "Mark Boltz" <mark.bo...@stonesoft.com> 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.
freeswan/openswan uses leftsubnet/rightsubnet for that, where "left is the
left side of your diagram". In other words, your own arbitrary choice :)
You could use "local subnet" and "remote subnet"?
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.
Excellent! raw RSA should interop widely, and getting raw public keys
from DNSSEC is but one method to obtain these. They can be fetched from
other sources (secured LDAP, TLS, etc). It would be good to stick to
one representation though so everyone can implement their own key
retrieval method. Similar to how people are now talking about dnssec-chains,
one could piggyback there and define an updated representation for raw
keys from RFC-4025
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
