Re: [secdir] Secdir review of draft-ietf-mif-problem-statement-07

Jari Arkko <> Thu, 26 August 2010 05:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E22C3A6A6A; Wed, 25 Aug 2010 22:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.363
X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gCinq8452Nql; Wed, 25 Aug 2010 22:20:23 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 92FD83A690D; Wed, 25 Aug 2010 22:20:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 208E22CC34; Thu, 26 Aug 2010 08:20:51 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aePgvxTtXmfv; Thu, 26 Aug 2010 08:20:50 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by (Postfix) with ESMTP id 81D442CC32; Thu, 26 Aug 2010 08:20:48 +0300 (EEST)
Message-ID: <>
Date: Thu, 26 Aug 2010 01:20:50 -0400
From: Jari Arkko <>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] Secdir review of draft-ietf-mif-problem-statement-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Aug 2010 05:20:25 -0000


Thanks for your review!

> 1) Lower layer authentication and encryption
> It's possible that some interfaces may have link layer or IP layer
> encryption and authentication.  Its possible that this characteristic
> might be used in determining how configuration parameters are processed.
> Some connection managers may already do this to a certain extent.  I
> think this should be listed as a consideration in the appropriate
> sections of the document (3.1, 3.6,5)

This seems reasonable. Authors, can you suggest some text and update the 

> 2) I think the security considerations can be expanded
> It discusses that information may be leaked from one network to another
> which seems to be talking about generic data.  This is true, but it
> seems that would be worthwhile to talk specifically about the
> information discussed in the document.  For example it seems that it is
> at least possible for one interface to send configuration parameters
> that will cause a denial of service on another interface.  It may also
> be possible for one host to set configuration parameters which cause
> certain traffic to be forwarded to an attacker.  


> The last paragraph is also not very clear.  What I think you are trying
> to say is that the information that is used by the connection manager
> may be vulnerable to spoofing and forgery if it is unprotected.  In
> general its not possible to protect this information in all cases, so it
> is not clear what you are recommending.  

I agree that configuration information is unlikely to be fully secured, 
at least if "secured" means communications security or authentication.

Here's what I would say in that paragraph:

Additional security concerns raise up when information is provided to
the host so that it could make a more intelligent decision (e.g.
provide selection policies to the connection manager). This
additional information should be protected in some manner.
Additional security concerns are raised by possible future mechanisms that
provide additional information to the host so that it can make a more
intelligent decision with regards to the issues discussed in this document.
Such future mechanisms may themselves be vulnerable and may not be
easy to protect in the general case.