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?
Mike ----- Original Message ----- From: Ulliott, Chris To: 'sha...@juniper.net' ; 'ipsec@ietf.org' Sent: Tuesday, November 22, 2011 2:06 PM Subject: Re: [IPsec] Preparing a charter change for P2P VPN UNCLASSIFIED Classification:UNCLASSIFIED I think the problem as stated represents the issue quite well although I'd be tempted to add discovery to the list of issues. What I've taken awa from the various debates is that there are differing views as to whether the problem can be sorted by combining existing RFC's in a standard way or whether we need a new RFC for some (yet to be agreed) gaps. Personally, from trying to do this with a practical deployment, discovery seems to be the only gap - so perhaps a good way forward would be to take the use cases in the draft and then expand on them. From this, we can work out if there are any gaps? It's not as formal as a requirements document, but could work to help everyone better understand the problem. Chris [This message has been sent by a mobile device] ----- Original Message ----- From: Stephen Hanna [mailto:sha...@juniper.net] Sent: Monday, November 21, 2011 08:09 PM To: ipsec@ietf.org WG <ipsec@ietf.org> Subject: [IPsec] Preparing a charter change for P2P VPN The conclusion of Wednesday night's P2P VPN side meeting was that we would start a new thread on the proposed ipsecme charter change and resolve the open questions by email. Let's start off with the text that came out of Wednesday's meeting and the questions raised there. The text from the meeting describing the problem to be solved was: In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. And the main open questions from the meeting were: * Should we create a problem statement and requirements draft? * Should we create a Standards Track document with the solution or just document existing proprietary vendor solutions in Informational RFCs? Please respond to this email with comments on the problem description text and on the questions. I think we need to reach consensus on those basic matters before we can work on final proposed text for the charter change. Thanks, Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmas...@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491 ext 30306 (non-secure) or email info...@gchq.gsi.gov.uk **************************************************************************** The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
