[OPSEC] Comments on draft-jdurand-bgp-security

Ronald Bonica <rbonica@juniper.net> Tue, 07 August 2012 14:40 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E06B21F853D for <opsec@ietfa.amsl.com>; Tue, 7 Aug 2012 07:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.575
X-Spam-Level:
X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXlgeAqrLLzw for <opsec@ietfa.amsl.com>; Tue, 7 Aug 2012 07:40:33 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id DCA0F21F8532 for <opsec@ietf.org>; Tue, 7 Aug 2012 07:40:32 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUCEo3/b0rY1kHsQDA0dhBKHC26Q3EIQx@postini.com; Tue, 07 Aug 2012 07:40:32 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 07:38:34 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 10:38:33 -0400
From: Ronald Bonica <rbonica@juniper.net>
To: "opsec@ietf.org" <opsec@ietf.org>
Date: Tue, 07 Aug 2012 10:38:32 -0400
Thread-Topic: Comments on draft-jdurand-bgp-security
Thread-Index: Ac10qlFrY5+NYzLkQSyU572HanPu5g==
Message-ID: <13205C286662DE4387D9AF3AC30EF456D77178BB80@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OPSEC] Comments on draft-jdurand-bgp-security
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 14:40:34 -0000

Authors,

Thanks for writing draft-jdurand-bgp-security. On the whole, it is a very well written document. The following are a few comments:

Section 2.5
============
Somewhere between Section 2 and Section 3, you should mention that the BGP process needs to be protected from stray packets. Protection can be achieved by applying a forwarding plane ACL. The ACL accepts all packets that meet the following criteria:

- directed to TCP port 179 on the local device
- sourced from a known BGP neighbor

It discards all packets directed to TCP port 179 on the local device and sourced from an address not known to be a BGP neighbor.


Section 3.1
============
In Section 3.1, you talk about MD5 Password Protection. This make the reader think that you are talking about RFC 2385. However, the reference is to RFC 5925 (TCP-AO). Please be clear about which you are recommending.

In this regard, we have a dilemma. The IETF has obsoleted RFC 2385 and replaced it with RFC 5925. However, to the best of my knowledge, there are no commercially available implementations.

Section 4.1.1.1
===============
Rather than listing every IPv4 special-use address, you might want to simply refer the reader to RFC 5735 and 5736.

Section 4.1.1.2
================
Rather than listing every IPv6 special-use address, you might want to refer the reader to http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml. It might be better to refer the reader to the registry, because it will be kept up to date in the future.


Section 4.1.3
=============
It is true that most ISPs will not accept advertisements beyond a certain level of specificity. However, this is an issue to be worked out between the operators, and not an issue for standardization.

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf