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

[Lou Berger <[e-mail]>]

Hi,

     Thanks for the comments -- see below for responses

On 3/8/2019 3:11 PM, Justin Dean wrote:
> Only a few inline comments. Marked with JWD
>
> On Thu, Mar 7, 2019 at 9:12 PM Lou Berger <[e-mail] 
> <mailto:[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]> <mailto:[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] <mailto:[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.

given that these states are not defined anywhere in the context of DLEP, 
I'm reluctant to add it here -- unless there is a solid reference 
defining such.  Do you have a good reference?

alternatively, how about s/SHOULD attempt/SHOULD take whatever actions 
are needed


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

I think the text covers this in "that have previously been processed" -- 
is this not sufficient?  If not, I'll change it back to SHOULD?

Thanks!

Lou


>>>>>
>>>>>     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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/manet
>