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

"Jeffrey (Zhaohui) Zhang" <> Wed, 19 September 2012 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 124DF21E8034; Wed, 19 Sep 2012 12:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.467
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E8ikv68iLmFd; Wed, 19 Sep 2012 12:42:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0A8E021F8468; Wed, 19 Sep 2012 12:42:47 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUFogNjBRqthRkUb05X/sAQQt/; Wed, 19 Sep 2012 12:42:47 PDT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 19 Sep 2012 12:41:08 -0700
Received: from ( by ( with Microsoft SMTP Server id 14.1.355.2; Wed, 19 Sep 2012 12:41:08 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Sep 2012 12:42:36 -0700
Received: from ( by ( with Microsoft SMTP Server id; Wed, 19 Sep 2012 19:41:08 +0000
Received: from mail33-co1 (localhost []) by (Postfix) with ESMTP id 05315400204; Wed, 19 Sep 2012 19:41:08 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); (null);; R:internal; EFV:INT
X-SpamScore: -30
X-BigFish: PS-30(zz9371I103dK1521I542M1432Id6f1izz1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh1155h)
Received: from mail33-co1 (localhost.localdomain []) by mail33-co1 (MessageSwitch) id 1348083665464325_17646; Wed, 19 Sep 2012 19:41:05 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 6E69650004C; Wed, 19 Sep 2012 19:41:05 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 19 Sep 2012 19:41:04 +0000
Received: from ([]) by ([]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 19:41:02 +0000
From: "Jeffrey (Zhaohui) Zhang" <>
To: "Murphy, Sandra" <>, "" <>, "" <>
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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 22 Sep 2012 11:37:22 -0700
Cc: "" <>
Subject: Re: [secdir] secdir review of draft-ietf-ospf-hybrid-bcast-and-p2mp
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Sep 2012 19:42:48 -0000


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

> -----Original Message-----
> From: Murphy, Sandra []
> Sent: Thursday, August 16, 2012 12:11 PM
> To:;
> Cc:
> 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.


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