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

Brian Haberman <brian@innovationslab.net> Tue, 06 January 2015 17:17 UTC

Return-Path: <brian@innovationslab.net>
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 CEB2E1A0394; Tue, 6 Jan 2015 09:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9SvqwqNs6qT2; Tue, 6 Jan 2015 09:17:45 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7EF1A036C; Tue, 6 Jan 2015 09:17:45 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 933EA88134; Tue, 6 Jan 2015 09:17:45 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CF12671C0002; Tue, 6 Jan 2015 09:17:44 -0800 (PST)
Message-ID: <54AC18B1.1080404@innovationslab.net>
Date: Tue, 06 Jan 2015 12:17:37 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>, '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-sha512; protocol="application/pgp-signature"; boundary="XqHm4l0nOWoRkxbN7Oqab6FW6QfcqXpO9"
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/4m6HEd35dFtl_h3cneQww7abSpU
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:17:48 -0000

Hi Adrian,

On 1/6/15 10: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 ...

http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-10#section-11
does say that RFC 5709  and
draft-ietf-ospf-security-extension-manual-keying provide additional
protection for OSPFv2, but it doesn't suggest/recommend that they be used.

> 
>> 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?

As Stephen put it, if there is a lot of money involved it makes sense to
recommend a stronger level of protection.  But, more generally, I think
the world has changed enough that we need to be making stronger
recommendations to protect all information.

> 
> 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.
> 
> What am I missing about your concerns?

If I can make routers believe that a particular link has a high delay, I
can make that router send the traffic over a different link that I know
has a longer delay.  Even a few milliseconds difference in data transfer
can have a huge impact on micro-trading houses.

Despite the above example, I don't think we need to be judging the
relative importance of TLVs, but rather the general issue that if
someone can spoof these TLVs they can influence TE decisions being made
in routers.

Regards,
Brian