Re: [Lsr] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Hi Yaron, On 06/11/18 07:13 , Yaron Sheffer wrote: Thank you Peter, this addresses my comments. latest version (17) includes your comments. thanks, Peter 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 . . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
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 . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
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 . ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
