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

Charles Shen <> Sun, 20 June 2010 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 666153A686B; Sat, 19 Jun 2010 20:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ouuS9Kc7YjRi; Sat, 19 Jun 2010 20:52:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1A7843A67C1; Sat, 19 Jun 2010 20:52:48 -0700 (PDT)
Received: by qyk5 with SMTP id 5so21577qyk.31 for <multiple recipients>; Sat, 19 Jun 2010 20:52:51 -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=+FSnrpftDE/uZ3wUv+unxjKSOjE1jjWWvK1ofrPmTGA=; b=NFaQwSMYmBTTgPVh//nYzlOf10rWcm/2EbKZj8XVKzy7tECUNiIW9ba3Y+KXnNfJe4 FDguqKkubkuXFI7qzRKbrbGkMBTDC3qQ7W7p6SBdtkmqvXwpsb4+Vak9Q/Ct2jFGauMH N3mXTqR0AKA+28gTab8LvenKL/dK4m2MaWPXg=
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=xlmO+0zIMtu1fHlcXObJE8IUy/bybEeU0z7/7lpCG3370FihkVEyKfeaIorqcGkDPp /+KE8zaZtEGUIHftwv65KVLlod2LLyhbQ2j1Ms4v3RVjzUr0wAqUwlLjnyNIwY0EvzYl kVPaFXfhfkkjc+g3VBeoSbu1CLGeK1y1fejNw=
MIME-Version: 1.0
Received: by with SMTP id d18mr2218476qae.158.1277005971720; Sat, 19 Jun 2010 20:52:51 -0700 (PDT)
Received: by with HTTP; Sat, 19 Jun 2010 20:52:51 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sat, 19 Jun 2010 23:52:51 -0400
X-Google-Sender-Auth: WNhbowQ89MKC-OBeNnegUV3eyVM
Message-ID: <>
From: Charles Shen <>
To: Yaron Sheffer <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 21 Jun 2010 05:23:19 -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: Sun, 20 Jun 2010 03:52:49 -0000

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.

> 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.

> 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.