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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Sandra,

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


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