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.
Regards, Dan On Sat, Oct 7, 2017 at 1:54 AM, Acee Lindem (acee) <a...@cisco.com> wrote: > > > On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu" > <ospf-boun...@ietf.org on behalf of droma...@gmail.com> 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. > > The generic OSPFv2 security considerations are referenced as well. Can you > 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@ietf.org > >https://www.ietf.org/mailman/listinfo/ospf > >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
