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

Yaron Sheffer <> Sun, 04 July 2010 13:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4F143A680D for <>; Sun, 4 Jul 2010 06:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZxkKK3p1mmeE for <>; Sun, 4 Jul 2010 06:13:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B5CA3A67FA for <>; Sun, 4 Jul 2010 06:13:14 -0700 (PDT)
Received: by wwb24 with SMTP id 24so1092098wwb.13 for <>; Sun, 04 Jul 2010 06:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=R4y+XG6/M9yhQDtYPSl72XXdXDECfRgfsgKTSAA1mkE=; b=Ju0fIjCccAeTSVTjqYTnT0vzKY+7GUgAOFn24MukkoFOiGhXc9jq7EDIvYR7P89n7s Oa8SLyx5s2ltqhdu/iI5xXZHy0gC9dWaFK1lHJ+csXYI2yy0LG+lpDT0uLnDIABY4vrW D59pJCycoJwxK82WZTiia6lQE1DfgXxIsoRzo=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=IsQSCFETFKThdTPpA7le9hXMqAEqhTeP2veC0MP+pgBXALMrSoqoVgj76KFdySzG2+ uf1cGn5nPjnzw4t8KfErR7ndGOICYCmpK6uVtKOXBOwnWO7i5ASKFJ7DuZjQdZeOhxgC wLFcDy+KGjmdYfkOFjH/+mXFDAGv0TVjX+Rhs=
Received: by with SMTP id z3mr1764617wbt.179.1278249189226; Sun, 04 Jul 2010 06:13:09 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id i25sm23066522wbi.16.2010. (version=SSLv3 cipher=RC4-MD5); Sun, 04 Jul 2010 06:13:08 -0700 (PDT)
Message-ID: <>
Date: Sun, 04 Jul 2010 16:13:05 +0300
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Charles Shen <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Sun, 04 Jul 2010 13:13:16 -0000

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.


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