Re: [Lsr] AD Review of draft-ietf-lsr-ospf-prefix-originator-07

["Ketan Talaulikar (ketant)" <[e-mail]>]

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 <[e-mail]> 
Sent: 09 March 2021 02:57
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: John Scudder <[e-mail]>; [e-mail]; [e-mail]; Christian Hopps <[e-mail]>
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 following work?

<NEW/>
A rogue node that can inject prefix advertisements may use the new extensions introduced in this document to indicate incorrect prefix source information.
</NEW>


...
> 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.
[KT2] Ack 


> 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.
[KT2] Fixed. 


...
> 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 an
> 230 address, implementations MAY support mechanisms to determine a
> 231 reachable address (e.g., advertised with the N-flag set [RFC7684] 
> or
> 232 N-bit set [RFC8362] and either matching the OSPF Router ID or the
> 233 highest IP address) belonging to the originating node to set in 
> the
> 234 Router Address field.
>
> [minor] "then that value is set" Which value?
>
> s/then that value is set/then the same address MUST be used
>
> [KT] I would use SHOULD - please see my previous comment about them 
> being semantically equivalent but not necessary have to be the same 
> (e.g. if an implementation provided a separate knob for it).

Ok.  When is it ok to not use the same address?  Put another way, why would an implementation provide a knob in the first place?
[KT2] We will change this to MUST - this is to be consistent with ISIS and also, there isn't any strong reason that I could think of to do it otherwise.

...
> [major] "MAY support mechanisms to determine a reachable address" I 
> don't understand how this action can be optional.
>
> [KT] An implementation can choose not to advertise this sub-TLV - it 
> is optional and hence we are not mandating. The address just has to be 
> a reachable address of that node.

The specification should be written from the point of view of an implementation of this document.  IOW, if the functionality is implemented would "mechanisms to determine a reachable address" be required?   I think the answer is yes, right?

s/MAY support/MUST support   ("must" is also ok)
[KT2] Ack. Instead of "must", I would propose "can". 



> [minor] "advertised with the N-flag set" Are you suggesting that if 
> the N-flag is set then the Prefix Originator Sub-TLV doesn't need to be present?
> I know it was just an example, but it raises the question of: what if 
> the N-flag is set and the Prefix Originator Sub-TLV is present, and 
> the addresses don't match?
>
> [KT] This is about which address may be picked for advertisement in 
> the Prefix Originator sub-TLV - picking a node address with N-flag set 
> indicates that it is associated with that node and also that it is not anycast.

I think we could live without the example.
[KT2] Have updated the text since this is not an example.

Thanks,
Ketan