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

Charles Shen <> Tue, 06 July 2010 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D54A3A63CB for <>; Mon, 5 Jul 2010 17:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V0-ydv6-Yo3W for <>; Mon, 5 Jul 2010 17:59:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1333A3A67F3 for <>; Mon, 5 Jul 2010 17:59:36 -0700 (PDT)
Received: by iwn38 with SMTP id 38so399532iwn.31 for <>; Mon, 05 Jul 2010 17:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=X6YwSDEnUQaY9mLecVjZ1AUYMjhPgaOU0LDq8oQDWc8=; b=BRB2nvwaI8qUkPwC9XwqWPqmpJvgyMeqEXPpogd+tMDQhp8HssvB7NouqpqJD+ZN3w 1gwxz1k4JCi8S0UzLzFcrkV/FRkqOtPmVcAk4+wuAThP7MsZ1SySIZvHxGQciImmE7lK CQIZA41yjkb/FXXHQV6L1eSCYbRC9i6Y6DLxg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=t8jHVqPuX3rMfEH62v1yiTqv2QrgPSQd/NYwMWyNVi9NTmHA4AdmMmZenSzCCmtBJ5 s1UuDbt6pQ/yFsERdAlhg9vXZjElDrCy/4or085WSglROvwGgMXdsKGpsnrEZ1lFfHcW jEr95bvGu0J2Zh/LX1vj8xeWbvHnyxni9/DpQ=
MIME-Version: 1.0
Received: by with SMTP id u9mr3773357ibz.17.1278377977592; Mon, 05 Jul 2010 17:59:37 -0700 (PDT)
Received: by with HTTP; Mon, 5 Jul 2010 17:59:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 5 Jul 2010 20:59:37 -0400
X-Google-Sender-Auth: ibE5BLhzPOmHqvzu8899Eo2D090
Message-ID: <>
From: Charles Shen <>
To: Yaron Sheffer <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:02 -0700
Cc: Henning Schulzrinne <>,,
Subject: Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11
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: Tue, 06 Jul 2010 00:59:37 -0000

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.


On Sun, Jul 4, 2010 at 9:13 AM, Yaron Sheffer <> 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<>
>>  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<>
>>>>  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
>>> <>" - 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