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

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Mon, 13 Jan 2014 16:07:10 +0000

Hi,

In reviewing the discussions over the past few weeks, there appear to be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that require further clarification.

It would be useful for the working group if the following aspects of draft-sathyanarayan-ipsecme-advpn-03 were clarified:

 1. scaling & general networking:
  1.1 It does appear this proposal has a limit of 256 networks. Is this correct ? How do nodes negotiate SA's when there are more than 256 prefixes on each side ? For reference, RFC5996 does not offer the ability to negotiate more than 256 prefixes in the TSi TSr payloads.

  1.2 What happens when a prefix administratively changes from behind one branch to another ? How do servers get notified about that ?

  1.3 How is VLSM taken into consideration (Variable Length Subnet Masking). E.g. long prefix behind one branch and a short prefix behind another

  1.4 How does a hub decide which Security Association to use when to spoke devices decide to advertise the same prefix ?

 2. multicast:

 2.1 There does not appear to be a specification of Multicast in this proposal. This is a key requirement for some of the ADVPN sponsors. How does multicast  work ?

 2.2 How are SA's negotiated and how do applications request multicast traffic to be sent ?

 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention how a server/hub learns about networks behind other servers

 3.1 what are the steps a server should take to establish a network with other servers

 3.2 how is topology and reachability information exchanged between servers

Thank you,

	Frederic Detienne

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 17 Jan 2014 09:56:51 +0000

Hi,

I would like to re-iterate the importance of clarifying the points below as it is not possible to assess the performances, relevance and interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage - - these are all important issues to potential users of this techology.

Thank you,

 Frederic Detienne

On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) <[email-masked]> wrote:

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

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Fri, 17 Jan 2014 17:01:21 +0000

Hi Fred,

All of our co-authors are currently busy, as we need to catch up with many
post holidays pending works. We will get back to you soon.

-- Praveen

On 1/17/14 1:56 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

>Hi,
>
>I would like to re-iterate the importance of clarifying the points below
>as it is not possible to assess the performances, relevance and
>interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage -
>- these are all important issues to potential users of this techology.
>
>Thank you,
>
> Frederic Detienne
>
>
>> In reviewing the discussions over the past few weeks, there appear to
>>be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03
>>that require further clarification.
>> 
>> It would be useful for the working group if the following aspects of
>>draft-sathyanarayan-ipsecme-advpn-03 were clarified:
>> 
>>  1.1 It does appear this proposal has a limit of 256 networks. Is this
>>correct ? How do nodes negotiate SA's when there are more than 256
>>prefixes on each side ? For reference, RFC5996 does not offer the
>>ability to negotiate more than 256 prefixes in the TSi TSr payloads.
>> 
>>  1.2 What happens when a prefix administratively changes from behind
>>one branch to another ? How do servers get notified about that ?
>> 
>>  1.3 How is VLSM taken into consideration (Variable Length Subnet
>>Masking). E.g. long prefix behind one branch and a short prefix behind
>>another
>> 
>>  1.4 How does a hub decide which Security Association to use when to
>>spoke devices decide to advertise the same prefix ?
>> 
>> 2. multicast:
>> 
>> 2.1 There does not appear to be a specification of Multicast in this
>>proposal. This is a key requirement for some of the ADVPN sponsors. How
>>does multicast  work ?
>> 
>> 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not
>>mention how a server/hub learns about networks behind other servers
>>

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Fri, 17 Jan 2014 17:05:11 +0000

Thanks Praveen!

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 20 Jan 2014 18:14:58 +0000

Hi Fred,

Many thanks for the good comments. We're happy to clarify the fine details and nuances in our proposal further. As you could imagine, there are two ways that one can deploy ADVPN, as described in our draft. First, you can use the IPSec rules as defined on a per system/zone/virtual-system basis. Alternatively, one can bind the negotiated traffic-selectors during the negotiation (i.e. bind them to a virtual tunnel interface; in vendor-speak, I guess Cisco calls this a VTI interface, while Juniper refers to it as st0 interface). In general we consider this primarily an implementation decision. That is, different vendors may opt for either way, depending on what said vendor wants to bring into production. Both approaches are viable in the field and have their respective advantages. For example, if a tunnel-interface based approach is adopted, this allows us to run standard routing protocols to manage a large network, or achieve load-balancing in ECMP-based next hops. If someone choose rule based approach, they get better granularity and better security management.

The take-home message here is that our draft (draft-sathyanarayan-ipsecme-advpn) is flexible enough to allow any vendor (commercial, open-source, and even academic) to go for whichever approach they prefer to implement according to their own considerations. With respect to commercially-oriented vendors, in particular, we expect that they can easily adopt our draft to provide an open solution without compromising their business goals. (This may not be the case for the other two drafts, but never mind for now).

We would like to highlight once again that our draft does _not_ require the use of another tunneling mechanism just for establishing a shortcut tunnel between two endpoints. That is, one can simply extend their existing IPsec implementation to support shortcuts.

Please see inline below for further answers and comments to your questions.

Thanks,

Praveen

On 1/13/14, 8:07 AM, "Frederic Detienne (fdetienn)" <[email-masked]<mailto:[email-masked]>>

wrote:

Hi,

In reviewing the discussions over the past few weeks, there appear to be a

number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that

require further clarification.

prefixes on each side ? For reference, RFC5996 does not offer the ability

to negotiate more than 256 prefixes in the TSi TSr payloads.

[PRAVEEN] The value you mention (256) is on a per shortcut tunnel basis. Nothing prevents you from having multiple shortcuts between the same shortcut partners. If a tunnel-interface approach is chosen, a routing protocol can be employed to manage, say, a large network. Based on the authors’ own implementation experience of IKE (i.e. without the ADVPN implementation in), you can always negotiate a single range (read: single subnet without narrowing). In other words, setting up an IPsec tunnel that is not tied to a VTI is pretty cheap and simple. It's just one round-trip in IKEv2 and, by default, involves no "heavy" crypto - just an encrypted CCSA packet and a KDF.

  1.2 What happens when a prefix administratively changes from behind one

branch to another ? How do servers get notified about that ?

[PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a general rule, each spoke can download updated PROTECTED_DOMAIN information periodically, which advertises everything behind the hub and all other spokes combined. Of course, this does not change if some subnet has moved from behind spoke A to behind another spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key here. We could see this being employed in a straightforward manner to allow for this transition: a) the subnet can "disappear" and be unreachable for one Lifetime, or b) the original spoke can redirect to the new spoke.

We don't think this matters much in the real world, because people don't just move entire subnets instantaneously. Typically, folks stop using a subnet in one place, then begin using it in another. This makes a lot of sense for several operational reasons, as you would imagine. In fact, experience shows that since routing doesn't update across the world immediately, best practice would, for instance, indicate that it’s best to wait a day between stopping using the subnet in one place and starting to use it in another place. In this case, a Lifetime of one day or less should be just fine (and we’re thinking that, in fact, an hour would be a reasonable Lifetime value in practice).

We would indeed argue that using Lifetime allows us to make the basic implementation of ADVPN handle a transition from one administrative domain to another in a straightforward manner. A redirection based on RFC5685 re-uses an already defined mechanism and makes the transition immediate, if/when necessary. This is one more argument for draft-sathyanarayan-ipsecme-advpn as it illustrates the modularity of our ADVPN proposal _and_ keeps the implementation simple.

another

[PRAVEEN] Traffic-selector payloads are specified through address ranges. As such, shortcut tunnels can be established with _finer granularity than with VLSM_. Of course, on balance, this may mean that you can have weird selectors (for example, 192.168.0.0-192.168.36.255 and 192.168.38.0-192.168.255.255). Overall, we consider this yet another +1 for our proposal.

[PRAVEEN] I guess you refer to error-handling, right? Because we see this as an erroneous configuration; please let us know if this is not the case (and why would that be so in a typical deployment; we’re looking forward to it).

In general, we assume that the hub has correct configuration or that, at the very minimum, the implementation would reject configuration changes that lead to an inconsistent state (and if that is the case, promptly alert the administrator about it). But to your question: Since it is hub, it must have SPD entries for its corresponding spokes. According to the SPD entries, the hub will choose which tunnel to use for forwarding the traffic. Please see Section 5 (http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03#section-5), which details how SPD entries are modified when a shortcut tunnel is established. In a nutshell, a dynamic shortcut SPD entry is added on top of an administratively configured static entry. We believe that, for all practical purposes, this is more than “good enough”. Of course, if routing protocols have a better solution to the problem you bring up, we’re all ears.

2. multicast:

does multicast  work ?

[PRAVEEN] The traffic-selector payload does not make any assumptions about the type of prefixes that can be exchanged during the negotiation; multicast prefixes can be exchanged. If a virtual interface approach is adopted, the administrator can also use multicast routing protocols like PIM to discover source and best paths.

2.2 How are SA's negotiated and how do applications request multicast

traffic to be sent ?

[PRAVEEN] As mentioned above, one can configure and negotiate multicast groups. I believe, #2.1 already answers your question. However, we do not see multicast used with spokes: mutlicast IP is tunneled as regular IP. Maybe we didn’t get the scenario well understood though. Would you mind elaborating the scenario you have in mind wrt multicast?

3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention

how a server/hub learns about networks behind other servers

3.1 what are the steps a server should take to establish a network with

other servers

[PRAVEEN] Would you please clarify the problem by providing some details here? What specific issues did you identify? May be you should refer to Appendix A, B and C of our draft. They may answer your question.

[PRAVEEN] Please refer to Appendix C (http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03#appendix-C), which illustrates PROTECTED-DOMAIN can be used.

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Tue, 21 Jan 2014 08:52:46 +0000

Hi Praveen,

thanks for taking the time to respond. I have read the ADVPN proposal with attention and these points need a much deeper dive as I do not think the specification is so straightforward.

I will split the Q&A's for easier follow up as the thread will be very quickly unreadable.

regards,

	fred

On 20 Jan 2014, at 19:14, Praveen Sathyanarayan <[email-masked]> wrote:

> On 1/13/14, 8:07 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
> wrote:
>  
> Hi,
>

---

From: "Frederic Detienne (fdetienn)" <[email-masked]>
Date: Thu, 23 Jan 2014 15:32:20 +0000

> [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respectively) of http://tools.ietf.…

It turns out I did read those sections and this is exactly what surprised me. Your answer is even more surprising.

Before going any further, is this resource exclusively exchanged between hub & spoke or also between spokes ?

thanks,

	fred

---

From: Praveen Sathyanarayan <[email-masked]>
Date: Mon, 27 Jan 2014 17:13:44 +0000

Hi Fred,

Comments inline.

Thanks,
Praveen

On 1/23/14 7:32 AM, "Frederic Detienne (fdetienn)" <[email-masked]>
wrote:

>>one
>> [PRAVEEN] That¹s an interesting point Fred, and thanks for bringing it
>>up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN
>>sections (3.6 and 3.9, respectively) of
>>http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a
>>general rule, each spoke can download updated PROTECTED_DOMAIN
>>information periodically, which advertises everything behind the hub and
>>all other spokes combined. Of course, this does not change if some
>>subnet has moved from behind spoke A to behind another spoke, B.
>>However, the Lifetime attribute of the ADVPN_INFO payload is key here.
>>We could see this being employed in a straightforward manner to allow
>>for this transition: a) the subnet can "disappear" and be unreachable
>>for one Lifetime, or b) the original spoke can redirect to the new spoke.
>

[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? 

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