Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Feb 2014 15:28:52 +0000

In addition to what Praveen said, I'd like to point out that draft-sathyanarayan defines a two-tier network. On the top tier are security gateways that are (presumably) always-on and know the union protected domain of the VPN.  The second tier are devices that do not know the entire protected domain. The group of first-tier nodes is not necessarily identical to the group "hubs", but that is typical. Also typical is for that group to be relatively small - 2-30 gateways in a network that contains 10s of thousands of nodes.

Second tier devices are typically remote access clients, home routers or small office routers. Their initial configuration is simple - one peer, and credentials for connecting to that peer.

First tier devices should know at all times what the union protected domain is. It's possible that they won't know which peer gateways protects a particular address, but they have to know the difference between "send through the VPN" and "send through the unprotected Internet".

The PROTECTED_DOMAIN attribute described in section 3.9 is always sent from a first-tier gateway to a second tier node, and includes the union protected domain, unless policy requires something different: for example, remote access clients are often required to send all their traffic (even google searches) through a center gateway. The PROTECTED_DOMAIN is a bootstrap mechanism for 2nd tier nodes. It is *not* part of the normal continuous operation of the network, although 2nd tier nodes may use it periodically.

The Shortcut exchange, described in most of section 3 is the one used among all the nodes in the AD-VPN to tell each other where a particular part of the union protected domain is protected.  That *is* part of the normal operation of the protocol. 

When adding or deleting a spoke with a protected domain, two steps are required:
 1. Configure the new spoke with the identity, address, and credentials for a hub gateway
 2. Configure the hub gateway with the identity, credentials and protected domain of the new spoke. 

You cannot omit step #2 in any solution unless you forego authentication. Accepting a protected domain from an unauthenticated node, whether the protected domain is sent in a CFG payload, an HTTP resource, or a routing protocol message is a security vulnerability. Accepting any valid certificate without pre-configuring the expected content (for example, "Subject must contain 'CN=Tokyo Office' and Issuer must be xxxx")  is no authentication at all.

The missing piece here is the propagation of the union protected domain information among all the 1st tier nodes. This is fairly simple in a single enterprise network where such nodes are managed centrally. I can also see how in more heterogenous environments routing protocols could be used. Or the WG can develop some new mechanism (although I don't think that's a good idea). I think this is more useful than requiring 2nd tier [1] devices to participate in routing protocols.

Yoav

[1] I've often heard people use mobile phones as the ultimate example of low-end, but looking at the specs of small-office gateways, many of them are lower-spec than the average phone - under 1GB of memory, around 1GB of flash space, CPUs that are leftovers from last year's mobile phones.

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 5 Feb 2014 13:42:30 +0000

Hi Praveen,

Sorry about the delay. I am just back from our EMEA company event and have been a lot busier than I planned.

> [PRAVEEN] For one-liner question, we could only imagine the scenario that
> you are trying to solve. And this is what we could come up. May be you can
> provide more detailed question on what scenario you would like to solve.
> We could help in answering those scenarios.
> 
> When admin changes the prefix of a spoke, spoke¹s existing static tunnel
> with Hub, gets re-negotatiaged for updated prefix in Tsi/TSr payload. This
> event updates the Hub about changed prefix information. Is that what you
> wanted to know? 

Yes, this is the information I was looking for. So in a nutshell, when a prefix in spoke network is changed, it takes an additional change in the central DB and a tear down of the tunnels.

This is not very attractive compared to a routing protocol which can do it instantly and without affecting the other prefixes. Especially in the presence of a large number of prefixes behind spoke(s).

Also, I am taking it that there is one such file per spoke ? Or is it one big file containing all the spoke prefixes ?

>> 
>> Before going any further, is this resource exclusively exchanged between
>> hub & spoke or also between spokes ?
> 
> 
> [PRAVEEN] ³resource² you means ADVPN_INFO payload or Subnet information?
> ADVPN_INFO exchanged between spokes. Subnet information exchanged part of
> Tsi and TSr during IKE negotiation (which means between hub & spoke and
> between spokes as well).

I mean the ADVPN_INFO pointing to the URL with the list of prefixes.

The question is now: who has access to those resources ? Who can update the file(s) on the fileserver(s) ? This raises the whole question about role based management.

It also means the change management is now quite complex since in order to update spoke prefixes you also have to change the central prefix files.

One of the requirements which was "no change on the central devices when adding a branch" is in contradiction with this method. OTOH, I am pondering that the spokes could automatically update the central file(s) in which case it would not be very different from a routing protocol...

thanks,

	fred

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

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 5 Feb 2014 13:45:16 +0000

On 03 Feb 2014, at 16:28, Yoav Nir <[email-masked]> wrote:
> […]

> The missing piece here is the propagation of the union protected domain information among all the 1st tier nodes. This is fairly simple in a single enterprise network where such nodes are managed c…

this is precisely one of the major complains against draft-sathyanarayan. It translates into multiple forms at various levels.

Some things can work in some use cases but it forever needs development for other use cases. The changes between v0 and v3 are significant and they will keep augmenting.

We can no longer call that a simple solution. There are pieces that meet some of the requirements but are in contradiction with others.

Similarly, draft-sathyanarayan offers multiple implementation or deployment systems (policy based or tunnel based) which are not compatible at protocol level. It means implementations have to cover BOTH methods to guarantee interoperability.

To take a practical example: one domain may initially be rule based, the other tunnel based. What happens when those domains must now cooperate ?

Both issues above will prevent proper cross-domain interoperability. In particular, a "policy-based" spoke will not be able to talk to a "tunnel based" hub as per this draft… it would take a decision as to which is the fallback mode and a dual implementation on at least one of the devices.

In draft-detienne, the tunnels between the hubs need to support one of the existing routing protocols (we would recommend BGP for large domains). This guarantees interoperability end-to-end.

thanks,

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Wed, 5 Feb 2014 19:27:46 +0000

Hi Fred,

My comments inline.

Thanks,
Praveen

On 2/5/14, 5:42 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

Hi Praveen,

Sorry about the delay. I am just back from our EMEA company event and have
been a lot busier than I planned.

> event updates the Hub about changed prefix information. Is that what you

Yes, this is the information I was looking for. So in a nutshell, when a
prefix in spoke network is changed, it takes an additional change in the
central DB and a tear down of the tunnels.

This is not very attractive compared to a routing protocol which can do it
instantly and without affecting the other prefixes. Especially in the
presence of a large number of prefixes behind spoke(s).

Also, I am taking it that there is one such file per spoke ? Or is it one
big file containing all the spoke prefixes ?

[PRAVEEN] I think you didn’t get my answer. What I was trying to say is,
if there is a network prefix change on the spoke side, Spoke renegotiates
with Hub (Child SA rekey has TSi and Tsr payload to convey about the
address change). Thus Hub would know about the change, without any
administrator intervention. There is no file/database to be edited. This
is quite similar to what routing protocol would do.

I want to re-stress the point. Our solution is not against using routing
protocol. If vendor thinks that is the best approach deploy, he/she can do
so, just like many vendor already do today.

The question is now: who has access to those resources ? Who can update
the file(s) on the fileserver(s) ? This raises the whole question about
role based management.

It also means the change management is now quite complex since in order to
update spoke prefixes you also have to change the central prefix files.

One of the requirements which was "no change on the central devices when
adding a branch" is in contradiction with this method. OTOH, I am
pondering that the spokes could automatically update the central file(s)
in which case it would not be very different from a routing protocol…

[PRAVEEN] It all depends on how you implement. It can be automated as
well, if you like to do so. For example, each spoke when establishes a
tunnel with the Hub, Hub already knows about the prefixes that spokes
protects. This information can be populated to PROTECTED_DOMAIN database
automatically. You don’t need any administrator intervention, if you
really want to trust such changes.

Also, if an administrator would like to prevent such changes, before
reviewing it, that can be done as well. Again it depends on how vendor
wants productize this neat security feature. Hey, remember that, a south
asian ISP advertising I have YouTube (in intention of blocking YouTube in
his country), that lead to falsely advertising rest of the world? Don’t
you think administrator of a domain want to prevent such things happening
in his/her domain?

The problem with routing protocol is, it comes with implicit assumption of
trust. Yes this good thing in most scenario, but not always. There are
administrators who would like to have a better control over their network
than just automated way of deploying.

Again, if you don’t think that is the case, you can choose to implement
with our solution with routing protocol, similar to most vendor (including
Cisco and Juniper) who already do that with IPSec today. That provides
flexibility that an administrator want out of routing protocol.

thanks,

	fred

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Wed, 5 Feb 2014 23:08:27 +0000

Hi Praveen,

Comments inline.

Thanks,

   Fred

(sent from mobile)

> is quite similar to what routing protocol would do.

I think this is getting clearer now. Thanks.

So based on what you say above and below, when the spoke updates its new TSi TSr, all traffic is potentially blocked until the admin vouches the change in the protected domain list ?

> really want to trust such changes.

Thanks for that. I meant the PROTECTED_DOMAIN list. 

So how does the PROTECTED_DOMAIN list get updated from a protocol standpoint ? Specifically when there are multiple hubs to serve a domain ?

> flexibility that an administrator want out of routing protocol.

Well in fact, as draft-detienne-01 shows, we can also use IKE (config exchange) but regardless of the prefix transport method, it does not need the domain list contraption to achieve that security level.

Now it would be interesting that you specify how a routing protocol works in the context of draft-

Also, how do two domains with different mode interoperate ? What happens when a routed spoke talks to a PROTECTED_DOMAIN hub or spoke ?

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Wed, 5 Feb 2014 23:31:11 +0000

Hi Fred,

I see draft-detienne¹s view of discovery of tunnel-peer is a routing
issue. So DMVPN solution predominantly a routing solution. So,
draft-detienne may work good for routing vendors.

But it is not a solution for non-routing vendors. As an example, mobile
devices increasingly can do more features like FaceTime/Skype/Hangout,
Airdrop. To do these, expecting mobile devices to run BGP protocol, to
discover a direct tunnel is not a reasonable expectation. Or for that
matter expecting a firewall device to run routing protocol, is not a
reasonable expectation either.

More comments inline.

Thanks,
Praveen

On 2/5/14, 5:45 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

> We can no longer call that a simple solution. There are pieces that meet
>some of the requirements but are in contradiction with others.

> Similarly, draft-sathyanarayan offers multiple implementation or
>deployment systems (policy based or tunnel based) which are not
>compatible at protocol level. It means implementations have to cover BOTH
>methods to guarantee interoperability.

[PRAVEEN] I disagree. How will a spoke running OSPF and other spoke
running BGP interop in draft-detienne?  Your answer was, (previously in
virtual conference) was that it does not matter. Because, as long as Hub
supports both routing protocols, there is no issue. The same thing applies
here. If you have route based implementation on a SpokeA and Policy based
implementation SpokeB, it can still open a direct IPSec tunnel without
causing any interoperability. And of course, there is no need of running
routing protocol between the spokes, even in our solution.

To take a practical example: one domain may initially be rule based, the
other tunnel based. What happens when those domains must now cooperate ?

Both issues above will prevent proper cross-domain interoperability. In
particular, a "policy-based" spoke will not be able to talk to a "tunnel
based" hub as per this draftŠ it would take a decision as to which is the
fallback mode and a dual implementation on at least one of the devices.

[PRAVEEN] No issues here. As long as you support rfc5996, and you exchange
TSi and Tsr payloads, you are ready to setup a tunnel and forward the
traffic. On route based VPN side, you get TSi and TSr payload that defines
the SPD entries. These SPD entries are bound to your tunnel interface.
Route that exist before the shortcut tunnel, still points to tunnel
interface. As this tunnel-interface is now has dynamic SPD entries, it now
knows how to forward all/selective traffic to the shortcut tunnel. And of
course the Policy based domain side it is straight forward. Where do you
see the issue? 

Thanks,
Praveen

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Thu, 6 Feb 2014 04:44:58 +0000

Hi Praveen,

I suppose it would be convenient for you to minimize DMVPN to a "routing solution" however draft-detienne covers more than that.

The remote access client case is fully covered. Without routing protocol. This point was clarified sometime in November (I believe) and draft-detienne was updated accordingly.

Now back to the discussion, I think I now do understand precisely how you see the negotiation going. It turns out we support all these methods already and we know the complexity of it.

I would like to verify a few more points because it is not trivial at all.

What I am exposing here is that draft-sathyanarayan will quickly grow out of control as it tries to encompass all possible negotiation methods.

In practice, it means only a couple vendors will be able to implement it decently and will likely clash quite hard. All this at the expense of users who are lured by failed promises.

More inline on this topic then I will slowly move on to the next points.

Thanks,

   Fred

(sent from mobile)

> On 06 Feb 2014, at 00:31, "Praveen Sathyanarayan" <[email-masked]> wrote:
> 
> Hi Fred,
> 

> routing protocol between the spokes, even in our solution.

The big difference is here:

domain1 can deploy a routed based network only by picking a vendor focusing on that method only. In this case, the TSi TSr may be 0.0.0.0/0 0.0.0.0/0

Domain2 may deploy a pure policy based implementation.

Now how does domain 2 accept domain1's proposals ? And vice versa ?

As you explain below, the route based method probably has to fall back to a policy type negotiation.

If domain1 admin made that choice, one can assume there is a reason. Now we end up with a double negotiation method.

Also how does spoke domain 1 initiate to hub domain 2 ? How does that hub know how to narrow down the TSi to ? It does not know that spoke yet...

What now if domain 3 wants GRE/IPsec ? I remember an early email saying it can be negotiated too.

Draft-sathyanarayan possibly allows any protocol to be negotiated but it focuses on the policy based method and does not mention at all how interop is achieved.

> course the Policy based domain side it is straight forward. Where do you

So I presume TSi TSr of the routed spoke will be 0.0.0.0/0 0.0.0.0/0 ?

This then gets narrowed down by the policy spoke ?

We would create a tunnel per peer to achieve that. Your comment is interesting however as it raises a complexity.

On a policy spoke1, the initial policy is

10.0.0.0/24 10.0.0.0/8 to hub

Then spoke2 is discovered hosting 10.0.1.0/24

Now the SPD says

10.0.0.0/24 10.0.0.0/8 to hub
10.0.0.0/24 10.0.1.0/24 to spoke2

I know implementations that will not behave well in this case. The SPDB does not guarantee a best match or sorted search.

What should they do ?

Thanks,

  Fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Fri, 7 Feb 2014 01:23:43 +0000

Hi Fred,

Comments inline.

Thanks,
Praveen

On 2/5/14 8:44 PM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

>Hi Praveen,
>
>I suppose it would be convenient for you to minimize DMVPN to a "routing
>solution" however draft-detienne covers more than that.
>
>The remote access client case is fully covered. Without routing protocol.
>This point was clarified sometime in November (I believe) and
>draft-detienne was updated accordingly.
>
>Now back to the discussion, I think I now do understand precisely how you
>see the negotiation going. It turns out we support all these methods
>already and we know the complexity of it.
>
>What I am exposing here is that draft-sathyanarayan will quickly grow out
>of control as it tries to encompass all possible negotiation methods.
>
>In practice, it means only a couple vendors will be able to implement it
>decently and will likely clash quite hard. All this at the expense of
>users who are lured by failed promises.
>
>domain1 can deploy a routed based network only by picking a vendor
>focusing on that method only. In this case, the TSi TSr may be 0.0.0.0/0
>0.0.0.0/0
>

[PRAVEEN] Hmm… May be you should re-read our draft. What our draft says
that the suggester/hub will suggest what traffic-selctor should be used
for establish the tunnel. So each spokes knows exactly what Tsi and Tsr
being negotiated. 

>If domain1 admin made that choice, one can assume there is a reason. Now
>we end up with a double negotiation method.
>
>Also how does spoke domain 1 initiate to hub domain 2 ? How does that hub
>know how to narrow down the TSi to ? It does not know that spoke yet...
>

[PRAVEEN] Again in Tsi and Tsr payload carry that information shortcut
suggestion from Hub. If GRE is supported in a particular domain, it should
be able to switch to GRE/IPSec.

>
>Draft-sathyanarayan possibly allows any protocol to be negotiated but it
>focuses on the policy based method and does not mention at all how
>interop is achieved.

[PRAVEEN] Sure if needed we will update with the information that is
required. This is why we are having discussion isn’t it? ;-)

>We would create a tunnel per peer to achieve that. Your comment is
>interesting however as it raises a complexity.
>
>I know implementations that will not behave well in this case. The SPDB
>does not guarantee a best match or sorted search.

[PRAVEEN] This is described in Section 5. It explains with example. Please
take a look.