Hi Acee, Indeed, that was the intention of my comment.
Thanks and Regards, Dan On Sun, Oct 8, 2017 at 8:15 PM, Acee Lindem (acee) <[email protected]> wrote: > Hi Dan, > > Can you elaborate on how the OSPFv2 segment routing extensions in the > draft make the protocol more susceptible to a DDoS attack? Is this with > respect to logging the occurrence of malformed TLVs or Sub-TLVs? If so, > that can be added. > > Thanks, > Acee > > From: Dan Romascanu <[email protected]> > Date: Saturday, October 7, 2017 at 1:57 AM > To: Acee Lindem <[email protected]> > Cc: "[email protected]" <[email protected]>, "draft-ietf-ospf-segment- > [email protected]" <draft-ietf-ospf-segment- > [email protected]>, "[email protected]" <[email protected]>, OSPF > WG List <[email protected]> > Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-segment- > routing-extensions-19 > > 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) <[email protected]> wrote: > >> >> >> On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu" >> <[email protected] on behalf of [email protected]> 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 >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/ospf >> >> >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
