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

John E Drake <jdrake@juniper.net> Mon, 05 January 2015 15:00 UTC

Return-Path: <jdrake@juniper.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 372F11A8907; Mon, 5 Jan 2015 07:00:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 S2E1BXYFyR9v; Mon, 5 Jan 2015 07:00:43 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0102.outbound.protection.outlook.com [207.46.100.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57BA1A8910; Mon, 5 Jan 2015 07:00:42 -0800 (PST)
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 15:00:41 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0049.002; Mon, 5 Jan 2015 15:00:41 +0000
From: John E Drake <jdrake@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, "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: AQHQKPcTYkgvr/DSW0yf+pAMCKIr2pyxno6Q
Date: Mon, 5 Jan 2015 15:00:40 +0000
Message-ID: <BLUPR05MB5622DD9BB73D19F1C1268E0C7580@BLUPR05MB562.namprd05.prod.outlook.com>
References: <20150104020718.29256.7059.idtracker@ietfa.amsl.com> <00d301d02802$60ed8990$22c89cb0$@olddog.co.uk> <D0D008E5.B001%acee@cisco.com>
In-Reply-To: <D0D008E5.B001%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jdrake@juniper.net;
x-dmarcaction: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB561;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB561;
x-forefront-prvs: 0447DB1C71
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(43544003)(164054003)(377454003)(479174004)(189002)(199003)(24454002)(51704005)(13464003)(99396003)(120916001)(86362001)(2501002)(97736003)(122556002)(40100003)(92566001)(31966008)(62966003)(77156002)(2656002)(87936001)(76576001)(21056001)(19580395003)(19580405001)(4396001)(74316001)(2900100001)(2950100001)(33656002)(66066001)(102836002)(15975445007)(50986999)(54356999)(76176999)(54606007)(101416001)(64706001)(20776003)(230783001)(99286002)(106116001)(107046002)(46102003)(105586002)(54206007)(106356001)(68736005)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB561; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2015 15:00:40.7019 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB561
Archived-At: http://mailarchive.ietf.org/arch/msg/ospf/sszGwK-y4MIGzEx8Qj28xxoOqR0
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 15:00:46 -0000

Acee,

I will take care of Stephen's nits and add the references you mention to the Security Considerations.

Yours Irrespectively,

John

> -----Original Message-----
> From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem
> (acee)
> Sent: Monday, January 05, 2015 9:51 AM
> To: adrian@olddog.co.uk; 'Stephen Farrell'; 'The IESG'
> 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)
> 
> 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
> >
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf