Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13
Perfect; thanks. Barry On Fri, Oct 5, 2018 at 12:33 AM Naiming Shen (naiming) wrote: > > Hi Barry, > > Thanks for the review and your suggestion makes sense. The original wording > is confusing. Also, as Tony has pointed out in the same thread, this > sentence > was the original intention when start of the draft, but it has been > extended for > other use cases described in section 1. How about this on top of your > suggestions: > >For the use case in section 1.1, Node and Link Isolation, a router MUST > limit >the period during which it advertises a Reverse Metric TLV toward a > neighbor >only to the operational maintenance window period during which it wants > that >neighbor to temporarily update its IS-IS metric or Traffic Engineering > parameters >towards it. > > Best Regards, > - Naiming > > > On Oct 4, 2018, at 10:36 AM, Barry Leiba > wrote: > > > > Reviewer: Barry Leiba > > Review result: Ready > > > > This document is well written and seems ready to go. The only security > issue I > > thought of as I read through it (attacking by spoofing a reverse metric) > is > > covered in the Security Considerations section. > > > > I found one sentence to be slightly ambiguous, but only very slightly. > In > > Section 3.5: > > > > A router MUST advertise a Reverse Metric TLV toward a neighbor only > > for the operational maintenance window period during which it wants a > > neighbor to temporarily update its IS-IS metric or Traffic > > Engineering parameters towards it. > > > > It begins to look like it's saying that a router MUST advertise this > under > > certain conditions, and it took me a moment to get that it's actually > > *limiting* when it should be advertised (the "MUST" applies to the "only" > > clause). If you think my suggested replacement reads well, you might > use it; > > if not, no problem: > > > > A router MUST limit the period during which it advertises a Reverse > Metric > > TLV toward a neighbor only to the operational maintenance window period > > during which it wants that neighbor to temporarily update its IS-IS > metric > > or Traffic Engineering parameters towards it. > > > > -- Barry -- Barry Leiba (barryle...@computer.org) http://internetmessagingtechnology.org/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13
Hi Barry, Thanks for the review and your suggestion makes sense. The original wording is confusing. Also, as Tony has pointed out in the same thread, this sentence was the original intention when start of the draft, but it has been extended for other use cases described in section 1. How about this on top of your suggestions: For the use case in section 1.1, Node and Link Isolation, a router MUST limit the period during which it advertises a Reverse Metric TLV toward a neighbor only to the operational maintenance window period during which it wants that neighbor to temporarily update its IS-IS metric or Traffic Engineering parameters towards it. Best Regards, - Naiming > On Oct 4, 2018, at 10:36 AM, Barry Leiba wrote: > > Reviewer: Barry Leiba > Review result: Ready > > This document is well written and seems ready to go. The only security issue > I > thought of as I read through it (attacking by spoofing a reverse metric) is > covered in the Security Considerations section. > > I found one sentence to be slightly ambiguous, but only very slightly. In > Section 3.5: > > A router MUST advertise a Reverse Metric TLV toward a neighbor only > for the operational maintenance window period during which it wants a > neighbor to temporarily update its IS-IS metric or Traffic > Engineering parameters towards it. > > It begins to look like it's saying that a router MUST advertise this under > certain conditions, and it took me a moment to get that it's actually > *limiting* when it should be advertised (the "MUST" applies to the "only" > clause). If you think my suggested replacement reads well, you might use it; > if not, no problem: > > A router MUST limit the period during which it advertises a Reverse Metric > TLV toward a neighbor only to the operational maintenance window period > during which it wants that neighbor to temporarily update its IS-IS metric > or Traffic Engineering parameters towards it. > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-isis-reverse-metric-13
funny enough, https://tools.ietf.org/html/draft-shen-isis-spine-leaf-ext-06#page-12 by the overlaping author set seems already to circumvent this ;-) On Thu, Oct 4, 2018 at 10:37 AM Barry Leiba wrote: > Reviewer: Barry Leiba > Review result: Ready > > This document is well written and seems ready to go. The only security > issue I > thought of as I read through it (attacking by spoofing a reverse metric) is > covered in the Security Considerations section. > > I found one sentence to be slightly ambiguous, but only very slightly. In > Section 3.5: > >A router MUST advertise a Reverse Metric TLV toward a neighbor only >for the operational maintenance window period during which it wants a >neighbor to temporarily update its IS-IS metric or Traffic >Engineering parameters towards it. > > It begins to look like it's saying that a router MUST advertise this under > certain conditions, and it took me a moment to get that it's actually > *limiting* when it should be advertised (the "MUST" applies to the "only" > clause). If you think my suggested replacement reads well, you might use > it; > if not, no problem: > >A router MUST limit the period during which it advertises a Reverse > Metric >TLV toward a neighbor only to the operational maintenance window period >during which it wants that neighbor to temporarily update its IS-IS > metric >or Traffic Engineering parameters towards it. > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
