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

[Praveen Sathyanarayan <[e-mail]>]

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)" <[e-mail]<mailto:[e-mail]>>

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.