On Nov 29, 2011, at 2:38 AM, Paul Hoffman wrote: > > On Nov 28, 2011, at 4:11 PM, Michael Ko wrote: > >> I agree that discovery is one of the issues that should be explored. Due to >> the dynamic nature, automated discovery is an important requirement for the >> user to set up a secure connection with an authorized network node. For a >> direct end-to-end connection between two parties when both are located >> behind different NATs, TURN resorts to the use of publicly addressable >> rendezvous servers. Can the existing proprietary vendor solutions discussed >> in the side meeting handle this situation? > > When people here advocate for "discovery", what do they mean? Do you mean: > > - hubs can receive information from the spokes about what addresses the spoke > gateways protect > > - hubs can proactively go out and find spokes and then ask what addresses > each spoke gateway protects > > - something else
I would define discovery something like this: Node A (either a client or a gateway) has a packet bound for host 194.29.35.43. It asks "the universe" how to encrypt traffic to that host: - What is the address of the gateway protecting 194.29.35.43 (could be the host itself, or could be none) - What ID and credential (certificate or PSK) will the peer show - What ID and credential should I show - What other addresses does this gateway protect In this discovery process, "the universe" could be a pre-configured hub (pretty much what the Cisco and Juniper solutions do), a special-use server (as in the architecture in Michael's presentation) or maybe the DNS. But all this data needs to be returned. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
