Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 20 June 2010 11:46 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E113A696F for <secdir@core3.amsl.com>; Sun, 20 Jun 2010 04:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVWtThkUzf86 for <secdir@core3.amsl.com>; Sun, 20 Jun 2010 04:46:34 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 137AA3A6816 for <secdir@ietf.org>; Sun, 20 Jun 2010 04:46:33 -0700 (PDT)
Received: by wya21 with SMTP id 21so1932813wya.31 for <secdir@ietf.org>; Sun, 20 Jun 2010 04:46:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uQDHtOz+qujiWWnwEvZK3HnAPi1GV1Yr4/V5jPJOLa0=; b=cAznRn7J6M6rHYzZvqdAZVeXCdlM7xewG68nSnQcQOpaNrs7lcNWuwkFRYnlF5I/4d 8R4nxJjxrOkdF3SYoCaLfrQqgLdCtDp/rEq2dooCvBBGBOVLzPvVjlW32dfpVLYeKehL RZFWusOIJkzfNqmLH8m6qT/UVkxIFOnjbC2Ec=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CgYOFxjNUp15glE+LplYfbNU7+BeEF2JD0UQefmpqBdmJFxzqPZDO+vxH+NZJCsWC1 c434sGj16/Hun3a3eLMBlE6yF+0re0MZxFcnygXowwPMML3jTJ4Wchu/4dEWWFhwxfRb 78ASb4Pau9v5QAI1bSpPjq3cKjwdL0N8xx/LI=
Received: by 10.227.143.212 with SMTP id w20mr3300399wbu.107.1277034397123; Sun, 20 Jun 2010 04:46:37 -0700 (PDT)
Received: from [10.0.0.2] (bzq-79-178-30-177.red.bezeqint.net [79.178.30.177]) by mx.google.com with ESMTPS id u36sm32868370wbv.6.2010.06.20.04.46.34 (version=SSLv3 cipher=RC4-MD5); Sun, 20 Jun 2010 04:46:36 -0700 (PDT)
Message-ID: <4C1DFF97.1020103@gmail.com>
Date: Sun, 20 Jun 2010 14:46:31 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Charles Shen <charles@cs.columbia.edu>
References: <4C148FB1.8060709@gmail.com> <AANLkTinw980xq5rcwzZMvrGRewuMs6YMu4s3XheGHmsB@mail.gmail.com>
In-Reply-To: <AANLkTinw980xq5rcwzZMvrGRewuMs6YMu4s3XheGHmsB@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, draft-ietf-nsis-tunnel.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Jun 2010 11:46:47 -0000

[Removed the IESG.]

Hi Charles,

please see my comments inline.

Thanks,
     Yaron

On 06/20/2010 06:52 AM, Charles Shen wrote:
> Hi Yaron, thank you for your careful review. Please see comments inline.
>
> On Sun, Jun 13, 2010 at 3:58 AM, Yaron Sheffer<yaronf.ietf@gmail.com>  
> wrote:
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the IESG.
> > These comments were written primarily for the benefit of the security
> > area directors.  Document editors and WG chairs should treat these
> > comments just like any other last call comments.
> >
> > This draft discusses the problem of NSIS messages (particularly, QoS
> > reservation flows) being encapsulated into various IP tunneling 
> protocols,
> > which prevent the correct QoS setup from being performed. The draft 
> proposes
> > a solution for NSIS tunnel-aware tunnel endpoints, which basically 
> adds an
> > NSIS signaling flow between the tunnel endpoints, but outside of the 
> tunnel.
> >
> > General
> >
> > The draft presents the problem, and the solution, reasonably well.
> >
> > The draft goes for the "no new security issues" approach. I think 
> this is
> > incorrect, and in fact a number of security issues should be 
> analyzed and
> > possibly resolved. In addition, as a complete outsider to NSIS, I have
> > identified one major unspecified piece, leading me to believe that 
> the draft
> > has not had enough review.
> >
> > Security
> >
> > The main security issue is that the draft fails to consider
> > security-oriented tunnels. IPsec tunnels (and the commonly used
> > GRE-over-IPsec) provide security services: normally encryption and 
> integrity
> > protection with ESP, less commonly integrity-protection only with 
> AH, ESP
> > with null encryption, or the new WESP (RFC 5840). The proposed solution
> > raises at least three major security issues related to these tunnels:
> >
> > 1. A so-called covert channel that results from NSIS flows in the 
> protected
> > networks directly triggering NSIS protocol exchanges in an unprotected
> > network (i.e. between the tunnel endpoints). Please see Appendix B.1 of
> > draft-ietf-tsvwg-ecn-tunnel-08 for treatment of a similar issue.
> >
>
> With regard to this specific draft, I see the problem as a more
> generic issue which exists also for other protocols (e.g., RSVP)
> requiring per-hop processing to interact with IPSec. E.g., RFC4302
> mentions that "NOTE: Use of the Router Alert option is potentially
> incompatible with use of IPsec. Although the option is immutable, its
> use implies that each router along a packet's path will "process" the
> packet and consequently might change the packet.". I think that
> mentioning of this potential incompatibility will be beneficial. But I
> don't quite see how "limiting the bandwidth of the covert channel" as
> discussed in Appendix B.1 of draft-ietf-tsvwg-ecn-tunnel-08 can be
> applied here. Please correct me if I were wrong.
>
You can say this solution is incompatible with IPsec and be done with 
it. Otherwise, there is a "covert channel 
<http://en.wikipedia.org/wiki/Covert_channel>" - someone can create 
spurious NSIS signaling flows within the protected network, just to 
create signaling in the outside network, which then someone else is 
monitoring. For highly secure networks, this would be seen as a way to 
smuggle information out of the network, and you would want to rate-limit 
this channel.
> > 2. A more serious interaction in the other direction: unprotected 
> NSIS flows
> > outside the tunnel interact with NSIS flows in the protected 
> networks and
> > inside the tunnel, and so, an attacker in the unprotected network can
> > possibly influence QoS behavior in protected networks.
> >
> > 3. A practical result of (2) is that the NSIS protocol stack on the 
> tunnel
> > endpoint is now exposed to unprotected networks and therefore suddenly
> > becomes security-critical.
> >
>
> IMHO, if we have a segment of the path which is compromised, the QoS
> of the rest of the path segments (and the end-to-end QoS) can be
> easily affected anyway, whether you have a tunnel segment in the path
> or not. Therefore, it doesn't seem to me as a new threat introduced by
> this document per se. But it will certainly also be helpful to mention
> this scenario in the security considerations section.
What I'm saying in #3 is that any security vulnerability (e.g. buffer 
overflow) in the NSIS stack is suddenly exposed to the big bad Internet, 
even when the customer may have expected all their traffic to be 
protected by a VPN gateway, where the VPN software is normally the only 
software that needs to be hardened.
>
> > Non-Security
> >
> > The draft defines extra UDP encapsulation in some cases ("the tunnel
> > entry-point inserts an additional UDP header"), but the format
> > (specifically, the port number) is not specified. This omission is 
> strange,
> > because the protocol cannot be implemented in the absence of this
> > information!
> >
>
> To me this is an intended feature. The mechanism does not require a
> pre-allocated fixed UDP port, but allows the port to be dynamically
> chosen and conveyed during the tunnel flow/session binding operations.
>
Sure, I missed this point. Can you please mention it explicitly.

> Thanks
>
> Charles