[secdir] draft-ietf-trill-pseudonode-nickname-06

Carl Wallace <carl@redhoundsoftware.com> Sat, 12 September 2015 19:59 UTC

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4B01B4B8A for <secdir@ietfa.amsl.com>; Sat, 12 Sep 2015 12:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMtI8M0iZZgs for <secdir@ietfa.amsl.com>; Sat, 12 Sep 2015 12:59:53 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814F21B4B83 for <secdir@ietf.org>; Sat, 12 Sep 2015 12:59:53 -0700 (PDT)
Received: by qgez77 with SMTP id z77so88337606qge.1 for <secdir@ietf.org>; Sat, 12 Sep 2015 12:59:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=6+huL74/FqUxQw8oBn8snGm0W2OfRarP5rO/CGAiNMs=; b=dklU1l3EsYkA2RmF2iXTD0vW8gaPfPwfTxRT3OB9bVukZYoImXnu0ofPjlUefaCxvc jCEfBNyDAc2/4/e47b1qflkibE0/tzt7AZ8tdyVBNwH5YKf8c1Zjmok02ZCwHLntCkVj CJ0hkK6PDtoeJLPPPwf4rMtjeO0tlFP/ci+iB+w4HaAt4TEw2OPK2Pm1N04E9M0GEuMY R3nMp3C2HRIrmVh0r/1CfrbFhwyQE/0CpTURXxvToGRHo3WVvPUzH3hlx5+cLx+6bAv4 G+jy/yE8hGAwKJAl2NI9ScRKQ7JsL1o4yryJJ4n3RcBbYOzY1EXd7f4dfS7VvEKZ7nXT SLeg==
X-Gm-Message-State: ALoCoQkeczLE6P22CczSKQxsx5d2rlGbtgtDxYPakckzLXfQL8HTGX2SXki7AkZTJreisnVqc8VD
X-Received: by 10.140.218.133 with SMTP id o127mr9379285qhb.4.1442087992689; Sat, 12 Sep 2015 12:59:52 -0700 (PDT)
Received: from [192.168.2.27] (pool-173-66-90-83.washdc.fios.verizon.net. [173.66.90.83]) by smtp.gmail.com with ESMTPSA id v34sm2613730qge.47.2015.09.12.12.59.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 12 Sep 2015 12:59:51 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.5.4.150722
Date: Sat, 12 Sep 2015 15:59:48 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: <draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org>
Message-ID: <D219FC74.3E6A6%carl@redhoundsoftware.com>
Thread-Topic: draft-ietf-trill-pseudonode-nickname-06
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/9ZMTOv6CK7P6GYnA8agTqjGnM-s>
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] draft-ietf-trill-pseudonode-nickname-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 12 Sep 2015 19:59:55 -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.

This document describes use of pseudo-nicknames for RBridges in an
Active-Active Edge RBridge group. I am not familiar with TRILL but found
the document to be well written and easy to follow. I did have one
question, which may just be due to my lack of familiarity with relevant
normative specs. The second paragraph of section 8 states the following:

	"However, for multi-destination TRILL Data packets, since they can reach
all member RBridges of the new RBv and be egressed to CE1 by either RB2 or
RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the
packet's Inner.Label maps to in the new RBv), special actions to protect
against downlink failure for such multi-destination packets is not
needed."	 

Why is there no race condition between the arrival of multi—destination
traffic and the creation of a new RBv following the failure of RB1 that
enables the traffic to be forwarded? Generally, mentioning failure of the
DF for the virtual RBridge seemed like it might warrant mention in the
security considerations section, since that is new relative to the specs
noted in the current security considerations.