Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

2012-03-21 Thread Yoav Nir
direct endpoint-to-endpoint connectivity may not be possible if both endpoints are NATed Why? There are several protocols (SIP/RTP come to mind) that manage endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't IPsec endpoints do this? If this requires some new NAT

Re: [IPsec] P2P VPN draft UNCLASSIFIED

2012-03-21 Thread Manish Kumar
Although I prefer it over some of the other names, discovery isn't making too good an adjective here. How about Dynamic Secure VPN without over qualifying dynamic ? Thanks, Manish On 19/03/12 1:27 PM, Yoav Nir y...@checkpoint.com wrote: As Tero pointed out, some of the use cases don't end up

Re: [IPsec] [ipsecme] #210: What should we call this effort?

2012-03-21 Thread Manish Kumar
How about Dynamic Secure VPN ? Thanks, Manish On 21/03/12 6:55 AM, Stephen Hanna sha...@juniper.net wrote: Here's the first issue. So far, it has been the most contentious one! Interesting that it's the least technical issue. H. Anyway, if you're not happy with the proposed

[IPsec] SUSPENSION OF THREAD #210: What should we call this effort?

2012-03-21 Thread Paul Hoffman
chair hat == on Steve posted a large number of interesting technical questions that have been asked about the document. Spending energy on those is *much* more important to the WG than deciding the name. Further, some of the answers of those questions will help choose the best name. I will

Re: [IPsec] FW: [ipsecme] #211: We should talk more about why this is a hard problem.

2012-03-21 Thread yogendra pal
1. Let us not say this is a hard problem, it sounds like NP hard problem (which indeed it's not) Just rephrasing it, Suggested Resolution: Add a Requirements section that lays out the problems that any solution must address. #211: We should talk more about why this is a hard problem. This topic

Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed.

2012-03-21 Thread Vishwas Manral
Hi Stephen, Sounds good to me. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:29 PM, Stephen Hanna sha...@juniper.net wrote: Third issue. Steve -Original Message- From: ipsecme issue tracker [mailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:57 PM To:

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

2012-03-21 Thread Vishwas Manral
Hi Steve, Branch routers have 3G/ 4G interfaces as backups for the primary interface and sometimes even multiple 3G/ 4G interfaces with no wired interface at all to the backend. I however do not see any issue that occurs as a result of this. Currently if an interface goes down the tunnel is torn

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Vishwas Manral
Hi Steve, I think this is an important requirement for sure. Thanks, Vishwas On Tue, Mar 20, 2012 at 6:36 PM, Stephen Hanna sha...@juniper.net wrote: Another issue to comment on. Steve -Original Message- From: ipsecme issue tracker [mailto:t...@tools.ietf.org] Sent: Tuesday,

Re: [IPsec] [ipsecme] #216: Multiple interfaces or mobile endpoint

2012-03-21 Thread Stephen Hanna
This issue was based on Michael Richardson's March 12, 2012 email where he said: Finally, say my laptop is normally part of such a mesh (as a /32,/128 subnet). When I'm trapped behind a NAPT, I naturally use NAT-traversal to get out and join the MESH. Now, what happens if I come to the office,

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

2012-03-21 Thread Stephen Hanna
Again, this issue was based on Michael Richardson's March 12 email, which said: The dual trunk scenario should perhaps be further motivated and clarified. Are there some situations where a spoke should not contact another spoke directly, but in fact should contact a hub closer to the other

Re: [IPsec] [ipsecme] #212: Section 2.2 should be more detailed.

2012-03-21 Thread Geoffrey Huang
I agree. I believe this is a common use case. -geoff From: Vishwas Manral vishwas.i...@gmail.commailto:vishwas.i...@gmail.com Date: Wed, 21 Mar 2012 12:14:26 -0700 To: Steve Hanna sha...@juniper.netmailto:sha...@juniper.net Cc: ipsec@ietf.orgmailto:ipsec@ietf.org

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Geoffrey Huang
I don't understand what temporary credentials means. If the intent is to have some transitive authentication (or redirection of trust hierarchy, at least) between a gateway and two spoke devices, which are trying to establish an ad-hoc connection, then I agree this would be important to have.

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Yaron Sheffer
The point of temporary credentials is that if these spokes normally use EAP or PSK to authenticate to the gateway, they cannot use these same credentials to auth to one another (because that would expose each spoke to impersonation by the other one). So to support this scenario we must have

Re: [IPsec] [ipsecme] #217: Temporary credentials

2012-03-21 Thread Praveen Sathyanarayan
Yes. If certificate based authentication was used in the network, there is no need of new credentials. But if pre-shared key based was used, then we need this temporary credentials. Also, it is required to define the lifetime of this temporary credentials. For example, if tunnel between spokes are

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

2012-03-21 Thread Yoav Nir
I agree that this pre-supposes that the solution will involve gateways figuring things out for endpoints in either one step or more than one step. It pre-supposes a two-tier system. We've had a presentation in Taipei that did not involve gateways, but rather specialized servers carrying

Re: [IPsec] [ipsecme] #218: Exhaustive configuration

2012-03-21 Thread Yoav Nir
+1 Not only IP addresses, but actual peers may come and go. A user database changes every day as employees (for example) come and go. On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote: Hi Steve, Like I mentioned the problem is not just exhaustive configuration but also the fact that

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

2012-03-21 Thread Yaron Sheffer
Hi Steve, Yoav, I don't want to speak for MCR, but I think you are taking his question too far towards the implementation aspects. What I read in the question is, do we allow for a situation where (by policy and/or because of limitations in the solution) an endpoint cannot connect directly to

Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

2012-03-21 Thread Stephen Hanna
If that's the topic, we already have an issue (#213) for it. Let's see if MCR will clarify what he meant here. Thanks, Steve -Original Message- From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] Sent: Wednesday, March 21, 2012 7:04 PM To: Yoav Nir Cc: Stephen Hanna; IPsecme WG

Re: [IPsec] [ipsecme] #213: In use case 2.1, direct endpoint-to-endpoint connectivity may not be possible

2012-03-21 Thread yogendra pal
I agree to what Yoav stated, that signalling part (SIP) and media part (RTP) both SHOULD work even if there is NAT in the configuration today. However, I could not get why we need to have new NAT traversal mechanism using hub gateway, can you elaborate on this... Thanks and Regards, Yogendra Pal