Re: [secdir] secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Wed, 19 September 2012 19:42 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124DF21E8034; Wed, 19 Sep 2012 12:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.467
X-Spam-Level:
X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8ikv68iLmFd; Wed, 19 Sep 2012 12:42:47 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E021F8468; Wed, 19 Sep 2012 12:42:47 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKUFogNjBRqthRkUb05X/sAQQt/4d1L7b1@postini.com; Wed, 19 Sep 2012 12:42:47 PDT
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 19 Sep 2012 12:41:08 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 12:41:08 -0700
Received: from co1outboundpool.messaging.microsoft.com (216.32.180.187) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 12:42:36 -0700
Received: from mail33-co1-R.bigfish.com (10.243.78.247) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 19:41:08 +0000
Received: from mail33-co1 (localhost [127.0.0.1]) by mail33-co1-R.bigfish.com (Postfix) with ESMTP id 05315400204; Wed, 19 Sep 2012 19:41:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -30
X-BigFish: PS-30(zz9371I103dK1521I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h)
Received: from mail33-co1 (localhost.localdomain [127.0.0.1]) by mail33-co1 (MessageSwitch) id 1348083665464325_17646; Wed, 19 Sep 2012 19:41:05 +0000 (UTC)
Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.225]) by mail33-co1.bigfish.com (Postfix) with ESMTP id 6E69650004C; Wed, 19 Sep 2012 19:41:05 +0000 (UTC)
Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 19:41:04 +0000
Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.3.218]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 19:41:02 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp
Thread-Index: Ac17uYA1ZqB188w9QjGy7M9E8oHAGAauGo0g
Date: Wed, 19 Sep 2012 19:41:01 +0000
Message-ID: <0BF0FCC78340F147BE76A6F5762318A8022E77@BY2PRD0510MB389.namprd05.prod.outlook.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F6014F@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F6014F@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.232.2]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%SPARTA.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-Mailman-Approved-At: Sat, 22 Sep 2012 11:37:22 -0700
Cc: "draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org" <draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 19:42:48 -0000

Sandra,

Sorry for the late response. I've been pulled into other things.


> -----Original Message-----
> From: Murphy, Sandra [mailto:Sandra.Murphy@sparta.com]
> Sent: Thursday, August 16, 2012 12:11 PM
> To: secdir@ietf.org; iesg@ietf.org
> Cc: draft-ietf-ospf-hybrid-bcast-and-p2mp.all@tools.ietf.org
> Subject: secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> 
> This document provides a new way of communicating connectivity on a
> shared network.  Currently there are two methods, one used for
> broadcast/NBMA nets and one used for point-multipoint networks.  The
> broadcast net case elects a DR that then floods a network LSA noting
> all routers on the net so that LSA database synchronization uses the DR.
> The p2mp case establishes links from each router to each other router
> on the p2mp network.  The broadcast/NBMA case does not permit different
> metrics for the links to each router on the broadcast network.  The
> p2mp case allows different metrics for the links between adjacent
> routers on the p2mp network.
> 
> This draft introduces a hybrid case for broadcast/NBMA networks - using
> the neighbor discovery and LSA database synchronization of the
> broadcast/NBMA case but the establishment of links with different
> metrics of the p2mp case.  The draft specifies changes to LSAs and
> processing that would produce this hybrid behavior.
> 
> The security considerations section says there are no new security
> vulnerabilities that result.  OSPF authenticates all routers on a
> shared network (whether broadcast/NBMA or p2mp) with a single shared
> key, and this mechanism's changes share that authentication.  OSPF does
> not protect against bad behavior by legitimate participants so no
> misbehavior possible with these changes would create new
> vulnerabilities.
> 
> The draft introduces changes to the LSAs and behavior but does not
> explain why the changes are needed or what their intent is.  This makes
> it very hard to understand or analyze what the effect would be.  I was
> able to figure out why the a router LSA type 1 link is introduced to a
> neighbor that is also mentioned by the DR (that's the combination of
> the broadcast discovery feature into the p2mp links part of the hybrid).
> But I was not able to figure out other changes, such as why it was
> necessary to introduce type 3 stub network links for the router's
> subnet.  Perhaps the authors expect that readers will be so intimately
> familiar with OSPF design that the motivation for each change will be
> obvious.  But it does make readers work hard.

Indeed the assumption is that readers are familiar with base OSPF protocol. The LSA behavior is basically to follow p2mp model.

> 
> Section 5 considers cases where some routers on a broadcast network
> follow the hybrid behavior and other follow the broadcast/NBMA behavior.
> OSPF works on the assumption that all routers share the same dataset
> and therefore each will compute shortest paths that will not introduce
> loops.   In this case, not all routers will be working from the same
> dataset of links, raising concern about loops.  Section 5 (briefly)
> says that in this case there would be "no traffic traversing certain
> pairs of routers" but no loops.   I can understand that enough to
> believe it.    But I am not as confident that a router that produces
> both the network LSA and a router LSA with the p2mp links could not
> confuse the situation sufficiently to produce loops.  I wonder if the
> authors have considered that case.  I'm sorry that I was not able to
> devote the time to the shortest path computation to resolve this lack
> of confidence for myself.

We have considered this case and there should be no problem. 

> 
> NOTE: this concern would be a case of mis-behavior by a valid
> participant and OSPF is well understood to be unprotected from such
> mis-behavior.  This is NOT a newly introduced security concern.
> 
> section 4.5 says "the DR MUST NOT generate a network LSA for the
> interface."  OSPF's specs in general do not recommend reporting errors,
> or I would suggest a new error report if a network LSA were spotted on
> an interface that was designated as hybrid.

Indeed. I guess I'm off the hook :-)

I've taken care of the two editorial comments below.

Thanks!
Jeffrey

> 
> --Sandy
> 
> Nits:
> 
> page 3:
> 
>    network.  Further, it mandates establishment of adjacencies to all
>    all configured or discovered neighbors on the network.
> 
> "all all" -> "all"
> 
> page 8
> 
>    o  If a router is in state DROther on the interface, it MUST
> consider
>       an adjacency to non-DR and non-BDR neighbors as reestablished
> when
>       the neighbor state reaches 2-Way.
> 
> I think there is a separate adjacency for each neighbor, not one for
> all neighbors, so I think this should be something like:
> 
>    o  If a router is in state DROther on the interface, it MUST
> consider
>       an adjacency to a non-DR or non-BDR neighbor as reestablished
> when
>       the neighbor state reaches 2-Way.
> 
> 
> 
>