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

[Daniel Migault <[e-mail]>]

Hi,

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

BR,
Daniel

On Thu, Feb 6, 2014 at 11:07 AM, Timo Teras <[e-mail]> wrote:
> On Thu, 6 Feb 2014 09:20:08 +0100
> Daniel Migault <[e-mail]> wrote:
>
>> 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.
>
> 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.

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

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

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.


> 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
>> issue you see?
>
> Could you specify how in practice I could implement one subnet to be
> 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

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

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.

>
> Thanks,
>  Timo



-- 
Daniel Migault
Orange Labs -- Security
[phone]