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