[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ospf-ospfv2-hbit-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Three comments/questions:

1) This sentence in section 3:
"An OSPFv2 router advertising a router-LSA with the H-bit
   set indicates that it MUST NOT be used as a transit router (see
   Section 4) by other OSPFv2 routers in the area supporting the
   functionality."
Isn't the MUST here too restrictive? What if the router is the part of the only
path to a certain host? Or is the assumption that this host is some kind of
endhost/deadend, but then it should never be on the shortest path anyway, or?

Later on you say
"When the H-bit is set, the OSPFv2 router is a Host (non-transit)
   router and is incapable of forwarding transit traffic."
However, there might also be routers that don't understand the H bit and
therefore will route traffic over this host anyway, no?

2) Shouldn't this document update RFC2328, given section 4 and this sentence in
section 2: "If the H-bit is set then the calculation of the shortest-
   path tree for an area, as described in section 16.1 of [RFC2328], is
   modified by including a check to verify that transit vertices DO NOT
   have the H-bit set (see Section 4)."
(And why is DO NOT in upper letters?)

3) Is there an attack that by spoofing the H-bit an attacker could influence
the routing such that traffic is router over a malicious node instead? I guess
there are multiple ways to impact the routing that way and this might not be
specific to the H bit but maybe still worth thinking about it once more...?

Nit:
Section 5: "The RI LSA MUST be area-scoped.  Bit:" -> I guess the "Bit:" should
be removed.