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

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Mar 2012 21:33:31 -0400

Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]] 
Sent: Tuesday, March 20, 2012 6:59 PM
To: [email-masked]; [email-masked]
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/>

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 21 Mar 2012 12:18:10 -0700

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-masked]> wrote:

> To: [email-masked];
> [email-masked]
> Ticket URL: <
> http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 21 Mar 2012 15:59:26 -0400

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-masked] [mailto:[email-masked]] 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-masked]<mailto:[email-masked]>> wrote:
Please comment on Suggested Resolution. Note that Yaron has
already supplied his comment below.

Steve

-----Original Message-----
From: ipsecme issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 20, 2012 6:59 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [ipsecme] #214: Should gateways figure things out completely or just punt endpoints to a closer gateway?

 yaronf.ietf@...          |  problem@...

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Mar 2012 23:33:53 +0200

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:

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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,

Thanks,
Vishwas

Steve

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 22 Mar 2012 01:04:22 +0200

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
>
>> 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-masked]
>> <mailto:[email-masked]>[mailto:[email-masked]]*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
>>
>> To:[email-masked]
>> <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]>
>> Subject: [ipsecme] #214: Should gateways figure things out completely
>> or just punt endpoints to a closer gateway?
>>
>> Ticket URL:
>> <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/214#comment:1>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 21 Mar 2012 21:01:24 -0400

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

> From: Yaron Sheffer [mailto:[email-masked]]
> 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,
> 
> >> dynamic information. A core gateway (a "hub" in Michael's parlance)
> >> 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
> >> information. At least, that's how I understand Michael's question.
> >> too much about the eventual solution. That's why I think it should
> be
> >> Apparently, Yaron doesn't agree with me. I'd like to hear more from
> >> I described above? What about a solution that doesn't rely on core
> >> 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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 10:37:31 +0200

>>>>> "Stephen" == Stephen Hanna <[email-masked]> 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)

  A                                                        B
   \                                                      /
    \                                                    /
     \                                                  /
      +----+    trunk1    +------+    trunk2     +-----+
      | H1 |==============|  H2  |===============|  H3 |
      +----+              +------+               +-----+
     /                            \
    /                              \
   C                                D

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:

  A                                                        B
   \.....................                                 /
    \                    \                               /
     \                    \                             /
      +----+    trunk1    +------+    trunk2     +-----+
      | H1 |==============|  H2  |===============|  H3 |
      +----+              +------+               +-----+
     /                            \
    /                              \
   C                                D

step2, H2 tells A where B is:

  A........................................................B
   \.....................                                 /
    \                    \                               /
     \                    \                             /
      +----+    trunk1    +------+    trunk2     +-----+
      | H1 |==============|  H2  |===============|  H3 |
      +----+              +------+               +-----+
     /                            \
    /                              \
   C                                D

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 10:42:54 +0200

{fat fingers let previous email got away too soon, ignore}

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)

  A                                                        B
   \                                                      /
    \                                                    /
     \                                                  /

  A                                                        B
   \.....................                                 /
    \                    \                               /
     \                    \                             /

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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 10:47:13 +0200

>>>>> "Yaron" == Yaron Sheffer <[email-masked]> 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?

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2012 11:04:29 +0200

> 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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 11:23:50 +0200

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:

    >> 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 :-)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Mar 2012 13:27:43 +0200

<#part sign=pgpmime>

Actually, in my haste, I skipped a possible step:

  A                                                        B
   \                                                      /
    \.....................                               /
     \                    \                             /

step2, H2 tells A where H3 is:

  A                                                        B
   \............................................          /
    \.....................                      \        /
     \                    \                      \      /
      +----+    trunk1    +------+    trunk2     +-----+
      | H1 |==============|  H2  |===============|  H3 |
      +----+              +------+               +-----+
     /                            \
    /                              \
   C                                D

step3, H3 tells A where B is:

  A........................................................B
   \............................................          /
    \.....................                      \        /
     \                    \                      \      /
      +----+    trunk1    +------+    trunk2     +-----+
      | H1 |==============|  H2  |===============|  H3 |
      +----+              +------+               +-----+
     /                            \
    /                              \
   C                                D