Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
Stephen == Stephen Hanna sha...@juniper.net writes: Stephen I think that Michael is asking an important question. There Stephen are many ways to solve the P2P VPN problem. One way is to Stephen have satellites with little configuration that connect to Stephen core gateways with lots of dynamic information. A core Stephen gateway (a hub in Michael's parlance) can download things Stephen to a satellite (maybe a new SPD and PAD, credentials, Stephen etc.), thus causing some traffic from the satellite to be Stephen sent to a different core gateway or satellite. In that Stephen circumstance, I think Michael's question is about whether Stephen the core gateway that a satellite initially connects (which Stephen I'll call the initial core gateway) to should be expected Stephen to have or obtain all the information needed to configure Stephen the satellite or whether the initial core gateway can send Stephen the satellite to another core gateway where it can get more Stephen information. At least, that's how I understand Michael's Stephen question. Perhaps he can affirm or deny this Stephen interpretation. You got my question correctly. I'm gonna add a diagram so that everyone can agree. (Those of you with mailers that ignore text/plain; format=fixed, you need to copy this email to Wordpad/vi, or it will be munged by your RFC-ignorant vendor) In the requirements document, I think that we need establish some nomenclature, such as hub. and initial hub, or core, as you wish. Given that goal of this is to go from hub+spoke (generalized to trunk+feeder.. In my spare time I'm actually a transit expert. True story) AB \ / \/ \ / ++trunk1+--+trunk2 +-+ | H1 |==| H2 |===| H3 | ++ +--+ +-+ /\ / \ CD Leaf A has traffic of leaf B. It would otherwise go via Hub1(H1), Hub2, and Hub3. Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol, magic will happen. The question, *AT THE REQUIREMENTS* phase, is whether a solution such as: step1, H1 tells A that H2 is closer: AB \. / \\ / \\ / ++trunk1+--+trunk2 +-+ | H1 |==| H2 |===| H3 | ++ +--+ +-+ /\ / \ CD step2, H2 tells A where B is: AB \. / \\ / \\ / ++trunk1+--+trunk2 +-+ | H1 |==| H2 |===| H3 | ++ +--+ +-+ /\ / \ CD pti Stephen Personally, I think that this question is premature. It Stephen presupposes too much about the eventual solution. That's Stephen why I think it should be answered in the solution not Stephen included in the problem statement. Apparently, Yaron Stephen doesn't agree with me. I'd like to hear more from him on Stephen this matter. Does he believe that all solutions to this Stephen problem (or at least all the good ones) must necessarily Stephen employ the model that I described above? What about a Stephen solution that doesn't rely on core gateways to refer Stephen satellites but instead has satellites querying for the Stephen information that they need? Or one that has some external Stephen entity (not the core gateway) configuring the satellites? Stephen In my view, there may be many possible P2P VPN Stephen solutions. However, I'm not an IPsec expert. Maybe this is Stephen the only practical approach. I'd like to hear views from Stephen Yaron and from others on this topic. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
{fat fingers let previous email got away too soon, ignore}
Stephen == Stephen Hanna sha...@juniper.net writes:
Stephen I think that Michael is asking an important question. There
Stephen are many ways to solve the P2P VPN problem. One way is to
Stephen have satellites with little configuration that connect to
Stephen core gateways with lots of dynamic information. A core
Stephen gateway (a hub in Michael's parlance) can download things
Stephen to a satellite (maybe a new SPD and PAD, credentials,
Stephen etc.), thus causing some traffic from the satellite to be
Stephen sent to a different core gateway or satellite. In that
Stephen circumstance, I think Michael's question is about whether
Stephen the core gateway that a satellite initially connects (which
Stephen I'll call the initial core gateway) to should be expected
Stephen to have or obtain all the information needed to configure
Stephen the satellite or whether the initial core gateway can send
Stephen the satellite to another core gateway where it can get more
Stephen information. At least, that's how I understand Michael's
Stephen question. Perhaps he can affirm or deny this
Stephen interpretation.
You got my question correctly.
I'm gonna add a diagram so that everyone can agree. (Those of you with
mailers that ignore text/plain; format=fixed, you need to copy this
email to Wordpad/vi, or it will be munged by your RFC-ignorant
vendor. Oh, I'll paste it into the ticket too)
In the requirements document, I think that we need establish some
nomenclature, such as hub. and initial hub, or core, as you wish.
Given that goal of this is to go from hub+spoke (generalized to
trunk+feeder.. In my spare time I'm actually a transit expert. True story)
AB
\ /
\/
\ /
++trunk1+--+trunk2 +-+
| H1 |==| H2 |===| H3 |
++ +--+ +-+
/\
/ \
CD
Leaf A has traffic of leaf B. It would otherwise go via Hub1(H1), Hub2,
and Hub3.
Thanks to our new Private Elastic Cloud On-Demand (PECOD) protocol,
magic will happen. The question, *AT THE REQUIREMENTS* phase, is
whether a solution such as:
step1, H1 tells A that H2 is closer:
AB
\. /
\\ /
\\ /
++trunk1+--+trunk2 +-+
| H1 |==| H2 |===| H3 |
++ +--+ +-+
/\
/ \
CD
step2, H2 tells A where B is:
AB
\. /
\\ /
\\ /
++trunk1+--+trunk2 +-+
| H1 |==| H2 |===| H3 |
++ +--+ +-+
/\
/ \
CD
open question whether when H1 told A about H2, whether it in fact told
A about *all* of the topology that H1 knew about H2, or just about A.
Would traffic from A to D go via H2 after step1, or would traffic to D
continue to go via H1/H2?
This speaks to requirements, because if H1 needs to know where B is,
then we need to have a protocol along trunk1 and trunk2 that permits the
information about where B is to be communicated.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE
then sign the petition.
pgp001BO8okTD.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote: Yaron == Yaron Sheffer yaronf.i...@gmail.com writes: Yaron I don't want to speak for MCR, but I think you are taking his Yaron question too far towards the implementation aspects. What I Yaron read in the question is, do we allow for a situation where Yaron (by policy and/or because of limitations in the solution) an Yaron endpoint cannot connect directly to the ultimate peer, but Yaron needs instead to go through some sort of relay. You didn't take my comments too far; I think you realized that I was in fact saying two things: 1) when traffic is redirected, MUST it be redirected directly to the real endpoint? (There might be issues of in-band double NAT that matter if the traffic doesn't get all the way there... I dunno, IPv6 RFC6145 is my answer to double NAT) 2) when traffic is redirected, MAY it be redirected more than once? Aren't these really the same question? My answer is that it's OK for redirection to happen more than once, but it's better to have less redirections than more. IOW it should be a requirement that H1 (in the diagram of your previous mail) be able to send more information about the topology behind H2 than just B is behind H2, such as D and H3 are also behind H2. But A should be required to not expect it. So H1 MUST be able to tell A that B is behind H2. It MAY be able to tell A that D is also behind H2, or that B is actually behind H3, or the actual address of B. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
Yoav == Yoav Nir y...@checkpoint.com writes: You didn't take my comments too far; I think you realized that I was in fact saying two things: 1) when traffic is redirected, MUST it be redirected directly to the real endpoint? (There might be issues of in-band double NAT that 2) when traffic is redirected, MAY it be redirected more than once? Yoav Aren't these really the same question? case1: Q1:yes, Q2: yes. Must redirect to final end point, but it is okay for redirection to occur multiple times. This implies that when A is redirected to H2, that no SA is created with H2, but rather there is an immediate redirection to H3, and again to B. case2: Q1:yes, Q2: no Must redirect to final end point, but redirection not permitted. H1 must get address of B via magic and tell A about it. case3: Q1:no, Q2: yes. final end point not required, multiple redirection. H1 can redirect to H2. A sends traffic to H2. H2 can decide to send a new redirect to H3 based upon seeing what traffic is arriving. (Note that B might get redirected by H2 for traffic for A to H2, and now we have A--H2--B, and now H2 actually knows about both A and B, and either easily link them directly, or realize that neither are directly reachable, and since H2 has plentiful bandwidth, it doesn't care...) case4: Q1:no, Q2: no. H1 should either redirect to B directly, or can redirect to H3, but H1 has to know whether or not B is directly reachable. At the same time, H3 might be redirecting B to H1 if A is not reachable, and we might have asymmetric routing. This might screw the SPD on A and B if your SPD is strict 4301. Yoav IOW it should be a requirement that H1 (in the diagram of your Yoav previous mail) be able to send more information about the Yoav topology behind H2 than just B is behind H2, such as D and Yoav H3 are also behind H2. But A should be required to not expect Yoav it. Yoav So H1 MUST be able to tell A that B is behind H2. It MAY be Yoav able to tell A that D is also behind H2, or that B is actually Yoav behind H3, or the actual address of B. So, you just created a requirement for H1-H2 communication :-) pgpy386mRbhY6.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
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] 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.netmailto: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.orgmailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.i...@gmail.commailto:yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.orgmailto: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.orgmailto:IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
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.orgmailto: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.netmailto: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.orgmailto:t...@tools.ietf.org] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.i...@gmail.commailto:yaronf.i...@gmail.com; draft-ietf-ipsecme-p2p-vpn-prob...@tools.ietf.orgmailto: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
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:*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
Re: [IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
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 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:*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
[IPsec] [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?
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] Sent: Tuesday, March 20, 2012 6:59 PM To: yaronf.i...@gmail.com; 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 https://www.ietf.org/mailman/listinfo/ipsec
