Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

[Dan Romascanu <[e-mail]>]

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) <[e-mail]> wrote:

>
>
> On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"
> <[e-mail] on behalf of [e-mail]> 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
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/ospf
>
>