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 the
ultimate peer, but needs instead to go through some sort of relay.
Given this reading of the issue, I think this is something that's still
at the requirements level and we should agree whether we want it as an
actual requirement.
Thanks,
Yaron
On 03/21/2012 11:33 PM, Yoav Nir wrote:
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 authoritative information, with all
the IPsec hosts, whether gateways or endpoints querying those servers.
Those servers could be specialized IPsec information servers, dispensing
PAD and SPD entries through a web service, or they could be the DNS
system. Either way, this is a different model to the one that has the
information flowing through the overlay network.
So I agree that answering this question is pre-mature. Whatever the
model, there will be an equivalent question, but I think it's too early now.
Yoav
On Mar 21, 2012, at 9:59 PM, Stephen Hanna wrote:
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 spoke. I can see some solutions where a hub would not have
complete knowledge of the mesh, and so would in fact simply punt a
connection closer.
I hope this clarifies the issue for you.
I think that Michael is asking an important question. There are many
ways to solve the P2P VPN problem. One way is to have satellites with
little configuration that connect to core gateways with lots of
dynamic information. A core gateway (a “hub” in Michael’s parlance)
can download things to a satellite (maybe a new SPD and PAD,
credentials, etc.), thus causing some traffic from the satellite to be
sent to a different core gateway or satellite. In that circumstance, I
think Michael’s question is about whether the core gateway that a
satellite initially connects (which I’ll call the “initial core
gateway”) to should be expected to have or obtain all the information
needed to configure the satellite or whether the initial core gateway
can send the satellite to another core gateway where it can get more
information. At least, that’s how I understand Michael’s question.
Perhaps he can affirm or deny this interpretation.
Personally, I think that this question is premature. It presupposes
too much about the eventual solution. That’s why I think it should be
answered in the solution not included in the problem statement.
Apparently, Yaron doesn’t agree with me. I’d like to hear more from
him on this matter. Does he believe that all solutions to this problem
(or at least all the good ones) must necessarily employ the model that
I described above? What about a solution that doesn’t rely on core
gateways to refer satellites but instead has satellites querying for
the information that they need? Or one that has some external entity
(not the core gateway) configuring the satellites? In my view, there
may be many possible P2P VPN solutions. However, I’m not an IPsec
expert. Maybe this is the only practical approach. I’d like to hear
views from Yaron and from others on this topic.
Thanks,
Steve
*From:*ipsec-boun...@ietf.org
<mailto:ipsec-boun...@ietf.org>[mailto:ipsec-boun...@ietf.org]*On
Behalf Of*Vishwas Manral
*Sent:*Wednesday, March 21, 2012 3:18 PM
*To:*Stephen Hanna
*Cc:*IPsecme WG
*Subject:*Re: [IPsec] [ipsecme] #214: Should gateways figure things
out completely or just punt endpoints to a closer gateway?
Hi Steve,
This is unclear to me. Isn't it routing that we send a packet across
to a closer gateway/ router? What does everything mean in the question
below?
If we are talking about say security and routing, I think that is
true. The "logical" gateway (could be multiple interactions and
devices) should be able to provide the functionality.
Thanks,
Vishwas
On Tue, Mar 20, 2012 at 6:33 PM, Stephen Hanna <sha...@juniper.net
<mailto:sha...@juniper.net>> wrote:
Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.
Steve
-----Original Message-----
From: ipsecme issue tracker [mailto:t...@tools.ietf.org
<mailto:t...@tools.ietf.org>]
Sent: Tuesday, March 20, 2012 6:59 PM
To:yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>;draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org
<mailto:draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.org>
Subject: [ipsecme] #214: Should gateways figure things out completely
or just punt endpoints to a closer gateway?
#214: Should gateways figure things out completely or just punt
endpoints to a
closer gateway?
Suggested Resolution: We should not specify this in the problem statement.
It should be specified in the solution.
YS: sounds like a requirements-level question to me.
--
-------------------------+-------------------------------------------------
Reporter: | Owner: draft-ietf-ipsecme-p2p-vpn-
yaronf.ietf@… | problem@…
Type: defect | Status: new
Priority: normal | Milestone:
Component: p2p-vpn- | Severity: -
problem | Keywords:
Resolution: |
-------------------------+-------------------------------------------------
Ticket URL:
<http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1>
ipsecme <http://tools.ietf.org/ipsecme/>
_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
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
