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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Mon, 02 Dec 2019 07:40:03 -0800

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.

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 2 Dec 2019 09:18:39 -0800

On December 2, 2019 at 10:40:05 AM, Mirja Kühlewind wrote:

Mirja:

Hi!

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

Completely avoiding transit traffic is the goal of the H-bit, which is
the reason/justification of the "MUST NOT".  Hence it being called the
Host-bit.

rfc6987 defines the "best effort" functionality that would be
equivalent to "SHOULD NOT": if no alternate path exits then the path
through the router can still be used.

§8 (in the third bullet) mentions the case where a rogue router can
partition a network by setting the H-Bit...and §5 talks about the
mitigation in mixed environments, where the recommendation (third
bullet) results in the rfc6987 behavior if not all the routers
advertise support.

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

Because the H-bit is an optional feature and not intended to be
supported by all OSPFv2 routers, then the formal Update is not needed.

> specific to the H bit but maybe still worth thinking about it once more...?

Yes.  By using the H-bit the traffic is directed away from the node,
which would force the traffic through another path, including a
specific node.  Similar to the last bullet in §8, this action would be
indistinguishable from the proper use of the H-bit, or from simply
shutting down an interface...

Thanks for the review!

Alvaro.