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:[email protected]] > Sent: Wednesday, March 21, 2012 7:04 PM > To: Yoav Nir > Cc: Stephen Hanna; IPsecme WG > Subject: Re: [IPsec] [ipsecme] #214: Should gateways figure things out > completely or just punt endpoints to a closer gateway? > > 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:*[email protected] > >> <mailto:[email protected]>[mailto:[email protected]]*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 <[email protected] > >> <mailto:[email protected]>> wrote: > >> Please comment on Suggested Resolution. Note that Yaron has > >> already supplied his comment below. > >> > >> Steve > >> > >> -----Original Message----- > >> From: ipsecme issue tracker [mailto:[email protected] > >> <mailto:[email protected]>] > >> Sent: Tuesday, March 20, 2012 6:59 PM > >> To:[email protected] > >> <mailto:[email protected]>;draft-ietf-ipsecme-p2p-vpn- > [email protected] > >> <mailto:[email protected]> > >> 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 > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/ipsec > >> _______________________________________________ > >> IPsec mailing list > >> [email protected] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
