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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0F8711A8897; Mon, 5 Jan 2015 06:51:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0pRZ8PxJgMBB; Mon, 5 Jan 2015 06:51:14 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D51571A87BE; Mon, 5 Jan 2015 06:51:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="5.07,700,1413244800"; d="scan'208";a="110400586"
Received: from ([]) by with ESMTP; 05 Jan 2015 14:51:13 +0000
Received: from ( []) by (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 ([]) by ([]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 08:51:12 -0600
From: "Acee Lindem (acee)" <>
To: "" <>, "'Stephen Farrell'" <>, "'The IESG'" <>
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: <>
References: <> <00d301d02802$60ed8990$22c89cb0$>
In-Reply-To: <00d301d02802$60ed8990$22c89cb0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" <> 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).

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