Re: [secdir] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16

[Yaron Sheffer <[e-mail]>]

Thank you Peter, this addresses my comments.

	Yaron

On 05/11/2018 10:12, Peter Psenak wrote:
> Hi Yaron,
> 
> thanks for your comments, please see inline:
> 
> 
> On 04/11/18 16:38 , Yaron Sheffer wrote:
>> Reviewer: Yaron Sheffer
>> Review result: Has Nits
>>
>> Summary: document has non-security related nits.
>>
>> Details
>>
>> * The definition of "segment" is different here from the one used in the
>> architecture RFC. The RFC is more abstract, quoting: A node steers a 
>> packet
>> through an ordered list of instructions, called "segments". Whereas 
>> here a
>> segment is simply a sub-path. This is confusing to a non-expert, and 
>> perhaps
>> indicates a change in the group's thinking.
> 
> the definition in this draft relates to segment as used by IGPs, in 
> which case a segment represents the sub-path. There are other segments 
> outside of IGPs which can represent other things, but they are not 
> covered by this draft.
> 
> 
>>
>> * SID/Label Sub-TLV: is it Mandatory? If so, please point it out.
> 
> SID/Label Sub-TLV is not advertised on its own. It is advertised as a 
> sub-TLV of the:
> 
> 3.2.  SID/Label Range TLV
> 3.3.  SR Local Block TLV
> 
> Both of these section specify that SID/Label Sub-TLV MUST be included.
> 
>>
>> * "The SR-Algorithm TLV is optional" - I find this sentence confusing. 
>> Maybe
>> replace by "The SR-Algorithm TLV is mandatory for routers that implement
>> segment routing"?
> 
> 
> the text says:
> 
>     "If the SR-Algorithm TLV
>     is not advertised by the node, such node is considered as not being
>     segment routing capable."
> 
> Isn't that sufficient?
> 
> 
>>
>> * The reference under "IGP Algorithm Type" registry should be to the IANA
>> registry itself, not to the I-D that defines it. (In particular since 
>> the IANA
>> registry has already been established,
>> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). 
>>
> 
> I got another comment from Opsdir last call review to include the I-D 
> that defined it. I Added them both, hopefully that satisfy everybody.
> 
>>
>> * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual 
>> incantation about
>> reserved bits.
> 
> Done.
> 
> 
> 
> 
>> * In general I agree with the reasoning in the Security 
>> Considerations. I would
>> like to raise the question if, in addition to mis-routing, this adds a 
>> threat
>> of massive denial-of-service on MPLS endpoints, e.g. by allowing an 
>> attacker
>> who has OSPF access to introduce routing loops. (This may be 
>> completely bogus,
>> I am far from expert with either of these protocols).
> 
> above is addressed by usage of the usage of the OSPF authentication as 
> described in the security section.
> 
> thanks,
> Peter
> 
>>
>> .
>>
>