Re: [Lsr] Martin Duke's Discuss on draft-ietf-lsr-ospf-reverse-metric-08: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Martin,

Thanks for your review and comments/feedback. Please check inline below for
responses.

We have also posted an update that includes the changes discussed below:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-09

On Thu, Oct 6, 2022 at 5:56 AM Martin Duke via Datatracker <[e-mail]>
wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-lsr-ospf-reverse-metric-08: Discuss
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I hope this is a quick one.
>
> A naive reading of Sec 2.2 implies that a router could generate
> reverse-metric
> TLVs quite rapidly,


KT> Did you mean send reverse-metric TLV over all its links to its
neighbors OR generate multiple reverse-metric TLVs with changing values OR
a combination of them both?


> triggering a storm of TLVs from a potentially large number
> of neighbors. Each reverse metric advertisement generates N LSAs,


KT> This is not correct. It would end up generating a single update to the
neighbors Router LSA. Perhaps more if we think of multiple parallel links
between those routers. But then there is also dampening built into the
protocol to slow down the rate of (re)generation of the same Router LSA too
frequently.


> increasing
> the amplification of any sort of misconfiguration or misbehavior far more
> than
> a traditional LSAs that is updated too often.
>

KT> As described in my first response above, a combination of varying
reverse metric values being signaled can trigger multiple updates to the
neighbor's Router LSA - which despite dampening may be problematic.


>
> At the very least, this ought to come up in security considerations, but I
> wonder if applying some sort of rate limit (beyond which neighbors are
> free to
> ignore) would be a firmer way of limiting the problem. I'm flexible on the
> best
> way forward.
>

KT> Added text in the security considerations that cover this issue as well
as a proposed mitigation. Please let us know if that works.


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A "don't be stupid" warning in 2.2 certainly wouldn't hurt, either.
>

KT> I am not sure how exactly to put that into the document. Any help is
appreciated. Perhaps something that generically goes into the
Internet-Draft and RFC boilerplate maybe ;-)

Thanks,
Ketan