Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22

From: Alvaro Retana <[email-masked]>
Date: Wed, 3 Apr 2019 14:21:54 -0700

On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) ([email-masked])
wrote:

Les:

Hi!

Thanks for the update.

I have a couple of comments on your replies — no showstoppers.  However, it
looks like my original comments were truncated; I added the remaining
comments at the end.

I am starting the IETF LC.  The remaining comments can be addressed with
any other comments that are received during LC.

Thanks!!

Alvaro.

...

> 445 V-Flag: Value flag. If set, then the Adj-SID carries a value.

> 446 By default the flag is SET.
>
> [minor] Is the description the same at the V-Flag in §2.1? If so, then
> indicating that, or at least also pointing out here that the value is
> carried instead of an index would be helpful.
>
[Les:] Done.

I think you missed this one.

...

> 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as
> 545 defined in [ISO10589].
>
> [major] Which System-ID?
>
[Les:] Text has been altered to indicate it is the system-id of the
neighbor.

> [major] "6 octets of...length "ID Length"" ??
>
[Les:] Done.

I was trying to point out that the text is confusing where it says that the
System-ID, which is (from the figure) a 6-octet field, is represented by "6
octets…of length "ID Length”.  Is the length 6 octets or “ID Length”?

ISO10589 says: "System identifier — a variable length field from 1 to 8
octets”…RFC1195 suggests this: "N is a system identifier. In the level 1
algorithm, N is a 6 octet ID for OSI end systems, a 7 octet ID for routers,
or an 8 octet IP Internal Reachability Information entry.”  For both cases,
it the length of the System ID is > 6 octets, which bits are expected to be
in the sub-TLV?  If the system ID is < 6 octets (which I doubt, but just to
cover ISO10589), what next?

Maybe I’m just confused...

Do you want to specify any check to make sure that the System ID in fact
corresponds to a valid neighbor?

...

> 812 The other flags defined in Section 2.1 are not used by the Mapping
> 813 Server and MUST be ignored at reception.
>
> [major] How does the receiver know that the sub-TLV was originated by a
> Mapping Server? Is it the case that it would originate a Binding TLV?
> IOW, would the other flags always be ignored when the sub-TLV is included
> in the Binding TLV (but not other TLVs)? Does this apply also to the
> Multi-Topology SID/Label Binding TLV (§2.5)?
>
[Les:] "Yes" to all of your questions.

Please add some text to clarify.

...

> 1075 3.3. SR Local Block Sub-TLV
>
> 1077 The SR Local Block (SRLB) Sub-TLV contains the range of labels the
> 1078 node has reserved for local SIDs. Local SIDs are used, e.g., for
> 1079 Adjacency-SIDs, and may also be allocated by other components than
> 1080 IS-IS protocol. As an example, an application or a controller may
> 1081 instruct the router to allocate a specific local SID. Therefore, in
> 1082 order for such applications or controllers to know what are the local

> 1083 SIDs available in the router, it is required that the router
> 1084 advertises its SRLB.
>
> [nit] s/than IS-IS protocol/than the IS-IS protocol

[Les:] Done.

>
>
> ...
> 1122 The originating router MUST NOT advertise overlapping ranges.
>
> [major] What should the receiver do if the ranges overlap? I'm assuming
> the same thing as what was specified before...please be specific.
>
[Les:] Similar question is relevant to SRGB and the behavior has been
specified in
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#section-2.3
and this draft references it. I would do the same here, but the SR MPLS
draft does not specify behavior for SRLB - even though the referenced
section is entitled "Segment Routing Global Block and Local Block". Best
solution I would think is to update SR MPKS draft so that a reference to it
could be added here.

Please go ahead and add the reference.  I’ll make sure to address the
issues when that document comes to the IESG (should be soon as it already
finished IETF LC).

...

> 1190 5. IANA Considerations
>
> 1192 This documents request allocation for the following TLVs and subTLVs

Hmmm…. It looks like my comments were truncated (I’ve seen this happen a
couple of times). :-(

Here’s the rest:

1190 5.  IANA Considerations

1192   This documents request allocation for the following TLVs and subTLVs.

[minor] IANA may be ok, but I find the formatting below a little
confusing.  A table may be a better option.

...

1313   This document creates the following sub-TLV Registry:

...

[major] Please indicate what the range is.

…

1317      Registration Procedure: Expert review
[] We’re going to need Designated Experts.  Volunteers?

[major] Are there specific instructions/considerations that the DEs should
be aware of when assigning from this new registry?  If so, please add some
text.

...

1333 6.  Security Considerations

1335   With the use of the extensions defined in this document, IS-IS

1336   carries information which will be used to program the MPLS data plane

1337   [RFC3031].  In general, the same types of attacks that can be carried

1338   out on the IP/IPv6 control plane can be carried out on the MPLS

1339   control plane resulting in traffic being misrouted in the respective

1340   data planes.  However, the latter may be more difficult to detect and

1341   isolate.  Existing security extensions as described in [RFC5304] and

1342   [RFC5310] apply to these segment routing extensions.

[nit] Maybe break up the paragraph into multiple ones with independent
points.

[major] With the last sentence, are you implying that authentication is
required when IS-IS is carrying SR extensions?  If so, please be explicit.
Why would these extensions be different than any other extension?

[minor] The companion OSPF documents added the following paragraph to the
Security Considerations as a result of one of the reviews...perhaps
consider including something similar:

   Implementations MUST assure that malformed TLV and Sub-TLV defined in

   this document are detected and do not provide a vulnerability for

   attackers to crash the OSPFv2 router or routing process.  Reception

   of malformed TLV or Sub-TLV SHOULD be counted and/or logged for

   further analysis.  Logging of malformed TLVs and Sub-TLVs SHOULD be

   rate-limited to prevent a Denial of Service (DoS) attack (distributed

   or otherwise) from overloading the OSPF control plane.

...

1415 9.1.  Normative References

...

[minor] I think that these references can be Informative:

1463   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic

1464              Engineering", RFC 5305, DOI 10.17487/RFC5305, October

1465              2008, <https://www.rfc-editor.org/info/rfc5305>.

1467   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,

1468              DOI 10.17487/RFC5308, October 2008,

1469              <https://www.rfc-editor.org/info/rfc5308>.

...

1527   Les Ginsberg (editor)

1528   Cisco Systems, Inc.

1529   IT

[nit] I didn't know you had moved. ;-)

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 4 Apr 2019 00:15:45 +0000

Alvaro –

Responses inline.

From: Alvaro Retana <[email-masked]>
Sent: Wednesday, April 03, 2019 2:22 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>
Subject: RE: AD Review of draft-ietf-isis-segment-routing-extensions-22

On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) ([email-masked]<mailto:[email-masked]>) wrote:

Les:

Hi!

Thanks for the update.

I have a couple of comments on your replies — no showstoppers.  However, it looks like my original comments were truncated; I added the remaining comments at the end.

I am starting the IETF LC.  The remaining comments can be addressed with any other comments that are received during LC.

[Les:] Understood – thanx.

Thanks!!

Alvaro.

...
[Les:] Done.

[Les:]I am not sure what your concern is. There is already a reference to 2.1.1.1.

And the description states the settings for V/L flags – for which the defaults are different for adj-sid than prefix-sid.

What do you think is still missing?

(I probably should not have indicated “done” on this one.)

> 545 defined in [ISO10589].
[Les:] Text has been altered to indicate it is the system-id of the neighbor.

[Les:] Done.

I was trying to point out that the text is confusing where it says that the System-ID, which is (from the figure) a 6-octet field, is represented by "6 octets…of length "ID Length”.  Is the length 6 octets or “ID Length”?

ISO10589 says: "System identifier — a variable length field from 1 to 8 octets”…RFC1195 suggests this: "N is a system identifier. In the level 1 algorithm, N is a 6 octet ID for OSI end systems, a 7 octet ID for routers, or an 8 octet IP Internal Reachability Information entry.”  For both cases, it the length of the System ID is > 6 octets, which bits are expected to be in the sub-TLV?  If the system ID is < 6 octets (which I doubt, but just to cover ISO10589), what next?

[Les:] ISO 10589 allows a system-id to be from 1-8 octets (and the value “0” is interpreted as “6” for historical reasons). But in practice only the value 6 (and its alias “0”) are used.

The text you quote from RFC 1195 is part of a non-normative Appendix which is illustrating how an implementation might build tables in support of running the Dijkstra algorithm. It isn’t relevant here.

I will update the text to indicate the fields are of “ID Length” (though in practice this will always be “6”).

Do you want to specify any check to make sure that the System ID in fact corresponds to a valid neighbor?

[Les:] No. If the neighbor cannot be found then the SID will never be used.

...

[Les:] The entire section is about the encoding of the Binding TLV and sub-section 2.4 is about Mapping Server support in the Binding TLV. I am not sure what is causing the confusion on your part.

...

[Les:] Done.

> the same thing as what was specified before...please be specific.
[Les:] Similar question is relevant to SRGB and the behavior has been specified in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#section-2.3 and this draft references it. I would do the same here, but the SR MPLS draft does not specify behavior for SRLB - even though the referenced section is entitled "Segment Routing Global Block and Local Block". Best solution I would think is to update SR MPKS draft so that a reference to it could be added here.

Please go ahead and add the reference.  I’ll make sure to address the issues when that document comes to the IESG (should be soon as it already finished IETF LC).

[Les:] OK

...
> 1192 This documents request allocation for the following TLVs and subTLVs

Hmmm…. It looks like my comments were truncated (I’ve seen this happen a couple of times). :-(

Here’s the rest:

[minor] IANA may be ok, but I find the formatting below a little confusing.  A table may be a better option.

[Les:] Agreed – will use tables.

...

...

[Les:] Ack

…

1317        Registration Procedure: Expert review
[] We’re going to need Designated Experts.  Volunteers?
[Les:] Drafts have never addressed asking for DE volunteers – but I think you know where to find them. ☺

[major] Are there specific instructions/considerations that the DEs should be aware of when assigning from this new registry?  If so, please add some text.
[Les:] Ack

...

[nit] Maybe break up the paragraph into multiple ones with independent points.

[Les:] OK

[major] With the last sentence, are you implying that authentication is required when IS-IS is carrying SR extensions?  If so, please be explicit.  Why would these extensions be different than any other extension?

[Les:] No – this is standard text for most IS-IS drafts – referring to the authentication drafts as being applicable.

[minor] The companion OSPF documents added the following paragraph to the Security Considerations as a result of one of the reviews...perhaps consider including something similar:

[Les:] Definitely NOT!! ☺

This is junk which was only added to OSPF because the Security review demanded it. It is base protocol functionality. There is nothing unique to the new TLVs that makes malformed TLVs any more or less dangerous than any other. I promise to resist such a demand if it is made in this case.

...

...

[Les:] As you wish…

...

1528   Cisco Systems, Inc.

1529   IT

[Les:] Stefano promises to rent me a room in his villa (as soon as he buys one).

   Les