Hi Acee,
Thank you for your response and for addressing my comments. I do not disagree that a generic IGP protocol security considerations document may be useful, but I do not believe that this document should be dependent upon it. My observation was related to the last paragraph of the Security Considerations document. It seems to me that non-mandatory counting or logging of malformed TLVs or Sub-TLVs may not be sufficient to protect against a large scale DoS attack. On Sat, Oct 7, 2017 at 1:54 AM, Acee Lindem (acee) <acee@xxxxxxxxx> wrote:
On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"
The generic OSPFv2 security considerations are referenced as well. Can you<ospf-bounces@xxxxxxxx on behalf of dromasca@xxxxxxxxx> wrote:
>Reviewer: Dan Romascanu
>Review result: Ready with Issues
>
>I am the assigned Gen-ART reviewer for this draft. The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed
>by the IESG for the IETF Chair. Please treat these comments just
>like any other last call comments.
>
>For more information, please see the FAQ at
>
><https://trac.ietf.org/trac/gen/wiki/GenArtfaq >.
>
>Document: draft-ietf-ospf-segment-routing-extensions-19
>Reviewer: Dan Romascanu
>Review Date: 2017-10-05
>IETF LC End Date: 2017-10-13
>IESG Telechat date: Not scheduled for a telechat
>
>Summary:
>
>A useful and well-written document. It requires previous reading and
>understanding of OSPF, SPRING and other routing work. It is Ready for
>publication. I found some unclear minor issues. I recommend to address
>them
>before approval and publication.
>
>Major issues:
>
>Minor issues:
>
>1. I am wondering why, at this stage of progress of the document, the type
>values are still 'TBD, suggested value x'. Is there any other document
>defining
>this?
>
>2. Section 3.1 - are there other algorithms planned to be added in the
>future?
>If yes, do we need a registry? If no, what is this field an octet?
>
>3. It would be useful to mention that the Length fields are expressed in
>Octets. Also please clarify if padding is applied or not.
>
>4. Section 3.3:
>
>'The originating router MUST NOT advertise overlapping ranges.'
>
>How are conflicts resolved at receiver?
>
>5. I like Section 9 - Implementation Status - which I found rather
>useful. Is
>there any chance to keep a trimmed down version of it, with synthetic
>information on the lines of 'at the time the document was discussed a
>survey
>was run, it showed that there were x implementation, y were implementing
>the
>full specification, z were included in released production software ....'
>
>6. Section 10 - beyond recommending the counting and logging of the
>mal-formed
>TLVs and sub-TLVs, should not supplementary security recommendations be
>made?
>for example - throttling mechanisms to preempt DoS attacks.
be specific as to why you think there additional considerations specific
to these extensions? Perhaps, we should start work on a generic IGP
protocol security considerations document that is more comprehensive than
what we have done before.
Thanks,
Acee
>
>Nits/editorial comments:
>
>
>_______________________________________________
>OSPF mailing list
>OSPF@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/ospf