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

From: Timo Teras <[email-masked]>
Date: Wed, 5 Feb 2014 13:50:46 +0200

On Mon, 20 Jan 2014 18:14:58 +0000
Praveen Sathyanarayan <[email-masked]> 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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 6 Feb 2014 09:20:08 +0100

Hi Timo,

Thanks for the feed back.

We are happy you provide requirements over "dynamically routing
subnets" as a MUST. ADVPN responds to the requirements listed in
RFC7018. If there is a requirement that does not match you opinion,
can you please point it out?

Just to make it clear this 1 day time has never been mentioned in the
draft and is your assumption. The use of TTL does not impose a 1 day
and ADVPN can take advantage of the Redirect Mechanism or MOBIKE for
multihoming. As you can see the ADVPN solution can take advantage of
all previous and future featured designed for IKEv2. As you point out
the key characteristic of our design is its flexibility.

RFC5685 is not limited to client-gateway, the second line of the
section 10 you pointed out says: [...] the mechanism can also be used
between any two IKEv2 peers. " So no additional specification are
required.

You mention load balancing may be an issue. Can you please specify the
issue you see?

One last point to clarify. it seems that you are trying to say ADVPN
misses some features provided by routing protocols. In fact ADVPN can
take advanatge of ALL of these features as ANY routing protocol can
run on the top of ADVPN. This was a MUST requirement of RFC5685. If
you see a scenrio that you think does not fit ADVPN, please document
it so we can address your specific issue.

Best Regards
Daniel

On Wed, Feb 5, 2014 at 12:50 PM, Timo Teras <[email-masked]> wrote:
>> [PRAVEEN] That's an interesting point Fred, and thanks for bringing
>> indicate that it's best to wait a day between stopping using the
>> case, a Lifetime of one day or less should be just fine (and we're
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Timo Teras <[email-masked]>
Date: Thu, 6 Feb 2014 12:07:38 +0200

On Thu, 6 Feb 2014 09:20:08 +0100

> the key characteristic of our design is its flexibility.

It was Praveen's suggestion in the email I replied. My point was that
having that sort of default TTL does not sound good. And to me it
sounds like having very low TTL (in level of seconds or minutes) is too
heavy to be used in practice. So the TTL mechanism does not really
sound feasible to me.

> between any two IKEv2 peers. " So no additional specification are

You missed the next sentance:
"However, the mechanism can also be used between any two IKEv2 peers.
 But this protocol is asymmetric, meaning that only the original
 responder can redirect the original initiator to another server."

Spoke A established tunnel to spoke B. A is thus original initiator.
But the routing change is on spoke B subnet. B cannot send Redirect
according to the above. You'd need to specify additional mechanism for
that, or re-specify the original one. I believe this restriction is due
to security considerations for client-gateway type connectivity.

> You mention load balancing may be an issue. Can you please specify the

Could you specify how in practice I could implement one subnet to be
load-balanced to spoke nodes?

> it so we can address your specific issue.

I thought the advantage was to _not_ run routing protocol. If running
routing protocol is supported, can you please specify how a routing
protocol is to be integrated with the IKE traffic exchange? Yes, it is
possible, but non-trivial, thus I would like to see some specification
mapping how to do that mapping.

And like someone else asked, how is MPLS routed?

Thanks,
 Timo

---

From: Daniel Migault <[email-masked]>
Date: Wed, 19 Feb 2014 21:57:26 +0100

Hi,

Thanks for the feed back, please see inline my response.

BR,
Daniel

> heavy to be used in practice. So the TTL mechanism does not really

Fine so TTL is a simple way to provide resilience, but not an
optimized one. MOBIKE address this issue for IPsec.

>  responder can redirect the original initiator to another server."

Suppose A establish an IPsec session with node B. B can use a Redirect
not A. If A has not the capacity to handle the communication it should
not initiate it, and let C initiate the communication. This may be a
disadvantage is A and B are "equal", but in that case A and B should
be organized as clusters and redirect may not be the best way.

> load-balanced to spoke nodes?
If I correctly understand your scenario, you are looking at load
balancing the traffic of your private network between two spokes. Any
IP-load balancer could split and load balance the traffic between the
two spokes.
On the other hand you might also want to have multiple spokes under a
given IP address. In that case, load balancing is performed according
to the hash of the IP addresses or according to values of the SPI.
Solution like cluster IP load balance the traffic between the two
spokes [1].

[1] http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability

> I thought the advantage was to _not_ run routing protocol.

You are right ADVPN does not necessarily need routing protocol. It can
have one or not, it is up to the scenarios you want to address.

> If running  routing protocol is supported, can you please specify how a routing

I do not see the issue. Can you point out the issue more specifically.

> And like someone else asked, how is MPLS routed?

Maybe you could encapsulates MPLS traffic in GRE/IP. Everything
possible with DMVPN is possible with ADVPN.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Timo Teras <[email-masked]>
Date: Thu, 20 Feb 2014 09:12:57 +0200

Hi,

On Wed, 19 Feb 2014 21:57:26 +0100
Daniel Migault <[email-masked]> wrote:

> >> section 10 you pointed out says: [...] the mechanism can also be
> >> used between any two IKEv2 peers. " So no additional specification
> >> are required.
> >
> > "However, the mechanism can also be used between any two IKEv2
> > peers. But this protocol is asymmetric, meaning that only the
> > original responder can redirect the original initiator to another
> > server."
> >
> 

But if A original had the capacity and was intended to establish it,
but then later on routing protocol or administrative action made the
prefix to be removed from A. A would then need to inform of this
somehow.

> >> You mention load balancing may be an issue. Can you please specify
> >> the issue you see?
> >
> [1]
> http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability

This generally works by requiring single virtual IP that is then later
on load-blanced.

How about I have two ISP connection with separate public IPs. Haw can I
loadbalance over them? This is relatively simple to achieve in DMVPN.

> >> One last point to clarify. it seems that you are trying to say
> >> ADVPN misses some features provided by routing protocols. In fact
> >> ADVPN can take advanatge of ALL of these features as ANY routing
> >> protocol can run on the top of ADVPN. This was a MUST requirement
> >> of RFC5685. If you see a scenrio that you think does not fit
> >> ADVPN, please document it so we can address your specific issue.
> >
> > If running  routing protocol is supported, can you please specify
> > how a routing protocol is to be integrated with the IKE traffic
> > exchange? Yes, it is possible, but non-trivial, thus I would like
> > to see some specification mapping how to do that mapping.
> 

There is a lot of things involved. First question is already explained
in this (see above) and the previous mails. What happens when routing
protocol withdraws a subnet from one gateway, and it needs to tell
everyone that it's no longer available from it, but may be available
through other nodes.

> possible with DMVPN is possible with ADVPN.

This is one step closer to dmvpn. But how would the SHORTCUT mechanism
work then? 4.1. says protected domain can contain only
INTERNAL_IP4_SUBNET (13) and INTERNAL_IP6_SUBNET (15).  You'd need to
specify additional record types to all possible protocols ever needed
to run over GRE.