[OPSEC] some thoughts on draft-jdurand-bgp-security-02.txt

joel jaeggli <joelja@bogus.com> Mon, 29 July 2013 05:51 UTC

Return-Path: <joelja@bogus.com>
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 7F7E621F9F8E for <opsec@ietfa.amsl.com>; Sun, 28 Jul 2013 22:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yUuKNlQDIFq1 for <opsec@ietfa.amsl.com>; Sun, 28 Jul 2013 22:51:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD06221F99F2 for <opsec@ietf.org>; Sun, 28 Jul 2013 22:51:27 -0700 (PDT)
Received: from dhcp-603a.meeting.ietf.org (dhcp-603a.meeting.ietf.org [130.129.96.58]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r6T5pOvU045057 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 29 Jul 2013 05:51:26 GMT (envelope-from joelja@bogus.com)
Message-ID: <51F602DA.7060502@bogus.com>
Date: Mon, 29 Jul 2013 07:51:22 +0200
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0
MIME-Version: 1.0
To: "opsec@ietf.org" <opsec@ietf.org>, draft-jdurand-bgp-security@tools.ietf.org
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 29 Jul 2013 05:51:27 +0000 (UTC)
Subject: [OPSEC] some thoughts on draft-jdurand-bgp-security-02.txt
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: Mon, 29 Jul 2013 05:51:30 -0000

since this is on the agenda I'd thought I'd add some comments

section-4 worth noting citing/rfc 6192

Protecting the Router Control Plane

section 5.1.2.3

these sections are too deep. needs better organization, e.g. section 5
is actually probably two or three sessions.

e.g.

5.1.1. Prefixes that MUST not be routed by definition

Most of Regional
Internet Registries do also operate an IRR and can control that
registered routes conform to allocations made.


3 of 5

should cite

http://tools.ietf.org/html/rfc4012

rpsl

would be helpful to cite irrtoolset provide an example in an appendix.

the tier one example isn't that helpful would be more interesting to
cite the example for a customer vantge point e.g. managing objects so
that your upstreams will accept them.

----

rpki section needs to be fleshed out e.g. what you do with it, how it's
used what it can't be used for needs examples.

The rest of this
section assumes the reader understands all technologies associated
with SIDR.

Whut???????

5.1.4

mixes customer prefixes filtering policy with local prefixes…

issues around loop-detection (e.g. disconnected islands) vs more
specific(s) e.g. hijacking.

outbound filtering (prefix advertisement)

5.3 and later

prefer to think of these things as import/export policy rather than
describing everything as filter.

8.

o Do not accept overly long AS path prepending from the customer.

going to have to scope that.