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

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 06 January 2015 15:49 UTC

Return-Path: <adrian@olddog.co.uk>
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 AE1DA1A8853; Tue, 6 Jan 2015 07:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 l-VdCaDHURHa; Tue, 6 Jan 2015 07:49:04 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9272B1A87E6; Tue, 6 Jan 2015 07:49:03 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t06FmwVD008660; Tue, 6 Jan 2015 15:48:58 GMT
Received: from 950129200 (089144196255.atnat0005.highway.a1.net [89.144.196.255]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id t06FmuTP008626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 15:48:57 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Brian Haberman' <brian@innovationslab.net>, 'The IESG' <iesg@ietf.org>
References: <20150106145509.2890.85698.idtracker@ietfa.amsl.com>
In-Reply-To: <20150106145509.2890.85698.idtracker@ietfa.amsl.com>
Date: Tue, 06 Jan 2015 15:48:55 -0000
Message-ID: <03f601d029c8$48746510$d95d2f30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIcK7x/tT4GWsbWPiHe0mnocRxiQJwbNEjA
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21226.007
X-TM-AS-Result: No--10.289-10.0-31-10
X-imss-scan-details: No--10.289-10.0-31-10
X-TMASE-MatchedRID: u7Yf2n7Ca/3PwZWTvltloXBRIrj8R47FwLlnHU0okA2SeV7T1XnwPfcP PfNzWVVPXP1H+XULAzxcHyoC9xsa8sDS5aC1uIczA9lly13c/gEL8TGleseLPI1Oeo4wEgnhHOW W/Rp/isp1W4HmMJd/09RKnavHM9xjCkuRNdaXSpRm85QoNuKKvlF5adRR2Ej1zAdJD7JeNMPcRk EWamG/l2uZ7LA6Q8diNwyDfqjDRQQMRVPkzQcfheJmMZmLmwx5I5K4Cd+0ao/jsTquy0JRi+KfV RMbjCR2hN6Lovduog2FOxrHL5nNb9aSgJLPelTm5gCHftmwEMLjAcZeNJgY95soi2XrUn/JmTDw p0zM3zoqtq5d3cxkNUc3U9YVGz98hWBf52y02NiUAGytsmcfd6R/jilAk8/oskFqUIGLP4s=
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/BwY6HaYiPbC7xSTOIOj9OI3PgjU
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
Reply-To: adrian@olddog.co.uk
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 15:49:06 -0000

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.

What am I missing about your concerns?

Thanks,
Adrian