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

[Jong-Hyouk Lee <[e-mail]>]

Dear Daniel.

I would like to encourage you not to only focus IPsec cases for securing
communication in multiple interface environments. As the title of this
draft shows it should address and point out general security requirements
for multiple interface environments. IPsec is not the sole solution. Note
that the document 00 is not addressing the general security requirements.

Access network attachment and flow security in multiple interface
environments should be addressed in such a security requirement document.

Cheers.


On Sun, Mar 25, 2012 at 5:05 PM, Daniel Migault <[e-mail]> wrote:

> 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]
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif
>
>


-- 
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/