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:24 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 209E31A00F6; Mon, 5 Jan 2015 07:24:15 -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, 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 HCkA6JYi3coV; Mon, 5 Jan 2015 07:24:09 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935961A009E; Mon, 5 Jan 2015 07:24:09 -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:23:46 +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:23:46 +0000
From: John E Drake <jdrake@juniper.net>
To: Acee Lindem <acee.lindem@gmail.com>
Thread-Topic: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-te-metric-extensions-09: (with COMMENT)
Thread-Index: AQHQKPcTYkgvr/DSW0yf+pAMCKIr2pyxno6QgAAFqYCAAAD/gA==
Date: Mon, 05 Jan 2015 15:23:45 +0000
Message-ID: <BLUPR05MB56203B4A4A36B640CB95A33C7580@BLUPR05MB562.namprd05.prod.outlook.com>
References: <20150104020718.29256.7059.idtracker@ietfa.amsl.com> <00d301d02802$60ed8990$22c89cb0$@olddog.co.uk> <D0D008E5.B001%acee@cisco.com> <BLUPR05MB5622DD9BB73D19F1C1268E0C7580@BLUPR05MB562.namprd05.prod.outlook.com> <C562024B-4B40-41D9-9D42-411FAD67587E@gmail.com>
In-Reply-To: <C562024B-4B40-41D9-9D42-411FAD67587E@gmail.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)(479174004)(377454003)(24454002)(51704005)(13464003)(189002)(199003)(43544003)(164054003)(20776003)(64706001)(101416001)(102836002)(15975445007)(54606007)(76176999)(50986999)(54356999)(110136001)(68736005)(77096005)(106116001)(107046002)(230783001)(99286002)(54206007)(105586002)(106356001)(46102003)(40100003)(122556002)(31966008)(93886004)(77156002)(62966003)(92566001)(97736003)(99396003)(86362001)(120916001)(4396001)(33656002)(66066001)(2950100001)(2900100001)(74316001)(2656002)(87936001)(21056001)(19580395003)(19580405001)(76576001); 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:23:45.9889 (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/sd18A0K2w6kCQXcyy4EBn-iwJ64
Cc: "draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org" <draft-ietf-ospf-te-metric-extensions.all@tools.ietf.org>, "ospf-chairs@tools.ietf.org" <ospf-chairs@tools.ietf.org>, OSPF List <ospf@ietf.org>, The IESG <iesg@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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:24:15 -0000
Sigh Yours Irrespectively, John > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@gmail.com] > Sent: Monday, January 05, 2015 10:20 AM > To: John E Drake > Cc: Acee Lindem (acee); adrian@olddog.co.uk; Stephen Farrell; The IESG; > OSPF List; 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 John, > I realized now I have one more comment that is better late than never. Can > you add a reference to RFC 5329 in the abstract, section 3, section 10, and > section 11? There is no reason why these metric extensions shouldn't apply > equally to the OSPFv3 TE. > Thanks, > Acee > On Jan 5, 2015, at 10:00 AM, John E Drake <jdrake@juniper.net> wrote: > > > 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 > > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf
- [OSPF] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… Adrian Farrel
- Re: [OSPF] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… John E Drake
- Re: [OSPF] Stephen Farrell's No Objection on draf… Acee Lindem (acee)
- Re: [OSPF] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [OSPF] Stephen Farrell's No Objection on draf… John E Drake