Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
Hi Alvaro, Thanks for that confirmation and the updated draft version has been posted with the changes. https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-prefix-originator-09 Thanks, Ketan -Original Message- From: Alvaro Retana Sent: 16 March 2021 23:23 To: Ketan Talaulikar (ketant) ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; Christian Hopps Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07 Ketan: Hi! I’m ok with your responses — I think we’re good to go. Thanks! Alvaro. On March 9, 2021 at 12:42:21 PM, Ketan Talaulikar wrote: > I will wait for your responses on a few of the points before posting > the draft update. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
Ketan: Hi! I’m ok with your responses — I think we’re good to go. Thanks! Alvaro. On March 9, 2021 at 12:42:21 PM, Ketan Talaulikar wrote: > I will wait for your responses on a few of the points before > posting the draft update. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
Hi Alvaro, Please check inline below with [KT2] I will wait for your responses on a few of the points before posting the draft update. -Original Message- From: Alvaro Retana Sent: 09 March 2021 02:57 To: Ketan Talaulikar (ketant) ; draft-ietf-lsr-ospf-prefix-origina...@ietf.org Cc: John Scudder ; lsr-cha...@ietf.org; lsr@ietf.org; Christian Hopps Subject: RE: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07 On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote: Ketan: Hi! I have a couple of comments below, which I think can be handled with other last-call comments. I'm starting the IETF LC. Thanks!! Alvaro. ... > 127 2. Protocol Extensions > > 129 This document defines the Prefix Source Router-ID and the Prefix > 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable > 131 address information for the router originating the prefix as a > prefix > 132 attribute. > > [major] I understand that the 2 sub-TLVs are optional and complement > each other. Is there an expectation for both to be present? Should > (SHOULD/MUST) both be present? What if they're not? > > [KT] There is no dependency between the two and hence either one or > both of them may be advertised. Why do we need both then? Can the users of this information figure stuff out with only one? After all you added the Prefix Originator Sub-TLV for a reason. ;-) [KT2] One sub-TLV signals the OSPF Router-ID of the originating node in the OSPF domain, the other sub-TLV signals a reachable address of the originating node (may be within or even outside the OSPF domain for external prefixes). The draft explains this in the introduction and the procedures. I think perhaps it helps if we rename as s/Prefix Source Router-ID Sub-TLV/Prefix Source OSPF Router-ID Sub-TLV s/Prefix Originator Sub-TLV/Prefix Source Router Address Sub-TLV ... > 134 2.1. Prefix Source Router-ID Sub-TLV ... > 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that > 162 originated the prefix advertisement in the OSPF domain. > > [major] Should there be a relationship between the router ID and the > Advertising Router field in the LSA containing the prefix? What does > it mean if the router ID doesn't match? > > [KT] The value MUST match for intra-area. So we can clarify this part > and if it does not match then the sub-TLV can be ignored. For external (e.g. > Type 5), we cannot determine because we don't know if it was not > translated from Type 7 to Type 5 by an NSSA ABR. Same way we cannot > figure this out reliably for inter-area prefix advertisements. Not > sure if there is anything we can say other than intra-area. Right. OLD> For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV MUST be considered invalid and ignored if it is not the same as Advertising Router ID for the prefix advertisement. NEW> For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. [KT2] Ack For inter-area, maybe it's worth mentioning the fact that it cannot be verified, so a rogue ABR (see more on rogue below) can inject incorrect information. [KT2] Ack. Will add - " Similar validation cannot be reliably performed for inter-area and external prefix advertisements." At the end of the above paragraph. > [major] Even though this document doesn't specify any > OSPF-in-the-network action based on the new information, it does say > that the information is useful for "topology analysis and traffic > engineering", which means that the values may have an impact on route > calculation (at a controller). I'm asking the questions about matching > values because (if they don't) then it would be relatively easy for a > rogue node to introduce non-congruent values which could have an effect on > the controller's decision. > > [KT] We need to remember that we are talking about a prefix > advertisement - a rogue would need to make a prefix advertisement > first (which is considered for OSPF routing) and only then comes the > part when this sub-TLV value is mismatched. Isn't the first part a bigger > issue? Yes. But a rogue node can already do that!! This draft adds the second part. Note that by rogue I mean a router that has been subverted; e.g. someone got the password and now has the ability to inject anything into the network. In this case authentication does not help because the router has the proper keys. Note that I'm not asking you to fix the problem -- just to mention the new risk. [KT2] I am assuming you are asking for this to be mentioned in the Securities Considerations section. I am not sure what would be a helpful text here. Does the followin
Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
On March 8, 2021 at 12:35:52 PM, Ketan Talaulikar (ketant) wrote: Ketan: Hi! I have a couple of comments below, which I think can be handled with other last-call comments. I'm starting the IETF LC. Thanks!! Alvaro. ... > 127 2. Protocol Extensions > > 129 This document defines the Prefix Source Router-ID and the Prefix > 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable > 131 address information for the router originating the prefix as a prefix > 132 attribute. > > [major] I understand that the 2 sub-TLVs are optional and complement each > other. Is there an expectation for both to be present? Should (SHOULD/MUST) > both be present? What if they're not? > > [KT] There is no dependency between the two and hence either one or both of > them may be advertised. Why do we need both then? Can the users of this information figure stuff out with only one? After all you added the Prefix Originator Sub-TLV for a reason. ;-) ... > 134 2.1. Prefix Source Router-ID Sub-TLV > ... > 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that > 162 originated the prefix advertisement in the OSPF domain. > > [major] Should there be a relationship between the router ID and the > Advertising Router field in the LSA containing the prefix? What does it mean > if the router ID doesn't match? > > [KT] The value MUST match for intra-area. So we can clarify this part and if > it does not match then the sub-TLV can be ignored. For external (e.g. > Type 5), we cannot determine because we don't know if it was not translated > from Type 7 to Type 5 by an NSSA ABR. Same way we cannot figure this out > reliably for inter-area prefix advertisements. Not sure if there is anything > we can say other than intra-area. Right. OLD> For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV MUST be considered invalid and ignored if it is not the same as Advertising Router ID for the prefix advertisement. NEW> For intra-area prefix advertisements, the Prefix Source Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. For inter-area, maybe it's worth mentioning the fact that it cannot be verified, so a rogue ABR (see more on rogue below) can inject incorrect information. > [major] Even though this document doesn't specify any OSPF-in-the-network > action based on the new information, it does say that the information is > useful for "topology analysis and traffic engineering", which means that the > values may have an impact on route calculation (at a controller). I'm asking > the questions about matching values because (if they don't) then it would be > relatively easy for a rogue node to introduce non-congruent values which > could have an effect on the controller's decision. > > [KT] We need to remember that we are talking about a prefix advertisement - > a rogue would need to make a prefix advertisement first (which is considered > for OSPF routing) and only then comes the part when this sub-TLV value is > mismatched. Isn't the first part a bigger issue? Yes. But a rogue node can already do that!! This draft adds the second part. Note that by rogue I mean a router that has been subverted; e.g. someone got the password and now has the ability to inject anything into the network. In this case authentication does not help because the router has the proper keys. Note that I'm not asking you to fix the problem -- just to mention the new risk. ... > 172 2.2. Prefix Originator Sub-TLV > ... > 198 o Router Address: A reachable IPv4 or IPv6 router address for the > 199 router that originated the IPv4 or IPv6 prefix advertisement. > 200 Such an address would be semantically equivalent to what may be > 201 advertised in the OSPFv2 Router Address TLV [RFC3630] or in the > 202 OSPFv3 Router IPv6 Address TLV [RFC5329]. > > [minor] "semantically equivalent" The text in §3 says that the addresses are > the same -- what is "semantically equivalent", and is that different from > "the same"? > > [KT] There are implementation which allow different loopback (i.e. node) > addresses being specified/used for the TE Router-ID. So semantically > indicates have similar properties (e.g. cannot be anycast) but does not have > to be the same address technically. Ok. Please explain that in the text. > 204 A prefix advertisement MAY include more than one Prefix Originator > 205 sub-TLV, one corresponding to each of the Equal-Cost Multi-Path > 206 (ECMP) nodes that originated the given prefix. > > [] Same questions as above. You changed the text in the previous section, but not the one here. ... > 226 If the originating node is advertising an OSPFv2 Router Address TLV > 227 [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then that > 228 value is set in the Router Address field of the Prefix Originator > 229 Sub-TLV. When the originating node is not advertising such
Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
Hi Alvaro, Thanks for your detail review and comments. We've update the draft to address your comments and the version 8 posted below. https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-originator-08.txt Please check inline below for responses. Thanks, Ketan -邮件原件- 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Alvaro Retana 发送时间: 2021年2月13日 20:36 收件人: draft-ietf-lsr-ospf-prefix-origina...@ietf.org 抄送: lsr-cha...@ietf.org; John Scudder; Christian Hopps; lsr@ietf.org 主题: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07 Dear authors: Thank you for working on this document. I have some comments (below) that I would like to see addressed before starting the IETF Last Call. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction ... 77 The identification of the originating router for a prefix in OSPF 78 varies by the type of the prefix and is currently not always 79 possible. For intra-area prefixes, the originating router is 80 identified by the advertising Router ID field of the area-scoped LSA 81 used for those prefix advertisements. However, for the inter-area 82 prefixes advertised by the Area Border Router (ABR), the advertising 83 Router ID field of their area-scoped LSAs is set to the ABR itself 84 and the information about the router originating the prefix 85 advertisement is lost in this process of prefix propagation across 86 areas. For Autonomous System (AS) external prefixes, the originating 87 router may be considered as the Autonomous System Border Router 88 (ASBR) and is identified by the advertising Router ID field of the 89 AS-scoped LSA used. However, the actual originating router for the 90 prefix may be a remote router outside the OSPF domain. Similarly, 91 when an ABR performs translation of Not-So-Stubby Area (NSSA) 92 [RFC3101] LSAs to AS-external LSAs, the information associated with 93 the NSSA ASBR (or the router outside the OSPF domain) is not conveyed 94 across the OSPF domain. [minor] s/advertising Router ID field/Advertising Router field/g [KT] Ack ... 102The primary use case for the extensions proposed in this document is 103to be able to identify the originator of the prefix in the network. 104In cases where multiple prefixes are advertised by a given router, it 105is also useful to be able to associate all these prefixes with a 106single router even when prefixes are advertised outside of the area 107in which they originated. It also helps to determine when the same 108prefix is being originated by multiple routers across areas. [nit] s/of the prefix/of a prefix [KT] Ack 110This document proposes extensions to the OSPF protocol for inclusion 111of information associated with the router originating the prefix 112along with the prefix advertisement. These extensions do not change 113the core OSPF route computation functionality. They provide useful 114information for topology analysis and traffic engineering, especially 115on a controller when this information is advertised as an attribute 116of the prefixes via mechanisms such as Border Gateway Protocol Link- 117State (BGP-LS) [RFC7752]. [minor] "advertised...via...BGP-LS" Please add an Informative reference to draft-ietf-idr-bgp-ls-segment-routing-ext. [KT] Ack [FYI] The second sub-tLV is not included in the BGP-LS extension draft -- I will send a note to the authors. [KT] I am also co-author on that draft and will respond on that one. ... 127 2. Protocol Extensions 129This document defines the Prefix Source Router-ID and the Prefix 130Originator Sub-TLVs for inclusion of the Router ID and a reachable 131address information for the router originating the prefix as a prefix 132attribute. [major] I understand that the 2 sub-TLVs are optional and complement each other. Is there an expectation for both to be present? Should (SHOULD/MUST) both be present? What if they're not? [KT] There is no dependency between the two and hence either one or both of them may be advertised. ... 134 2.1. Prefix Source Router-ID Sub-TLV ... 161o OSPF Router ID : the OSPF Router ID of the OSPF router that 162 originated the prefix advertisement in the OSPF domain. [major] Should there be a relationship between the router ID and the Advertising Router field in the LSA containing the prefix? What does it mean if the router ID doesn't match? [KT] The value MUST match for intra-area. So we can clarify this part and if it does not match then the sub-TLV can be ignored. For external (e.g. Type 5), we cannot determine because we don't know if it was not translated from Type 7 to Type 5 by an NSSA ABR. Same way we can
[Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07
Dear authors: Thank you for working on this document. I have some comments (below) that I would like to see addressed before starting the IETF Last Call. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction ... 77 The identification of the originating router for a prefix in OSPF 78 varies by the type of the prefix and is currently not always 79 possible. For intra-area prefixes, the originating router is 80 identified by the advertising Router ID field of the area-scoped LSA 81 used for those prefix advertisements. However, for the inter-area 82 prefixes advertised by the Area Border Router (ABR), the advertising 83 Router ID field of their area-scoped LSAs is set to the ABR itself 84 and the information about the router originating the prefix 85 advertisement is lost in this process of prefix propagation across 86 areas. For Autonomous System (AS) external prefixes, the originating 87 router may be considered as the Autonomous System Border Router 88 (ASBR) and is identified by the advertising Router ID field of the 89 AS-scoped LSA used. However, the actual originating router for the 90 prefix may be a remote router outside the OSPF domain. Similarly, 91 when an ABR performs translation of Not-So-Stubby Area (NSSA) 92 [RFC3101] LSAs to AS-external LSAs, the information associated with 93 the NSSA ASBR (or the router outside the OSPF domain) is not conveyed 94 across the OSPF domain. [minor] s/advertising Router ID field/Advertising Router field/g ... 102 The primary use case for the extensions proposed in this document is 103 to be able to identify the originator of the prefix in the network. 104 In cases where multiple prefixes are advertised by a given router, it 105 is also useful to be able to associate all these prefixes with a 106 single router even when prefixes are advertised outside of the area 107 in which they originated. It also helps to determine when the same 108 prefix is being originated by multiple routers across areas. [nit] s/of the prefix/of a prefix 110 This document proposes extensions to the OSPF protocol for inclusion 111 of information associated with the router originating the prefix 112 along with the prefix advertisement. These extensions do not change 113 the core OSPF route computation functionality. They provide useful 114 information for topology analysis and traffic engineering, especially 115 on a controller when this information is advertised as an attribute 116 of the prefixes via mechanisms such as Border Gateway Protocol Link- 117 State (BGP-LS) [RFC7752]. [minor] "advertised...via...BGP-LS" Please add an Informative reference to draft-ietf-idr-bgp-ls-segment-routing-ext. [FYI] The second sub-tLV is not included in the BGP-LS extension draft -- I will send a note to the authors. ... 127 2. Protocol Extensions 129 This document defines the Prefix Source Router-ID and the Prefix 130 Originator Sub-TLVs for inclusion of the Router ID and a reachable 131 address information for the router originating the prefix as a prefix 132 attribute. [major] I understand that the 2 sub-TLVs are optional and complement each other. Is there an expectation for both to be present? Should (SHOULD/MUST) both be present? What if they're not? ... 134 2.1. Prefix Source Router-ID Sub-TLV ... 161 o OSPF Router ID : the OSPF Router ID of the OSPF router that 162 originated the prefix advertisement in the OSPF domain. [major] Should there be a relationship between the router ID and the Advertising Router field in the LSA containing the prefix? What does it mean if the router ID doesn't match? [major] Even though this document doesn't specify any OSPF-in-the-network action based on the new information, it does say that the information is useful for "topology analysis and traffic engineering", which means that the values may have an impact on route calculation (at a controller). I'm asking the questions about matching values because (if they don't) then it would be relatively easy for a rogue node to introduce non-congruent values which could have an effect on the controller's decision. 164 A prefix advertisement MAY include more than one Prefix Source 165 Router-ID sub-TLV, one corresponding to each of the Equal-Cost Multi- 166 Path (ECMP) nodes that originated the given prefix. [major] "prefix advertisement...more than one Prefix Source Router-ID sub-TLV" I guess you mean that the TLV (not just the advertisement) can include more than one of these sub0-TLVs, right? Please be specific. [minor] "...one corresponding to each of the Equal-Cost Multi-Path (ECMP) nodes that originated the given prefix." Is that the
