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

From: Lou Berger <[email-masked]>
Date: Thu, 7 Mar 2019 20:54:21 -0500

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 <[email-masked]> 
wrote:

> Ping!
>
> Just wondering where we are with this document.
>
> Alvaro.
>
> On November 20, 2018 at 3:50:17 PM, Alvaro Retana 
> ([email-masked] <mailto:[email-masked]>) 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?

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

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

---

From: Justin Dean <[email-masked]>
Date: Fri, 8 Mar 2019 15:11:54 -0500

Only a few inline comments. Marked with JWD

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

> Hi,
>
> I'm totally embarrassed to have missed both your initial comments and this
> ping.  You have my complete apologies!
>
> ------------------------------
>
> <[email-masked]> wrote:
>
>> Ping!
>>
>> On November 20, 2018 at 3:50:17 PM, Alvaro Retana ([email-masked])
>> wrote:
>>
>> Dear authors:
>>
>> 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.
>>
>>> I'll wait for these points to be addressed before starting the IETF Last
>>> Call.
>>>
>>> Thanks!
>>>
>>> Alvaro.
>>>
>>>
>>> 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
>>> [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?
>>>
>>> 113   Three data items are defined by this extension.  The Hop Count 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
>>> 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
>>> 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.
> 131   The data item also contains an indication of when a destination which
>>> 140   A router receiving a Hop Count Data Item MAY use this information
>>> in
>>> 142   scope of this document.  The absence of the Hop Count Data Item
>>> MUST
>>> [major] s/MAY/may  The rest of the sentence says that the use is out of
>>> scope, so there's nothing normative here.
>>>
>>> okay
>
>>
>>> 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
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 151
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 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.
>>> [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
>>> 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
>>> 181      A value of zero (0) is used to indicated that processing of a
>>> Hop
>>> [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
>>> ...
>>> 203   address.  Once the change is made, fails or is rejected, the modem
>>> 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
>>> 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
>>> [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.
>>>
> 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
>>> [minor] "Once the change is made, or fails or is rejected..."  Why could
>>> the change fail?
>>>
> 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:
>
>>> 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
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 233
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> 263   clear all control actions that have previously been processed on a
>>> 265   received in a Link Characteristics Request Message, a modem SHOULD
>>> 266   clear all control actions that have previously been processed for
>>> the
>>> [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.
>>>
> 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.

>>> 272   MUST NOT be sent in a Session Update Message message.  It indicates
>>> 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.
>>> above, I think that the last sentence (and any other details) are not
>>> needed and redundant.
>>>
>>> agreed and dropped
>
>>
>>> 308   A modem which receives the Suppress Forwarding Data Item in a Link
>>> 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
>>> 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
>>> 322   inherently introduce any additional threats above those documented
>>> in
>>>
>>> [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.
>>>
>>> sure.
>
>
>>> ...
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 8 Mar 2019 16:10:55 -0500

Hi,

     Thanks for the comments -- see below for responses

On 3/8/2019 3:11 PM, Justin Dean wrote:
> On Thu, Mar 7, 2019 at 9:12 PM Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     I'm totally embarrassed to have missed both your initial comments
>     and this ping.  You have my complete apologies!
>
>     On February 12, 2019 4:12:15 PM Alvaro Retana
>     <[email-masked]> <mailto:[email-masked]> wrote:
>
>>     Ping!
>>
>>>     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.
>
>     Sure.  How about adding:
>
>     <t>
>>>>>     I'll wait for these points to be addressed before starting the
>>>>>     IETF Last Call.
>>>>>
>>>>>     Thanks!
>>>>>
>>>>>     Alvaro.
>>>>>
>>>>>
>>>>>     [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.
>
>>>>>
>>>>>     destinations via multi-hop forwarding.  DLEP Destination
>>>>>     messages can be used to report such connectivity, see
>>>>>     [RFC8175]..."  Where does rfc8175 talk about that?
>     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.
>
>
>>>>>
>>>>>     ...
>>>>>     118   used by a router to request that a modem disable
>>>>>     multi-hop forwarding
>>>>>     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
>>>>>     [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.
>>>>>     142   scope of this document. The absence of the Hop Count
>>>>>     Data Item MUST
>>>>>     [major] s/MAY/may  The rest of the sentence says that the use
>>>>>     is out of scope, so there's nothing normative here.
>     okay
>>>>>
>>>>>     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
>>>>>     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.
>     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:
>>>>>
>>>>>     181      A value of zero (0) is used to indicated that
>>>>>     processing of a Hop
>>>>>     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
>>>>>     ...
>>>>>     204   MUST respond with a Link Characteristics Response
>>>>>     Message containing
>>>>>     205   an updated Hop Count Data Item.  Note that other
>>>>>     destinations can be
>>>>>     210   a Destination Down Message.  The modem MUST also notify
>>>>>     the router of
>>>>>     [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

>>>>>     216   Message SHOULD attempt to make the change indicated by
>>>>>     the data item
>>>>>     219   Message with an appropriate Status Code. Destination
>>>>>     specific impact
>>>>>     220   resulting from the processing of a Hop Control Data Item
>>>>>     in a Session
>>>>>     [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.
>
>     The far end modem rejects making the requested change, perhaps due
>     to policy.
>
>>>>>     failure/rejection.  It might be worth clarifying that
>>>>>     (specially the rejection case) somewhere.
>>>>>
>>>>>
>     Okay how about:
>
>>>>>     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
>>>>>     266   clear all control actions that have previously been
>>>>>     processed for the
>>>>>     [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

>>>>>     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
>>>>>     [minor] What is the difference between Reset and Terminate
>>>>>     (for a particular destination)?
>>>>>     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
>>>>>     [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
>>>>>
>>>>>     [major] s/MAY/may  There's nothing about the change that would
>>>>>     make forwarding optional.
>     s/MAY/can
>
>>>>>
>>>>>     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.
>
>>>>>
>>>>>     ...
>     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
>
>     [email-masked] <mailto:[email-masked]>

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 Mar 2019 16:47:09 +0100

On March 8, 2019 at 9:54:24 AM, Lou Berger ([email-masked]) wrote:

Lou:

Hi!

Thanks for getting this done.

I have a couple of nits below — and will also send a reply to your exchange
with Justin.   I’ll start the IETF LC in a couple of minutes.

Alvaro.

...

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

Yes, I think that’s fine.  Just a nit: there’s some orphaned text (“example
using”) left in the new text.

...

…but you still didn’t define the registry. :-(

Seriously:  it’s ok.  I trust that the next user will do the right thing.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 15 Mar 2019 16:48:04 +0100

On March 9, 2019 at 5:10:57 AM, Lou Berger ([email-masked]) wrote:

Hi!

...

I don’t like that either because it is not specific: what are the needed
actions??

I do like the explanation you added (below) about why it is really only an
attempt (why there may be failure/rejection).

So…I think that we could go back to “SHOULD attempt” given that there is an
explanation in the text.

BTW, there’s another “SHOULD attempt” in §3.2.3.

...

Thanks!

Alvaro.

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Mar 2019 12:09:34 -0400

On 3/15/2019 11:47 AM, Alvaro Retana wrote:
> On March 8, 2019 at 9:54:24 AM, Lou Berger ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
> Lou:
>
> Hi!
>
> I have a couple of nits below — and will also send a reply to your 
> exchange with Justin.   I’ll start the IETF LC in a couple of minutes.
>
> Alvaro.
>
>
> ...
>>>>>> ...
>>>>>> 72 1. Introduction
>>>>>> ...
>> Done, please see the changes at the repo posted above and let me know 
>> if the changes are sufficient.
>
> Yes, I think that’s fine.  Just a nit: there’s some orphaned text 
> (“example using”) left in the new text.
>
>
woops - thanks.
>> 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 ;-)
>
Thanks!

I've pushed your and some other nit changes to the repo, but don't think 
they need hold anything.

Thanks,

Lou

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Fri, 15 Mar 2019 17:11:48 +0000

Lou,

Another nit, see below.

> -----Original Message-----
> From: manet <[email-masked]> On Behalf Of Lou Berger
> Sent: vrijdag 15 maart 2019 17:10
> To: Alvaro Retana <[email-masked]>; draft-ietf-manet-dlep-multi-
> [email-masked]
> Cc: [email-masked]; Mobile Ad-hoc Networks Working Group <manet-
> [email-masked]>
> Subject: Re: [manet] AD Review of draft-ietf-manet-dlep-multi-hop-
> extension-05
> 
> 

... and then there is a then that should be a than 😉 (line 191 in the latest repo version: "any messages other THAN a Link Characteristics Response Message.")

Thanks,
Ronald

> Lou
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: Lou Berger <[email-masked]>
Date: Fri, 15 Mar 2019 13:46:09 -0400

thanks!