Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-extension-05

[Alvaro Retana <[e-mail]>]

Ping!

Just wondering where we are with this document.

Alvaro.

On November 20, 2018 at 3:50:17 PM, Alvaro Retana ([e-mail])
wrote:

Dear authors:

I just finished reading this document.  Please see my comments below.

The actions of the router may result in (unintended) unreachable
destinations. But there is no way (that I know of through DLEP) for the
router to know the result of any of its actions beforehand.  It is
important for this information to be clear in the document (either in a
dedicated Deployment Considerations sections or somewhere prominent in the
text).  Whether and how a router uses the Hop Count information or not
(already mentioned in §3.1), and whether and how it reacts to any
unreachable destinations as a result of its actions are out of scope of
this document...this fact should also be prominently mentioned.

Along similar lines, I think that the Security Considerations section
should also include (at least) a mention of the risks.

I'll wait for these points to be addressed before starting the IETF Last
Call.

Thanks!

Alvaro.


[Line numbers come from idnits.]

...
72 1.  Introduction
...
80   Some modem technologies support connectivity to destinations via
81   multi-hop forwarding.  DLEP Destination messages can be used to
82   report such connectivity, see [RFC8175], but do not provide any
83   information related to the number or capacity of the hops.  The
84   extension defined in this document enables modems to inform routers
85   when multi-hop forwarding is being used, and routers to request that
86   modems change multi-hop forwarding behavior.  The extension defined
87   in this document is referred to as "Multi-Hop Forwarding".

[major] Please define "multi-hop forwarding" in the context of the modems.

[minor] "Some modem technologies support connectivity to destinations via
multi-hop forwarding.  DLEP Destination messages can be used to report such
connectivity, see [RFC8175]..."  Where does rfc8175 talk about that?


...
101 2.  Extension Usage and Identification

103   The use of the Multi-Hop Forwarding Extension SHOULD be configurable.

[major] Is there a default recommended setting?


...
111 3.  Extension Data Items

113   Three data items are defined by this extension.  The Hop Count Data
114   Item is used by a modem to provide the number of network hops
115   traversed to reach a particular destination.  The Hop Control Data
116   Item is used by a router to request that a modem alter connectivity
117   to a particular destination.  The Suppress Forwarding Data Item is
118   used by a router to request that a modem disable multi-hop forwarding
119   on either a device or destination basis.

121 3.1.  Hop Count

123   The Hop Count Data Item is used by a modem to indicate the number of
124   physical hops between the modem and a specific destination.  In other
125   words, each hop represents a transmission and the number of hops is
126   equal to the number of transmissions required to go from a router
127   connected modem to the destination's connected modem.  The minimum
128   number of hops is 1, which represents transmission to destinations
129   that are directly reachable via the router's locally connected modem.

[minor] This section describes the hop count in terms of physical hops, but
§3 talks about "network hops".  Are these the same thing? Please clarify.

131   The data item also contains an indication of when a destination which
132   currently has a hop count of greater than one (1) could be made
133   direcly reachable by a modem, e.g., by re-aiming an antenna.

[nit] s/direcly/directly

...
140   A router receiving a Hop Count Data Item MAY use this information in
141   its forwarding and routing decisions, and specific use is out of
142   scope of this document.  The absence of the Hop Count Data Item MUST
143   be interpreted by the router as a Hop Count value of one (1).

[major] s/MAY/may  The rest of the sentence says that the use is out of
scope, so there's nothing normative here.

145   The format of the Hop Count Data Item is:

147        0                   1                   2                   3
148        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
149       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150       | Data Item Type                | Length                        |
151       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152       |P|  Reserved   |   Hop Count   |
153       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

155   Data Item Type:  TBA2

157   Length:  4

159   P:

161      The P-bit indicates that a destination is potentially directly
162      reachable.  When the P-bit is set, the router MAY request a direct
163      link to the associated destination using the Hop Control Data Item
164      described below.

[major] Should it only be set if the Hop Count is > 1?  I interpret the
definition ("potentially directly reachable") as saying that this bit
should not be set if Hop Count = 1, but I think it could be interpreted in
a different way.  Please clarify.

166   Reserved:

168      MUST be set to zero by the sender (a modem) and ignored by the
169      receiver (a router).

[major] I think that a registry for these bits is needed.  Otherwise anyone
can use them...

171   Hop Count:

173      An unsigned 8-bit integer indicating the number of network hops
174      required (i.e., number of times a packet will be transmitted) to
175      reach the destination indicated in the message.  The special value
176      of 255 (0xFF) is used to indicate that the number of hops is an
177      unknown number greater than one (1).  This field MUST contain a
178      value of at least one (1) if the associated destination is
179      reachable.

181      A value of zero (0) is used to indicated that processing of a Hop
182      Control action, see Section 3.2, has resulted in a destination no
183      longer being reachable.  A zero value MUST NOT be used in any
184      message other then a Link Characteristics Response Message.

[nit] s/indicated/indicate

[minor] s/has resulted in a destination no longer being reachable/has
resulted in the destination no longer being reachable  According to §3.2
the Hop Control message is about "a particular destination", so the result
can only be about it (the destination), and not about any destination ("a
destination").  Yes, this is really a nit...but it took me while to go
check rfc8175 to get that detail right.

186 3.2.  Hop Control
...
200   A modem that receives the Hop Control Data Item in a Link
201   Characteristics Request Message SHOULD attempt to make the change
202   indicated by the data item for the associated destination MAC
203   address.  Once the change is made, fails or is rejected, the modem
204   MUST respond with a Link Characteristics Response Message containing
205   an updated Hop Count Data Item.  Note that other destinations can be
206   impacted as a result of the change and such changes are reported in
207   Destination Down and Destination Update Messages.  The modem MUST
208   notify the router of each destination that is not identified in the
209   Link Characteristics Response Message and is no longer reachable via
210   a Destination Down Message.  The modem MUST also notify the router of
211   each destination that is not identified in the Link Characteristics
212   Response Message and has a changed Hop Count impacted via a
213   Destination Update Message.

[major] s/SHOULD attempt to make the change/SHOULD make the change  The
Normative action is to make the change, not to try to make it.  There are 2
more instances of the same phrase in the text.

215   A modem that receives the Hop Control Data Item in a Session Update
216   Message SHOULD attempt to make the change indicated by the data item
217   for all known destinations.  Once the change is made, or fails or is
218   rejected, the modem MUST respond with a Session Update Response
219   Message with an appropriate Status Code.  Destination specific impact
220   resulting from the processing of a Hop Control Data Item in a Session
221   Update Message is provided via Destination Down and Destination
222   Update Messages.  The modem MUST notify the router of each
223   destination that is no longer reachable via a Destination Down
224   Message.  The modem MUST notify the router of any changes in Hop
225   Counts via Destination Update Messages.

[minor] "Once the change is made, or fails or is rejected..."  Why could
the change fail?  Why would it be rejected?  I understand that the change
may fail if, for example, the destination is not directly reachable anymore
(and a Direct Connection was requested)...and I guess that there may be
"external" policy applied to the modem that could cause a
failure/rejection.  It might be worth clarifying that (specially the
rejection case) somewhere.

227   The format of the Hop Control Data Item is:

229        0                   1                   2                   3
230        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
231       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
232       | Data Item Type                | Length                        |
233       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
234       |       Hop Control Actions     |
235       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

237   Data Item Type:  TBA3

239   Length:  4

[major] The Length should be 2.

241   Hop Control Actions:

243      An unsigned 16-bit value with the following meaning:

245                      +-------+---------------------+
246                      | Value | Action              |
247                      +-------+---------------------+
248                      | 0     | Reset               |
249                      |       |                     |
250                      | 1     | Terminate           |
251                      |       |                     |
252                      | 2     | Direct Connection   |
253                      |       |                     |
254                      | 3     | Suppress Forwarding |
255                      +-------+---------------------+

257                    Table 1: Hop Control Actions Values

259 3.2.1.  Reset

261   The Reset Action requests that the default behavior be restored.
262   When received in a Session Update Message message, a modem SHOULD
263   clear all control actions that have previously been processed on a
264   device wide basis, and revert to its configured behavior.  When
265   received in a Link Characteristics Request Message, a modem SHOULD
266   clear all control actions that have previously been processed for the
267   destination indicated in the message.

[major] When would a modem not clear all control actions?  IOW, why use
SHOULD and not MUST?  I'm assuming that it may not be possible (simply
because of the nature of a manet), but I'm asking in case there are other
reasons.

269 3.2.2.  Terminate

271   The Terminate Action is only valid on a per destination basis and
272   MUST NOT be sent in a Session Update Message message.  It indicates
273   that a direct connection is no longer needed with the destination
274   identified in the message.  This request has no impact for multi-hop
275   destinations and may fail even in a single hop case, i.e. MAY result
276   in the Hop Count to the destination not being impacted by the
277   processing of the request.

[major] s/MAY/may  That is a non-Normative statement.

[minor] What is the difference between Reset and Terminate (for a
particular destination)?

279 3.2.3.  Direct Connection

281   The Direct Connection is only valid on a per destination basis and
282   MUST NOT be sent in a Session Update Message message.  It indicates
283   that the modem SHOULD attempt to establish a direct connection with
284   the destination identified in the message.  This action SHOULD only
285   be sent for destinations for which the Hop Count is greater than 1
286   and has the P-Bit set in the previously received Hop Count Data Item.
287   Results of the request for the destination identified in the message
288   are provided as described above.  If any other destination is
289   impacted in the processing of this action, the modem MUST send a
290   Destination Update Message for each impacted destination.

[minor] ...or send a Destination Down...   If pointing at the text above, I
think that the last sentence (and any other details) are not needed and
redundant.

292 3.2.4.  Suppress Forwarding
...
308   A modem which receives the Suppress Forwarding Data Item in a Link
309   Characteristics Request Message MUST suppress multi-hop forwarding
310   for only the destination indicated in the message.  This means that
311   data traffic originating from the modem's peer router SHALL be sent
312   by the modem to the destination indicated in the Link Characteristics
313   Request Message only when it is one modem hop away.  Notably, data
314   traffic received by the modem from another modem MAY be forwarded by
315   the modem per its normal processing.  Results are provided as
316   described above.

[major] s/MAY/may  There's nothing about the change that would make
forwarding optional.

318 4.  Security Considerations

320   The extension enables the reporting and control of forwarding
321   information by DLEP capable modems.  The extension does not
322   inherently introduce any additional threats above those documented in

324   [RFC8175].  The approach taken to Security in that document applies
325   equally when running the extension defined in this document.

[major] The use of this extension can result in unreachable destinations --
maybe an unintended consequence of, for example, re-aiming an antenna.  A
rogue (or compromised) router can take advantage of this.  A rogue (or
compromised) modem could indicate an incorrect hop count or P-bit setting
that may result in unreachable destinations (after the router acts on that
information).

rfc8175 already mentions some related risks.  However, I think that the
point still needs to be called out specifically because of the new
functionality introduced.


...
364 5.3.  Hop Control Actions Registry

366   Upon approval of this document, IANA is requested to create a new
367   DLEP registry, named "Hop Control Actions Values".  The following
368   table provides initial registry values and the [RFC8126]. defined
369   policies that should apply to the registry:

[nit] s/[RFC8126]./[RFC8126]


...
409 6.2.  Informative References

411   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
412              Writing an IANA Considerations Section in RFCs", BCP 26,
413              RFC 8126, DOI 10.17487/RFC8126, June 2017,
414              <https://www.rfc-editor.org/info/rfc8126>.

[major] This reference should be Normative.