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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 06 July 2010 12:57 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 1F9BA3A6863 for <secdir@core3.amsl.com>; Tue, 6 Jul 2010 05:57:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 PuDR8K8XTJAg for <secdir@core3.amsl.com>; Tue, 6 Jul 2010 05:57:36 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 404D53A6876 for <secdir@ietf.org>; Tue, 6 Jul 2010 05:57:36 -0700 (PDT)
Received: by ywa8 with SMTP id 8so6190ywa.31 for <secdir@ietf.org>; Tue, 06 Jul 2010 05:57:35 -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=iTUfKNIAWJMVtCyakAjWiLBcamXtpuxPjd0JqAgF2lo=; b=e6OgHFK2p5Ed0paCgBy3d+AxlFtRAb++nf18yAaUFJbdmVQj1+aVKFlBh+egVeIEzo PQdy9uua+lMwp/Osbn1+OGux590ROe41ii5aSkuB+kzHIfyYVRVfXz5FejDTruJNeZuz bGki6dtUYvmBpsFmS3dl8A5dh07zrEqMGVui8=
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=pA5rFTE9jrrbB90TBsmZd9rd0CxnvW+HeqdgTrktpaV/1pS47DAiEyKmZcwp4LxIZD kNUR7IaLrocBTqJNhDDt6e56Ez7eTckS/ke4hOuWGG4WRXAv0lkizPkqpRWnNwW5gqkI ZcukH97nZtitjrPS4aalksCMa5+U1zi24FkxI=
Received: by 10.213.32.197 with SMTP id e5mr4126960ebd.92.1278421054839; Tue, 06 Jul 2010 05:57:34 -0700 (PDT)
Received: from [10.0.0.1] ([109.67.45.226]) by mx.google.com with ESMTPS id a48sm50129446eei.12.2010.07.06.05.57.31 (version=SSLv3 cipher=RC4-MD5); Tue, 06 Jul 2010 05:57:33 -0700 (PDT)
Message-ID: <4C332838.4070607@gmail.com>
Date: Tue, 06 Jul 2010 15:57:28 +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> <4C1DFF97.1020103@gmail.com> <AANLkTikC3xPjuYHlQTUQtfnhq_rEGQJDpi3R0I9ObW2S@mail.gmail.com> <4C3088E1.6000100@gmail.com> <AANLkTileEN98KZ6Pd6MavLKIj6b7D7bzm6M-PQ8D4ZiX@mail.gmail.com>
In-Reply-To: <AANLkTileEN98KZ6Pd6MavLKIj6b7D7bzm6M-PQ8D4ZiX@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; 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: Tue, 06 Jul 2010 12:57:38 -0000

Looks good to me.

Thanks,
	Yaron

On 07/06/2010 03:59 AM, Charles Shen wrote:
> Hi Yaron, I have just submitted a revised version. please take a look
> and let me know if you have any further comments.
>
> Thanks again.
>
> Charles
>
>
>
>
> On Sun, Jul 4, 2010 at 9:13 AM, Yaron Sheffer<yaronf.ietf@gmail.com>;  wrote:
>> Hi Charles,
>>
>> I have been assigned your draft for a secdir re-review. The draft has not
>> been revised since my last review, so I will just reiterate: I recommend
>> that the Security Considerations be improved before the document goes into
>> IESG telechat.
>>
>> Thanks,
>>         Yaron
>>
>> On 06/21/2010 06:15 PM, Charles Shen wrote:
>>>
>>> Thanks Yaron, please see inline.
>>>
>>> On Sun, Jun 20, 2010 at 7:46 AM, Yaron Sheffer<yaronf.ietf@gmail.com>;
>>>   wrote:
>>>>
>>>> [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.
>>>>>
>>>
>>> That makes sense. My understanding is that the rate-limit does not
>>> complete solve the problem, but does reduce the potential harm.
>>>
>>>
>>>>>> 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.
>>>
>>> I agree. What I had been thinking is that compromise of other nodes
>>> (non-tunnel end-points) may similarly affect end-to-end QoS signaling,
>>> even if the end-to-end path includes a secure tunnel.
>>>
>>>>>
>>>>>> 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.
>>>>
>>>
>>> Sure!
>>>
>>> Thanks
>>>
>>> Charles
>>