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

[Alvaro Retana <[e-mail]>]

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 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?



...
> [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)



> [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.