[secdir] Secdir review of draft-ietf-softwire-gateway-init-ds-lite

Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 04 January 2012 13:00 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A3A7921F8715 for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2012 05:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZX6yK8eHu460 for <secdir@ietfa.amsl.com>; Wed, 4 Jan 2012 05:00:31 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org []) by ietfa.amsl.com (Postfix) with ESMTP id 8184B21F86D1 for <secdir@ietf.org>; Wed, 4 Jan 2012 05:00:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fj1qibpSU75/00Jf85dpgiksn/SYul/imUQQ6U96Hb35H5lsG15WJLXrUgaDQZF21XKqRFbo21SRPfPzmCTMheO25hABvcUKo/+wx8MoS/U5N/EDjFdiSE9VEyVELfQp; h=Received:Received:Message-ID:Disposition-Notification-To:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type;
Received: (qmail 3826 invoked from network); 4 Jan 2012 14:00:05 +0100
Received: from unknown (HELO ? ( by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2012 14:00:05 +0100
Message-ID: <4F044D50.7090709@gondrom.org>
Date: Wed, 04 Jan 2012 13:00:00 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: draft-ietf-softwire-gateway-init-ds-lite.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org
Content-Type: multipart/alternative; boundary="------------090104030409090802010707"
Subject: [secdir] Secdir review of draft-ietf-softwire-gateway-init-ds-lite
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 04 Jan 2012 13:00:31 -0000

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.

The Security Considerations of this document refer to four other 
documents. Unfortunately it does not state whether any new security 
issues are introduced by GI-DS-lite (or claims that no additional 
security issues are introduced by this spec).

A few security questions come to mind reading the spec:
- is there an implication that it is allowed to establish the softwire 
between Gateway and AFTR at any point in time (not just startup)?
- does the required uniqueness of combination of CID and SWID result in 
any attack vectors?
(btw. in section 3 do you mean "The combination of CID and SWID must be 
unique between gateway and AFTR" or "The combination of CID and SWID 
MUST be unique between gateway and AFTR"
- to define that the translation scheme configuration will be done 
either manually or out-of-band seems to solve some security worries, 
however, does this imply these MUST be done manually or out-of-band 
(e.g. for security purposes)?

I am concerned about the weak or possibly not proper use of RFC2119 
wording in wide parts of the drafts. In several cases I would expect 
RFC-2119 language instead of the currently used can/may/must (e.g. take 
a read of section 4 and 5).

Section 1:
s/GRE based encapsulation mechanisms is chosen/a GRE based encapsulation 
mechanism is chosen

Best regards, Tobias