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

[Timo Teras <[e-mail]>]

On Mon, 20 Jan 2014 18:14:58 +0000
Praveen Sathyanarayan <[e-mail]> wrote:

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

I disagree. IMGO, dynamically routing subnets is a MUST.

Multiple scenarios exist. But to name one:

I have complex site with multiple internal links and dynamic internal
routing connected to ADVPN via two or more spokes (connected via
different ISP lines).

All the spokes can route to all subnets inside that site to provide
redundancy, and in some cases load balancing.

If one spoke's ISP line dies, or if the internal routing protocol
decides other wise (e.g. intra-site link fails), the spokes should
dynamically move the subnet from one to another.

Having a failover time of _a day_ is unacceptable.

The redirect mechanism seems to be limited to client-gateway
connections, and only the gateway can send it (rfc5685 point 10). This
is not true in advpn context as any spoke may want to later on redirect
the SA of subnet it originally initiated. Using redirect would need
additional specifications to be usable.

Then there is also the case of load balancing... etc.

I do agree that subnets should be authorized to be routed. I do that in
existing dmvpn install, by means of automatically filtering the
announced routes based on the presented certificate. That is, the
certificate tells which subnets it can announce.

- Timo