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

[Justin Dean <[e-mail]>]

Only a few inline comments. Marked with JWD

On Thu, Mar 7, 2019 at 9:12 PM Lou Berger <[e-mail]> wrote:

> Hi,
>
> I'm totally embarrassed to have missed both your initial comments and this
> ping.  You have my complete apologies!
>
> See below for responses in-line.
>
> Also changes described in this message are posted at:
>
>
> https://github.com/louberger/dlep-extensions/commit/69a401553437037958c4502aaea58a21c1a84688
>
> and a formatted version at:
>
>
> https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/louberger/dlep-extensions/master/multi-hop/draft-ietf-manet-dlep-multi-hop-extension.xml
>
>
> ------------------------------
>
> On February 12, 2019 4:12:15 PM Alvaro Retana <[e-mail]>
> <[e-mail]> wrote:
>
>> 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.
>>
>> How about in the introduction, adding:
>   It is important to note that the use of the hop control mechanism
>   defined in this can result in connectivity changes and even loss of
>   the ability to reach one or more destinations.  The defined mechanism
>   will report such connectivity changes, but the details of what a
>   router does or how it reacts to such are out scope of this document.
>
> Along similar lines, I think that the Security Considerations section
>> should also include (at least) a mention of the risks.
>>
>>
> Sure.  How about adding:
>
> <t>
>   This extension does define one mechanism that is worth particular
>   note.  This extension includes a Hop Control mechanism, see <xref
>   target="sec-di-hcontrol"/>, that is similar to the Link
>   Characteristics Request Message in that it can impact the set of
>   destinations reported as reachable.  With the Link Characteristics
>   Request Message, this risk is implicit.  With the Hop Control
>   mechanism defined in this document it is more likely.  From a security
>   perspective, implementations should be aware of this increased risk
>   and may choose to implement additional configuration control
>   mechanisms to ensure that the Hop Control mechanism is only used under
>   conditions intended by the network operator.
>
>
>>> 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.
>>>
>>>
> Done, please see the changes at the repo posted above and let me know if
> the changes are sufficient.
>
>
>>> [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?
>>>
>>> does the following help? s/connectivity/reachable destinations
>
>
>>>
>>> ...
>>> 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?
>>>
>>> I think this is implementation specific.  For example if a modem or
> product usage is unlikely to show multiple hops default off seems
> reasonable, but the opposite is also possible.
>
>
>
>>> ...
>>> 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.
>>>
>>> Agreed.
> -  physical hops between the modem and a specific destination.  In other
> +  modem that transmits/sends data to reach a particular destination,
> +  i.e., hops, between the modem and a specific destination.  In other
>
> 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
>>>
>>> Thanks!
>
>
>>> ...
>>> 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.
>>>
>>> okay
>
>>
>>> 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.
>>>
>>> okay.
> -      described below.
> +      described below. This field MUST be ignored when the value
> +      contained in the Hop Count field is one (1).
>
>
>>> 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...
>>>
>>>
> My inclination would be to establish a registry on the second usage of the
> reserved field.  Right now I don't see additional uses and it seems like a
> lot of unneeded overhead at this point.  Of course, you're the AD so your
> view counts for more ;-)
>
>
>>> 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
>>>
>>> Thank you!
>
>
>>> [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.
>>>
>>> done.
>
>>
>>> 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.
>>>
>>> well there is the "fails or rejected" outcomes -- I don't think it's
> right to call these anything but an attempt.  Perhaps there's another way
> to address your concern and the possibility that the change can fail.  What
> do you think?
>

JWD This is actually because there is a hidden transient state: The modem
is attempting to make the change but it hasn't yet succeeded or failed.
The amount of time this takes is fully dependent on the modem/radio
characteristics so it would be inappropriate to put a fixed timeout value
here.  This may be more cleanly stated by defining what the "attempt" state
is.  The modem SHOULD enter the "attempt/resolving" state and once the
change is made, fails or is rejected, the modem MUST respond.

>
>
>>> 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?
>>>
>>> That the transmission characteristics of the channel don't support the
> one-hop connection, even though the control plane though it might.
>
> Why would it be rejected?
>>>
>>> The far end modem rejects making the requested change, perhaps due to
> policy.
>
> 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.
>>>
>>>
>>> Okay how about:
>
>   Failures may occur for multiple reasons, for example, the transmission
>   characteristics of the link don't support the one-hop connection at
>   the time of the request. Requests may be rejected by local policy.
>
>> 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.
>>>
>>> yikes - you are right! Great catch.
>
>>
>>> 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.
>>>
>>> I don't see a reason for not doing a MUST, I've made the change but
> others should speak up if this is a mistake...
>
> JWD I think it may be a mistake to change this to a MUST.  There may exist
chained requests or delayed requests which are not yet fully resolved and
in those cases the modem should keep some state on those pending actions so
the results of those actions don't cause errant behaviors.

>
>>> 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.
>>>
>>> s/MAY/can
>
>>
>>> [minor] What is the difference between Reset and Terminate (for a
>>> particular destination)?
>>>
>>> Terminate (possibly) undoes a direct connection
> Reset undoes direct connection and suppress forwarding
>
>>
>>> 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.
>>>
>>> agreed and dropped
>
>>
>>> 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.
>>>
>>> s/MAY/can
>
>
>>> 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).
>>>
>>> I'm not sure either of these are really new.  Please see if the text
> quoted above is adequate.
>
>> 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.
>>>
>>> sure.
>
>
>>> ...
>>> 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]
>>>
>>> thanks.
>
>
>>> ...
>>> 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.
>>>
>>>
>>> Okay.
>
> Thanks again for the comments -- once we resolve these I'll push a new
> version.  (I'll also push one before the monday cutoff no matter what.)
>
> Lou
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>