Re: [secdir] SecDir review of draft-ietf-nsis-tunnel-11
Charles Shen <charles@cs.columbia.edu> Mon, 21 June 2010 15:15 UTC
Return-Path: <charles.newyork@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 94E6F3A6880 for <secdir@core3.amsl.com>; Mon, 21 Jun 2010 08:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Level:
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
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 SdLGMH90Vdjy for <secdir@core3.amsl.com>; Mon, 21 Jun 2010 08:15:37 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C63F63A6896 for <secdir@ietf.org>; Mon, 21 Jun 2010 08:15:14 -0700 (PDT)
Received: by iwn9 with SMTP id 9so600697iwn.31 for <secdir@ietf.org>; Mon, 21 Jun 2010 08:15:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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=L54bGqy6SHnRKVfj+xl3T2SPKJhpwBW8LpWMmKZjQEs=; b=qm9cQCKpq4pYgU+1A+ER2rXHfwwUE7IIwC8dVsdclwmzOHUUpN1DcqYCzMNaQtk9SY Mn1xRrlUV5DeWO2Pee/O0NN5EVc1rZqQAN/OXwBIwgeRJCDoSyWQ7OlpPNZdII1mAS9A 2z6Kgwn2fEwix69+TueP5Y6bOUYl8EoSjGp+8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; 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=IuKMGRLiGm88BsilzVCTFGaIhYFtSbvBV8u1vrXqJN2yyoR4RQdDA/Zb1swTQD598g rCVJc3FQ7Y7VY1XdSKqpQQ21JFr/GguJYA3GLsTcejVNYByc4dRVyXgNbO3K7UTTCjSM S4ozjSQ++LwHObyhr31UmFZ/l8032q8dv1ECI=
MIME-Version: 1.0
Received: by 10.231.156.1 with SMTP id u1mr6216773ibw.46.1277133318306; Mon, 21 Jun 2010 08:15:18 -0700 (PDT)
Sender: charles.newyork@gmail.com
Received: by 10.231.200.136 with HTTP; Mon, 21 Jun 2010 08:15:18 -0700 (PDT)
In-Reply-To: <4C1DFF97.1020103@gmail.com>
References: <4C148FB1.8060709@gmail.com> <AANLkTinw980xq5rcwzZMvrGRewuMs6YMu4s3XheGHmsB@mail.gmail.com> <4C1DFF97.1020103@gmail.com>
Date: Mon, 21 Jun 2010 11:15:18 -0400
X-Google-Sender-Auth: U1NiotVUXx-CrCaRiDYW3wdgxbQ
Message-ID: <AANLkTikC3xPjuYHlQTUQtfnhq_rEGQJDpi3R0I9ObW2S@mail.gmail.com>
From: Charles Shen <charles@cs.columbia.edu>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 22 Jun 2010 10:15:13 -0700
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: Mon, 21 Jun 2010 15:15:44 -0000
X-List-Received-Date: Mon, 21 Jun 2010 15:15:44 -0000
X-List-Received-Date: Mon, 21 Jun 2010 15:15:44 -0000
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
- [secdir] SecDir review of draft-ietf-nsis-tunnel-… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Charles Shen
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Charles Shen
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-nsis-tun… Charles Shen