Subject: Genart last call review of draft-ietf-ospf-segment-routing-extensions-19

From: Dan Romascanu <[email-masked]>
Date: Thu, 05 Oct 2017 04:05:32 -0700

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.

Nits/editorial comments:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 6 Oct 2017 22:54:57 +0000

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

---

From: Dan Romascanu <[email-masked]>
Date: Sat, 7 Oct 2017 08:57:29 +0300

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 8 Oct 2017 17:15:19 +0000

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-masked]<mailto:[email-masked]>>
Date: Saturday, October 7, 2017 at 1:57 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>> wrote:

Thanks,
Acee

>[email-masked]<mailto:[email-masked]>

---

From: Dan Romascanu <[email-masked]>
Date: Mon, 9 Oct 2017 20:58:41 +0300

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-masked]> 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-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "draft-ietf-ospf-segment-
> [email-masked]" <draft-ietf-ospf-segment-
> [email-masked]>, "[email-masked]" <[email-masked]>, OSPF
> WG List <[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 9 Oct 2017 20:04:51 +0000

Hi Dan,
Great – we’ll address that with your other comments.
Thanks,
Acee

Date: Monday, October 9, 2017 at 1:58 PM

Hi Acee,

Thanks and Regards,

Dan

On Sun, Oct 8, 2017 at 8:15 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dan,

Thanks,
Acee

Hi Acee,

Regards,

Dan

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 12 Oct 2017 19:49:21 +0200

Hi Dan,

please see inline:

> values are still 'TBD, suggested value x'. Is there any other document defining

good point, fixed it.

> If yes, do we need a registry? If no, what is this field an octet?

yes, we know about this. The question is where do we want to put this 
registry - draft-ietf-spring-segment-routing defines Prefix-SID 
Algorithms 3.1.1. Both IGP SR drafts defines the same algorithms. This 
looks redundant. We need to keep it either in 
draft-ietf-spring-segment-routing and define a registry there and remove 
the definitions from IGP SR drafts and simply point to them to 
draft-ietf-spring-segment-routing. An alternative is to remove the 
section 3.1.1 from teh draft-ietf-spring-segment-routing and keep the SR 
Algorithm definition in IGP SR drafts and define the registry in one of 
them.

I need to talk to authors of draft-ietf-spring-segment-routing to 
resolve this.

> Octets. Also please clarify if padding is applied or not.

I fixed those cases where the "octets" was missing in the Length 
specification.

For the padding, all OSPF TLVs are always padded to 4-octet alignment. I 
don't believe we need to specify that here again.

> How are conflicts resolved at receiver?

SRLB sub-TLV is not used by routers running ISIS. The advertisement is 
only there for the benefit of external entities such as controllers so 
they can determine what labels are available for assignment. We do not 
define controllers behavior in our drafts.

> full specification, z were included in released production software ....'

I'm not sure, typically such section is removed prior to publication. I 
have no problem keeping it if that is allowed.

> for example - throttling mechanisms to preempt DoS attacks.

added following statement:

"Logging of malformed TLVs and Sub-TLVs should be rate-limited to 
prevent a Denial of Service (DoS) attack (distributed or otherwise) from 
overloading the OSPF control plane. "

thanks,
Peter
> .

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 12 Oct 2017 19:30:18 +0000

In regards to

> SRLB sub-TLV is not used by routers running ISIS. The advertisement is only
> there for the benefit of external entities such as controllers so they can
> determine what labels are available for assignment. We do not define
> controllers behavior in our drafts.
> 
> >
[Les:] SRLB usage is not the same as SRGB usage.

SRLB is a local space for each node to allocate node private labels. There is no notion of conflicting usage e.g. Node A can use 1000 as an adj-sid for one of its links and Node B can use SID 1000 as an adj-sid for one of its links and this is not a conflict. In other words the scope of the SIDs is local to the advertising node.

Further, nodes are NOT required to validate that a private SID (such as an adj-sid) is allocated from the SRLB of the advertising node - it is legal to assign a SID from outside of this space - so - as Peter has indicated - other routers do not make use of SRLB advertisements. IT is there for the convenience of external entities only.

It should be obvious that advertising overlapping ranges makes the advertisement ambiguous. Not sure what else needs to be said.

???

    Les