Re: [Lsr] [Last-Call] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

["Acee Lindem (acee)" <[e-mail]>]

Hi Alvaro, 

On 11/7/19, 11:58 AM, "Alvaro Retana" <[e-mail]> wrote:

    On November 3, 2019 at 2:28:29 PM, Padma Pillay-Esnault wrote:
    
    Padma:
    
    Hi!
    
    See below...
    
    > On Sat, Nov 2, 2019 at 7:03 PM Benjamin Kaduk wrote:
    > > On Thu, Oct 31, 2019 at 03:50:45PM -0700, Padma Pillay-Esnault wrote:
    > > > On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker
    > > > wrote:
    > > >
    > > > > * I'm curious what happens if a router sets the H-bit when it is on the
    > > > > only feasible transit path.
    > > >
    > > > PPE - The router with the H-bit set will not be "on the only feasible
    > > > transit path" to other destinations. The H-bit functionality will exclude
    > > > the host router from the path calculation in the SPF.
    > >
    > > I think you are talking about normal operation ("will not be on the only
    > > feasible transit path") and Kyle is asking about misconfiguration or
    > > similar edge cases.
    >
    > Thanks for this clarification.
    > >
    > > Having only read this email thread and not the document itself, I assume
    > > that traffic will fail to flow if such a misconfiguration occurred, but it
    > > would be good to confirm/refute that.
    >
    > Yes you are right ... for some cases.
    >
    > Assuming the router with the H-bit clear is on the only transit path. There
    > are several cases see below.
    >
    > Normal case:
    > The router has H-bit set
    > (a) All routers in the area support the H-bit then the router is excluded in
    > the SPF calculations and traffic will not flow.
    > (b) At least one router in the area does not support H-bit then H-bit is not
    > active in area. The traffic will flow as per normal OSPF operation.
    >
    > Misconfiguration case:
    > The router has H-bit erroneously set (misconfig)
    > (a) All routers in the areas support H-bit then the router is excluded in the
    > SPF calculations and traffic will not flow.
    > (b) At least one router in the area does not support H-bit then H-bit is not
    > active in area. The traffic will flow as per normal OSPF operation.
    >
    > The Section 8 of the document has a discussion on this.
    
    Yes, there is a discussion in §8, but I think we left out the case
    where a rogue router, who is on the only transit path, may set the
    H-bit (for no good/valid reason) and effectively partition the
    network.  This case is indistinguishable from the normal case where
    the operator (still on the only transit path) may consciously decide
    to set the H-bit to perform maintenance, for example.
    
    Please add a new bullet to cover this case.

If an OSPFv2 router is a trusted participant in the OSPFv2 routing domain (with or without cryptographic authentication), there are at least 3 or 4 other ways in which it could partition the routing domain. This is just one more. However, I'm not opposed to adding the bullet as this is "what we do" during the security reviews. 

Thanks,
Acee

    
    Thanks!
    
    Alvaro.