On Oct 29, 2011, at 1:34 PM, Yoav Nir wrote: > 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"?
I think a better term is "tunnel crypto policy". It's not a contract at all: the "contract" part comes when SpokeA and SpokeB complete the handshake. > 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? Regardless if that is vendor specific, it is not accurate. Part of the tunnel crypto policy is the authentication policy, which has nothing to do with encryption. Further, part of the tunnel crypto policy is the addresses that will be in the tunnel. I assume if SpokeA says to HubX "I want to open a tunnel to 5.6.7.0/24", and the only address policy that SpokeA has that matches that is for 5.0.0.0/8 with the gateway at 5.1.2.3, that HubX would respond with that as a possibility that SpokeA might like. So there are two types of policy: tunnel (address), and crypto (authentication and eventual encryption). At least, that was my picture of the requirements. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
