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

From: Michael Richardson <mcr+ietf_at_nospam>
Date: Mon Mar 26 2012 - 08:42:54 GMT
To: IPsecme WG <ipsec@ietf.org>

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

>>>>> "Stephen" == Stephen Hanna <shanna@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)

  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

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[ ] mcr_at_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.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Contemporary messages sorted: [ By Date ] [ By Thread ] [ By Subject ] [ By Author ]