Re: [secdir] Secdir review of draft-ietf-grow-ix-bgp-route-server-operations-03

Nick Hilliard <nick@inex.ie> Wed, 17 September 2014 21:59 UTC

Return-Path: <nick@inex.ie>
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 0A0561A6F99; Wed, 17 Sep 2014 14:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Dk7ZcStAX2No; Wed, 17 Sep 2014 14:59:37 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A301B1A6F98; Wed, 17 Sep 2014 14:59:36 -0700 (PDT)
X-Envelope-To: secdir@ietf.org
Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100::110]) (authenticated bits=0) by mail.netability.ie (8.14.9/8.14.5) with ESMTP id s8HLxPYw078990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Sep 2014 22:59:26 +0100 (IST) (envelope-from nick@inex.ie)
X-Authentication-Warning: cheesecake.netability.ie: Host [IPv6:2001:4d68:2002:100::110] claimed to be cupcake.foobar.org
Message-ID: <541A043C.8070708@inex.ie>
Date: Wed, 17 Sep 2014 22:59:24 +0100
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, iesg@ietf.org, secdir@ietf.org, draft-ietf-grow-ix-bgp-route-server-operations.all@tools.ietf.org
References: <9F322527-7D45-4A6C-9928-5F71DB9D948C@nrl.navy.mil>
In-Reply-To: <9F322527-7D45-4A6C-9928-5F71DB9D948C@nrl.navy.mil>
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7fSIFwUvH-Is6ngxVhQdpEMoZwY
Subject: Re: [secdir] Secdir review of draft-ietf-grow-ix-bgp-route-server-operations-03
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: <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, 17 Sep 2014 21:59:40 -0000

Catherine,

thank you for taking the time to review this draft.

On 17/09/2014 21:09, Catherine Meadows wrote:
> My only criticism of the Security Considerations section is that the
> issues are not described in very much detail.  It would be helpful to
> have references to other documents where more information is given. 
> Otherwise I find myself asking questions such as “What are the ‘certain 
> circumstances’ under which the path hiding problem can be exploited”

The intention of this sentence was to notify route server operators that
there were security issues associated with path hiding, and a reference was
given to ietf-idr-ix-bgp-route-server where the problem was explained more
clearly.  As the two drafts share the same authors, we felt that it was
better not to have overlap between the two, as there is some virtue in brevity.

> and
> “How is it trivial for a route server to implement denial of service if
> prefix leakage mitigation is not implemented?”

We could change that sentence to:

"...it is trivial for route server clients to implement denial of service
attacks against arbitrary Internet networks by leaking prefixes to a route
server."

Leaking prefixes is trivia -- and disturbingly common.

> Also, a nit.  I found the summary of  path hiding in Section 4.1 a
> little misleading:
> 
> "Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to 
> describe the process whereby a route server may mask individual paths by
> applying conflicting routing policies to its Loc-RIB.
> 
> This gave me the impression that path hiding is something done 
> deliberately, when actually it appears to be an unintended side effect.

Path hiding may or may not be intentional.  We deliberately left the
wording non-specific.

Nick