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

["Acee Lindem (acee)" <acee@xxxxxxxxx>]

Hi Dan, 

Great – we’ll address that with your other comments. 

Thanks,

Acee

From: Dan Romascanu <dromasca@xxxxxxxxx>
Date: Monday, October 9, 2017 at 1:58 PM
To: Acee Lindem <acee@xxxxxxxxx>
Cc: "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>, "draft-ietf-ospf-segment-routing-extensions.all@xxxxxxxx" <draft-ietf-ospf-segment-routing-extensions.all@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, OSPF WG List <ospf@xxxxxxxx>
Subject: Re: [OSPF] Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

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) <acee@xxxxxxxxx> 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 <dromasca@xxxxxxxxx>
Date: Saturday, October 7, 2017 at 1:57 AM
To: Acee Lindem <acee@xxxxxxxxx>
Cc: "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>, "draft-ietf-ospf-segment-routing-extensions.all@ietf.org" <draft-ietf-ospf-segment-routing-extensions.all@ietf.org>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, OSPF WG List <ospf@xxxxxxxx>
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) <acee@xxxxxxxxx> wrote:

On 10/5/17, 7:05 AM, "OSPF on behalf of Dan Romascanu"

<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.

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@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/ospf