To establish a secure connection between two authorized network nodes, some of the critical management tasks that are required include the following:
1. Discover if the network nodes that a user is authorized to access are currently online and active. (One can always resort to timeouts to determine if the peer is online or not, but being able to ascertain the status of the peer quickly would be nice.) 2. Discover the functional attributes associated with these authorized network nodes. 3. Discover the location of the authorized network nodes. (E.g., current IP address) 4. Determine if accessing the network node requires going through a relay (e.g., TURN). Discover the location of the relay if it is needed. 5. Determine the parameters needed to establish a secure connection between the two network nodes. 6. Discover, via inquiry or advertisement, other authorized network nodes as they become active and available. If we use the hub as the entity to provide this "discovery" function, then the statement "hubs can receive information from the spokes about what addresses the spoke gateways protect" comes closest to meeting the requirment, although the information to be "discovered" include the above list and goes beyond just addresses. Mike ----- Original Message ----- From: Paul Hoffman To: IPsecme WG Sent: Monday, November 28, 2011 4:38 PM Subject: [IPsec] Discovery (Was: Preparing a charter change for P2P VPN) 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 --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
