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 <pravee...@juniper.net> wrote:
> 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)" <fdeti...@cisco.com>
> 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.
>
> 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.
>
> [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.
>
>
> 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
>
> [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.
>
>
> 1.4 How does a hub decide which Security Association to use when to
> spoke devices decide to advertise the same prefix ?
>
> [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:
>
> 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 ?
>
> [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.
>
> 3.2 how is topology and reachability information exchanged between servers
>
> [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.
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
