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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 01 March 2012 22:56 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACF321F8AFE for <mif@ietfa.amsl.com>; Thu, 1 Mar 2012 14:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.51
X-Spam-Level:
X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp1qvg1S7yyP for <mif@ietfa.amsl.com>; Thu, 1 Mar 2012 14:56:27 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB31E21F8A0D for <mif@ietf.org>; Thu, 1 Mar 2012 14:56:26 -0800 (PST)
Received: by eeke51 with SMTP id e51so412957eek.31 for <mif@ietf.org>; Thu, 01 Mar 2012 14:56:25 -0800 (PST)
Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.204 as permitted sender) client-ip=10.14.99.204;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.204 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com
Received: from mr.google.com ([10.14.99.204]) by 10.14.99.204 with SMTP id x52mr4325484eef.7.1330642585947 (num_hops = 1); Thu, 01 Mar 2012 14:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lM5ZG42vST/4yhLljd0/nGlJRyEBugKx6SmSh578cCs=; b=Skkj6G/ve2RGpTy/hMZisLeCT6WLs8FC94EVIVg9zqmkj+H0hQxs+AiQotkQf3V9p/ T+eq1W1aOSCPtDA8H+JWlsW3GeIJfZsB5l6phjE7+kugMNJkK5VLlZCqmaZ9LmHDW2JN kZcHWCCx6vhxTjMS/ajV1pbZCkvEe1/UzMpxzGT5xrAdpMdZgC45+17+zbjEmMEci3gK /dhMPBWiIVnO6r0MHBpN1YJBEx24/plvmnd3OZQkP9lwDeBFYOKER967NP6VqQAD565m 11Ctwx5MP6Wqk98xehPq+FSgN2rmOGhYh71NBHIIuHv1/+hzyF3oHd6rZ7B80PtTZR42 nMiw==
Received: by 10.14.99.204 with SMTP id x52mr3316190eef.7.1330642585843; Thu, 01 Mar 2012 14:56:25 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm12562272eem.11.2012.03.01.14.56.23 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 14:56:25 -0800 (PST)
Message-ID: <4F4FFE91.8020906@gmail.com>
Date: Fri, 02 Mar 2012 11:56:17 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: mif@ietf.org
References: <20120301144229.28186.7229.idtracker@ietfa.amsl.com>
In-Reply-To: <20120301144229.28186.7229.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [mif] I-D Action: draft-mglt-mif-security-requirements-00.txt
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 22:56:27 -0000

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