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

[Lou Berger <[e-mail]>]

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

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