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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Mar 2012 11:56:17 +1300

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?

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. I do know that a conclusion that IPsec must be used
for everything is very unpalatable. 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.

   Brian

---

From: Daniel Migault <[email-masked]>
Date: Sun, 25 Mar 2012 17:05:30 +0200

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 <
[email-masked]> wrote:

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

> 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

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

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Mon, 26 Mar 2012 17:36:18 +0200

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.

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