On 11/1/11 7:49 PM, "Paul Wouters" <p...@xelerance.com> wrote:
>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"? It's not necessarily a single subnet. It could be an entire corporate LAN with multiple subnets. > >>> 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 Raw RSA keys work. If there is an introducer that tells both sides about each other, a shared secret also works. Shared secrets are very secure if you generate them randomly. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
