Re: [OSPF] Brian Haberman's No Objection on draft-ietf-ospf-te-metric-extensions-10: (with COMMENT)

joel jaeggli <joelja@bogus.com> Tue, 06 January 2015 17:13 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1D01A1A90; Tue, 6 Jan 2015 09:13:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 5h9qg1v8oIO2; Tue, 6 Jan 2015 09:13:24 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 304771A1A4A; Tue, 6 Jan 2015 09:13:24 -0800 (PST)
Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t06HDKXT048741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Jan 2015 17:13:21 GMT (envelope-from joelja@bogus.com)
Message-ID: <54AC17AB.4040908@bogus.com>
Date: Tue, 06 Jan 2015 09:13:15 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>, 'Brian Haberman' <brian@innovationslab.net>, 'The IESG' <iesg@ietf.org>
References: <20150106145509.2890.85698.idtracker@ietfa.amsl.com> <03f601d029c8$48746510$d95d2f30$@olddog.co.uk>
In-Reply-To: <03f601d029c8$48746510$d95d2f30$@olddog.co.uk>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="PCxwAiXopuL40c1qlPBVbLhrPqee8pxWK"
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/UTO3Ao4mWME799zJ23stndmSF38
Cc: ospf@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org
Subject: Re: [OSPF] Brian Haberman's No Objection on draft-ietf-ospf-te-metric-extensions-10: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jan 2015 17:13:26 -0000

On 1/6/15 7:48 AM, Adrian Farrel wrote:
> Brian and Stephen,
>
> While I agree that the Security section of this document could have included more references to state of the art OSPF security, I believe this has been fixed in -10. So I find myself wondering ...
>
>> I agree with Stephen that the specified use cases seem to warrant a
>> stronger recommendation to provide authentication and confidentiality.
>> The tools are available, so why are they not being recommended in this
>> instance?
> What is it about these specific TLVs in an TLV of an existing opaque LSA that cause you to see a higher concern for authentication and confidentiality than the previously existing ones?
>
> Do you, for example, think that an attacker might cause more damage by inserting an LSA containing a Unidirectional Link Delay TLV than it would by inserting an LSA containing a Local interface IP address TLV? As far as authentication is concerned, an attacker that is able to inject LSAs into the OSPF network is able to do considerable and "interesting" damage.
>
> Do you consider that the information in a Unidirectional Residual Bandwidth TLV is more sensitive to sniffing than, say, the Shared Risk Link Group TLV? The value of confidentiality of on-wire IGP advertisements will depend on the network and the planned attack. What can you work out from the delay metrics? Possibly short link length makes a link more interesting to attack because it will be carrying more valuable data? But it is the end-to-end delay that is used to determine where to place traffic, not the delay on any one specific link.
The implications for having a miscreant participate in your igp are
pretty dire, but I've at a loss to understand how they become more dire
with new tlvs. ospf md5 auth or ospfv3 esp encapsulation with static
keying is basically something an operator uses to prevent adjacency from
accidentally configured devices.

> What am I missing about your concerns?
>
> Thanks,
> Adrian
>
>
>
>
>