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
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
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
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
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
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:
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
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,
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,
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
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
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.
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
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
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
+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
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
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
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
19 matches
Mail list logo
