Re: [mif] I-D Action: draft-mglt-mif-security-requirements-00.txt

[Daniel Migault <[e-mail]>]

Hi Brian,

Thank you for your remarks we are considering for the 01 version of the
draft that will be published soon. I briefly provide inline responses.


On Thu, Mar 1, 2012 at 11:56 PM, Brian E Carpenter <
[e-mail]> wrote:

> Hi,
>
> I don't understand the scope or the threat model for this draft.
>
> The scope seems to be less than the whole of MIF. It seems to be
> limited to a subset of MIF cases where a provider is in some way
> in control of the acquisition and use of additional interfaces.
> In the general case, nobody is in control - the user device simply
> discovers and uses whatever connectivity appears. If this is a
> correct understanding, could the title, Abstract and Introduction
> make it very clear what the scope is?
>
> No. we are considering the general case of MIF. The confusion comes
probably from the section that considered ISP hosted services. What we
pointed out in this section was that the ISP would be able to adapt the
security of the Service according to the type of network. I remove this
confusing section in 01.



> I don't understand the threat model because it isn't described
> at all. So I can't evaluate any of the assertions about security
> requirements.


The model is that a communication being carried on a RAN MAY not need any
protection because RAN is a trusted Network. WLAN MAY not be trusted
Network, and EU switching to WLAN MAY want to protect the communication. We
describe why we recommend IPsec and what IPsec currently misses to address
the Multiple Interfaces Security Requirements.
There is no threats description in 01, but we provide a better description
of the motivations for Security Requirements.

I do know that a conclusion that IPsec must be used
> for everything is very unpalatable.


I agree. For ISPs, IPsec is recommended, but we also insist that there is
no systematic solutions.

There are risks in any public
> WLAN of course, but they exist whatever crypto is used.
>
> One detail:
>
> > Alternate IP addresses are provided for a given
> > communication, a Primary IP addresses is replaced by an
> > Alternate IP address, and Primary and Alternate are not used
> > simultaneously for the same communication.
>
> This is not true if the device uses recent techniques such as
> MPTCP, which automatically shares the available paths. Such end
> to end techniques are outside the control of the provider.
>

Right. Version 01 should  clarify this. The draft is focused on IPsec
configuration for Multihoming. I considered IKEv2 own mechanisms to deal
with Multihoming. I known work has previously been done to make IKEv2 work
over SCTP to make IKEv2 benefit from SCTP features but do not considered
here.
The idea is to make IKEv2 resistant to change of Interfaces, Interface
fail-over so that IKEv2 can proceed to the IPsec configuration for the
communication. Mobility, Multihoming, Multiple Interfaces do not concern
the communication in itself, but the way to configure IPsec. Configuring
properly IPsec is necessary to avoid IPsec blocking the communication, when
other protocols like SCTP, MTCP performs Mobility or Multihoming.

Regards,
Daniel

>   Brian
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>



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