[secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-11
Yoav Nir <ynir.ietf@gmail.com> Thu, 09 June 2016 13:12 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B241E12D61C; Thu, 9 Jun 2016 06:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 thlR6qmV0fsm; Thu, 9 Jun 2016 06:12:21 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 A583F12D639; Thu, 9 Jun 2016 06:12:20 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id n184so224816865wmn.1; Thu, 09 Jun 2016 06:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=FawuBGZTA9We8STA016hzginUM34diLDv704xCyBT50=; b=KF1lbMYOyhGE7Xd6jWIalBZq4+z/pOOf8FqX8yTegnVov1b7/xegSqr6gQOjgyGZoU lcKCD++FdrH3ZNICoGdkhLrrQjwRr8h9ibT2xI1Xxycwa4sttjRDrl5PaINnKivXoO0q iixLj/NfnkoerdnDOjMbTRf7c4/8yw5mQ4X3LjMJKLkei9zxUqbKT7Vmcsr1SFgC0KZO HNMK4Y4eDcNK6WR8sHFOo9Uc5d5MBx8XRS2s4Qb2u7vL/tXJN3sarHFTHlPfGYF8GvCQ Vi/T9kaTHldumzxURhow4lXh5I+O6FstcZIKU2lLVL0jYtSKIqpaJ+lYUo2UNwaE+/Ce 3u5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=FawuBGZTA9We8STA016hzginUM34diLDv704xCyBT50=; b=SljuzzTZufe2FKCYPo8hH6IH6HU2+AD4D+Wx7BEycmjCrXH5NR7tluFILwNlCxd7vd G0kZHQvLwxacOnYPE3NgsNqUPO84WplhLMSXil7LtAdnAfylhFOTu8zZPdWbWz8XVxIp XH26+V4t2IWqmQLLbt2OrzY4Ck6GzxJ63z8P7fHRiaUKFQA5l7VbOLSslwpjLB8xJloT gQooFckHgIirlutNvwKUrU2RN3OXn0tUtZIlBdYr5tMcn8vBYtpxnEXzZRfOq4hbBMhw satGjvQ3WPPdwe4JEDCcsQ1YhDHd2yar0aP+p0gOu9K2lhfFVjZZujqXJFbXbWoEG5Nh rQEQ==
X-Gm-Message-State: ALyK8tKY9n8CrX+rDCh7FfbMEYTulJM2YQCiKsCS3De/+sfNOhpx9qgQaUQySBupHnfbfQ==
X-Received: by 10.28.184.199 with SMTP id i190mr9778585wmf.57.1465477938970; Thu, 09 Jun 2016 06:12:18 -0700 (PDT)
Received: from [172.24.249.196] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t199sm7622198wmt.11.2016.06.09.06.12.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 06:12:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <E5B612D4-1F40-4061-8180-797394A96784@gmail.com>
Date: Thu, 09 Jun 2016 16:12:15 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <78EC7A14-FA30-4369-9059-90EE1C51B21D@gmail.com>
References: <E5B612D4-1F40-4061-8180-797394A96784@gmail.com>
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-rtgwg-bgp-routing-large-dc.all@ietf.org
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4VfELutCLodiABNhU2KedKHi4wI>
Subject: [secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 09 Jun 2016 13:12:23 -0000
Hi The new version addresses my concern from the message below. The document is now ready IMO. Thanks Yoav > On 5 May 2016, at 10:24 AM, Yoav Nir <ynir.ietf@gmail.com> wrote: > > Hi. > > 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. > > Summary: Almost Ready > > This document is an Informational discussion of packet routing within data centers. It describes existing practice with using layer-2 protocols such as STP or TRILL, hybrid setups, and layer-3 routing protocols, mostly IGPs. It finally recommends replacing these with EBGP and a Clos structure. The document is very clear and quite an interesting read. > > The document does not deal with security questions such as what kind of damage a rogue node can do, and that is fine. That is not the subject of this document. > > My one issue is with the Security Considerations section. Section 9 defers to the BGP RFCs (4271 and 4272) for the security considerations. This is a common pattern and it's usually fine, but in this case it is missing something. RFC 4271 requires the use of TCP-MD5 (RFC 2385) for authenticating the BGP connections between routers. RFC 4271 also mentions (but does not solve) the problem of key management. ISTM that in a large-scale and dynamically scalable data center, the problem of key management should be addressed. It might also be nice to use something less antiquated than TCP-MD5. > > Now it's possible to decide that all elements within the data center are trusted and under the administrator's control, and that therefore no authentication is necessary as long as BGP is somehow blocked from outside the DC to internal nodes. But if these assumptions exist, I believe they should be stated. > > Yoav