Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 04 January 2015 09:40 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 5639A1A7007; Sun, 4 Jan 2015 01:40: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 yub--e-Y-2Py; Sun, 4 Jan 2015 01:40:04 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72141A6F3A; Sun, 4 Jan 2015 01:40:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t049dlIN019334; Sun, 4 Jan 2015 09:39:47 GMT
Received: from 950129200 (089144225062.atnat0034.highway.a1.net [89.144.225.62]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id t049djww019328 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 09:39:46 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "'The IESG'" <iesg@ietf.org>
References: <20150104020718.29256.7059.idtracker@ietfa.amsl.com>
In-Reply-To: <20150104020718.29256.7059.idtracker@ietfa.amsl.com>
Date: Sun, 4 Jan 2015 09:39:45 -0000
Message-ID: <00d301d02802$60ed8990$22c89cb0$@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: AQHIbnREDHj8rln2+zSSDBUPDhGssZy/IG0w
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21222.006
X-TM-AS-Result: No--5.483-10.0-31-10
X-imss-scan-details: No--5.483-10.0-31-10
X-TMASE-MatchedRID: 0dFPYP4mu5QdVBXyH4TZjlaOpp/sV5nVVBDQSDMig9GqvcIF1TcLYBQT IYYoaUJC7bRGoKf05y1iVR5v4/csaU79+Npt/85FiUPZPmKZOQnomPrNi98UBGsxtqQk3w55TQz WIn91PFkOO2Gvl48O38Eer++Nt4GLKDJiqR5tgrXAJnGRMfFxyQ/80a3o2lzSEoJn5DrIHyoGIz NAJ7Ui2UB8I6NdsnKtbMVYGIFPJzCcj7jn01TtBge06kQGFaIWlnrMq7Sriu1UvqB5o/LqcxoJW w+GnpANxpoTmyihHA+ayMMdUAjTDZR1QS4wQ6454T0EFRcNxxTLvf5EDoNoilpbYq2f4jz+eYND 6G9gP8DRlpG99KwFV/EeAou1C0jhZP2HNi+vOdaGwT67eecJ8JRaYX0SmKrq2e73tJcoE9hZwdT Is6xF73ZsfV6c7x17sbkn7RfbWLYCarE6rzj92Fu4M/xm4KZefS0Ip2eEHnzWRN8STJpl3PoLR4 +zsDTtT2FZqUzXVBpcbr0N0AFvDhVymey2cdDIpKpdkxvp33PIWiQBkLadDVZca9RSYo/b
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/TW1IffL7zcp4XX6hre4P7Tk91sc
Cc: ospf@ietf.org, ospf-chairs@tools.ietf.org, draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org
Subject: Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (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: Sun, 04 Jan 2015 09:40:06 -0000

Hi Stephen,

I'd like the authors and shepherd to pitch in, but...

> - I'd have thought that these TLVs would be sent more
> often than others, and that (if enormous amounts of
> money are in play) then use of OSPF authentication might
> be more likely needed (or some equivalent security
> mechanisms). I'd even speculate that if enormous amounts
> of money are in play, then confidentiality may become a
> requirement (since if I can observe say A bit settings
> then that might give me insight into traffic levels -
> sort of a lights burning at night in central bank
> implies interest-rate change attack). Can you say why
> none of that needs to be mentioned at all? Was any of
> that considered by the WG? (Can you send a relevant link
> to the archive?)

I think you are raising two points:
1. Are the TLVs sent more often than others and what are the implications?
2. What can be learned from sniffing these TLVs?

To the first point, I don't think they are sent more often than other TE TLVs. Indeed metrics for loss and delay may be more stable than others, and Section 5 addresses measurement intervals and projects that on to announcement thresholds.

So the risk is that changes in bandwidth availability will cause rapid or frequent announcement of those metrics.  However, just like the original bandwidth metrics, implementations apply thresholds so that small changes don't trigger re-announcement in order to avoid stressing the network. Section 6 discusses this.

Thus, I think we can discard 1.

The second point is important: you can find out a lot about a network by sniffing the IGP, and if your plan is to understand the state of your competitor's network or to find the week spots to attack, then this is a powerful tool. But in this matter I would argue that these no TLVs are no more sensitive than other, pre-existing TLVs, although (of course) the more TLVs, the more information is available to be sniffed.

So, the question is how do we protect IGP information as it is advertised within a network. There are four elements:
- IGP information is retained within an administrative domain.
- If a router is compromised it has access to all of the information and there is nothing we can do.
- If a node attempts to join a network to access the information it will be unknown and will not be able to peer.
- If a link is sniffed (which is a somewhat more sophisticated attack) protection relies on encryption of the messages most probably at layer 2, but potentially at IP (which is an option for OSPF) or within the OSPF messages themselves.

I think all of this is just "IGP security as normal", was discussed by KARP, and is everyday business for network operators.

[snip]

> - The security considerations of RFC 3630, from 2003, is
> 11 lines long. Has nothing affected OSPF security in the
> last decade+ that would be worth noting here?

That is a good point. There is plenty of newer security work.

Adrian