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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 05 January 2015 14:51 UTC

Return-Path: <acee@cisco.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 0F8711A8897; Mon, 5 Jan 2015 06:51:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 0pRZ8PxJgMBB; Mon, 5 Jan 2015 06:51:14 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51571A87BE; Mon, 5 Jan 2015 06:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3726; q=dns/txt; s=iport; t=1420469473; x=1421679073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q7/I88JYxKHNo8TFX5bRbqGhAcI270g57hKF1TLXd2g=; b=IpV/Rtau6waRmD/XvlpgHyDdGqaU0t2AzjSl4P3xHHudEv+xPzW8qA4P XKMjmgv+cWGLAuYViNkiZrgK35YIVNTq+1nqofoCuv63tAZSDvdxY9CHQ kCb0Hiz+CiWlAWIzmprW9B4SDCNKzXe1YAkvS09wdNOJjK0/X0Bxj6byn Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcFAGukqlStJA2N/2dsb2JhbABGFoMGgSoEzA8CgQgWAQEBAQF9hA0BAQR5EAIBCCsbMiUCBAENBYgsvGUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjw1qB4QpAQSJIYR0hT6DNYENjQqDOSKCMoE8b4FFfgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,700,1413244800"; d="scan'208";a="110400586"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 05 Jan 2015 14:51:13 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t05EpDbV018961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Jan 2015 14:51:13 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.144]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 08:51:12 -0600
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "'Stephen Farrell'" <stephen.farrell@cs.tcd.ie>, "'The IESG'" <iesg@ietf.org>
Thread-Topic: Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)
Thread-Index: AQHQJ8Mv58Lo2f9RUkKcdPPUSnIEzJywGc2AgAGVhgA=
Date: Mon, 5 Jan 2015 14:51:12 +0000
Message-ID: <D0D008E5.B001%acee@cisco.com>
References: <20150104020718.29256.7059.idtracker@ietfa.amsl.com> <00d301d02802$60ed8990$22c89cb0$@olddog.co.uk>
In-Reply-To: <00d301d02802$60ed8990$22c89cb0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.152.197]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <63A77BD59FF4ED4B95F75EFCD2C7CC74@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/x2KAIP0fWaEYVxLLlJRBp3GF8O8
Cc: "ospf@ietf.org" <ospf@ietf.org>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.org>, "draft-ietf-ospf-te-metric-extensions.all@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
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: Mon, 05 Jan 2015 14:51:16 -0000

Hi Stephen, Adrian,

On 1/4/15, 4:39 AM, "Adrian Farrel" <adrian@olddog.co.uk>; wrote:

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


Agreed. This is covered in sections 5 and 6.

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


I agree. I canĀ¹t see that delay/loss would be more sensitive than
reachability information. I guess the premise is that one might want to
target better for links for DDoS attacks? I do not recall this coming up
in the discussions on either the OSPF or ISIS lists (there is an ISIS
draft advertising the same TLVs).


>
>[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.

This should include RFC 6863 for analysis, RFC 5709 for protection, and
draft-ietf-ospf-security-extension-manual-keying-11 for protection.
John? 

Thanks,
Acee


>
>Adrian
>