Re: [mif] draft-mglt-mif-security-requirements-01

[Daniel Migault <[e-mail]>]

Exactly. There are actually two possible scenarios:
        - Scenario 1 where the MIF-Node initiates for each Interface an
IKEv2 exchange to establish an IKEv2 channel and then configure the SA.
        - Scenario 2 where the MIF-Node re-use the already IKEv2 channel to
create the new SAs for each Interface with a CREATE_CHILD_SA exchange.

The proposed solution takes advantage of previously existing SA and SP.
When an update is required, we only update the required field, and when a
new SA or SP needs to be created, we take advantage of the existing
context. Note that when a new SP need to be created, we have to check first
they match the general Security Policies of the System.

I will clarify this in the next version of the draft thanks for the comment.

Here are some more details about the mentioned scenarios:

Note that Scenario1 MUST be considered since IKEv2 [RFC5996] mentions in
section1.3 an implementation MAY refuse all CREATE_CHILD_SA request within
an IKE_SA"

A) Scenario 1: For each Interface the MIF-Node performs an IKEv2 exchange
to negotiate the SA.

This requires at least a four message exchange which includes an
authentication. For example, using EAP-SIM [RFC4186] adds 7 exchanges and
using EAP-AKA [RFC4187] adds 5 exchanges. This method is not convenient
because it adds latencies, it results in creatings SA + IKE_SA for each
interface, add computations by generating the keys and DH exchange for each
Interface.

B) Scenario 2: For each Interface the MIF-Node performs an CREATE_CHILD_SA

This requires a two message exchange described in [RFC5996] section 1.3.1.
This exchange requires multiple Notify Payloads like SA (SA Proposal), Ni
(the Nonce) and Tsi Tr, (the Traffic Selectors). This is still better than
scenario 1, but (1) it does not take advantage of the previously negotiated
SA and its keying material, (2) Payloads are quite large which adds
latencies, slows the IPsec configuration. This affects the SCTP/ MPTCP
connectivity because packets are DISCARDed during this time. In additon,
the IPsec Anti-replay Windows is quite small and may increase the number of
rejected IP packets.


On Thu, Apr 5, 2012 at 4:46 PM, Hampel, K Georg (K Georg) <
[e-mail]> wrote:

>  Daniel,****
>
> ** **
>
> In principle, the same could be accomplished via separate SA on each path,
> even if the paths pertain to the same SCTP or MPTCP connection. Correct?
> This obviously adds cost to SA establishment.****
>
> ** **
>
> Georg****
>
> ** **
>  ------------------------------
>
> *From:* Daniel Migault [mailto:[e-mail]]
> *Sent:* Thursday, April 05, 2012 10:29 AM
> *To:* Hampel, K Georg (K Georg)
> *Cc:* [e-mail]
> *Subject:* Re: [mif] draft-mglt-mif-security-requirements-01****
>
> ** **
>
> That's correct. It provides IPsec the Multiple Interfaces features of SCTP
> or MPTCP.  The goal is that MIF Nodes can deal with IPsec protected
> communications.
>
>
> BR
> Daniel****
>
> On Thu, Apr 5, 2012 at 4:04 PM, Hampel, K Georg (K Georg) <
> [e-mail]> wrote:****
>
> Daniel, all,****
>
>  ****
>
> I read draft-mglt-mif-security-requirements-01. ****
>
>  ****
>
> Just to make sure I got the essence: The draft proposes to extend
> IPsec/MobIKE so that a multihomed host can simultaneously sustain multiple
> paths to the same security gateway or app server using the *same* SA.
> MobIKE would have to be upgraded to dynamically add/delete such paths.****
>
>  ****
>
> Purpose: Such an extension would avoid the need to establish separate SAs
> for each path.****
>
>  ****
>
> Is that correct?****
>
>  ****
>
>  ****
>
> Regards,****
>
> Georg****
>
>  ****
>
>  ****
>
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif****
>
>
>
>
> --
> Daniel Migault
> Orange Labs -- Security
> [phone]****
>



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