Last Call Review of draft-ietf-ospf-hybrid-bcast-and-p2mp-
review-ietf-ospf-hybrid-bcast-and-p2mp-secdir-lc-murphy-2012-08-21-00

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.

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.

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.

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