Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

["MORTON JR., AL" <[e-mail]>]

Hi Lincoln,

Thanks very much for your review! You’ve raised some good questions and identified areas to improve the draft.

I’ll reply point-by-point below, [acm]. I’ve left a few items for more discussion (haven’t implemented changes yet).
Al

From: Lincoln Lavoie <[e-mail]>
Sent: Wednesday, October 20, 2021 3:53 PM
To: IETF IPPM WG <[e-mail]>
Cc: MORTON JR., AL <[e-mail]>
Subject: Re: [ippm] Questions on draft-morton-ippm-capacity-metric-protocol-01

Hello Al (and everyone),

I give a quick read through and have some comments and questions on the current draft.

Section 3, Phase Item 1: It’s not clear if the expectation is for alignment of the mentioned items, i.e. both the client and server must support jumbo datagrams, or for a mismatch the connection is rejected.

[acm]
thanks, I’ll write clearer text to replace #1, and disentangle the client and server operation in the first sentence below (not yet modified).
1.  Setup Request and Response Exchange: client and server confirm
       matching protocol versions, authentication mode, and jumbo
       datagram support, or reject the connection.
BTW, all three of these configuration settings have to match, or the server sends the reject reply.

Put another way, is this a negotiation phase, where options are mutually agreed between client and server?  This is more clear in the setup section below, in terms of an “AND” type requirement.
[acm]
At this beginning Setup Exchange, there is no negotiation possible in the current protocol.
But assuming we expand the number of security modes (beyond the binary “authentication or unauthenticated” modes), the Setup Exchange could become more complicated, or be preceded by a new exchange to secure the communications.

Section 3, Phase Item 2: The set up of firewall rules.  It is unclear if this is a requirement or informative, such that linkage between the client implementation and a device's firewall might be required. Similarly, careful security considerations should be taken here, akin to duration of those “openings”
[acm]
This is an informative overview of the details in later sections that follow, and requirements will appear in the later sections. (I need to add this text in front of the list in Section 3).

This is the current text in question:
   2.  Test Activation Request and Response: ...  Note that the
       Test Activation exchange has opened any firewalls and network
       address/port translators for the test connection and the traffic
       that follows.

To answer your question, the client assumes that the co-located firewall will open the bi-directional address and port combinations in response to a client’s packet sent into the network, and subsequently close that combination after an idle time-out determined by the firewall. We didn’t imagine explicit control of the firewall, but nothing stops a management system from exerting its control.


Section 3, Phase Item 4: Should a comment be added to Item 4 about closing of firewall rules, etc.  I'm thinking about this separately then the opening of a socket / network port and the creation of the actual firewall rule allowing access to that port.
[acm]
ok, we could say that we don’t control the Firewall, and it is assumed to delete the state for the test communication after traffic stops (in phases 2 and 4).


In section 7.1, is the watchdog timer updated each time a test PDU is received, or each time a test PDU or status message is received.  In the case of downstream testing, for example, the server is sending down test PDUs and receiving upstream status information from the client. If the client or its connection were to die, the server should be able to detect this, from a lack of upstream status messages.  It is not clear if / how this is accomplished only at the receiver of test PDUs.
[acm]
In the current draft, I described the time-outs on the Test Setup, Test Activation, and Test Stream reception.
Specifically in 7.1:

   The watchdog timer at the receiver SHALL be reset each time a test

   PDU is received.
but I need to add the symmetrical time-out for Status PDUs in 7,2 (at least I don’t see it in the draft).
However, we have the symmetrical watchdog timers in the running code, and are ensuring all the needed timers and time-outs appear in TR-471 Issue 2, RFC 9097-to-be, TR-181, etc.

For the Setup Command Response Codes in Section 5, these seem to be indicated as an ENUM type parameter, but as an example, what if there were multiple conditions to be indicated to the client.  Could these be made into “flags” such that multiple could be set.  The consequence would be limiting the maximum number within the 8-bit size (which is already exceeded).
[acm]

Command Response Codes

Control Header Setup Request Code CHSR_CRSP_NONE     0 = None

Control Header Setup Request Code CHSR_CRSP_ACKOK    1 = Acknowledgement

Control Header Setup Request Code CHSR_CRSP_BADVER   2 = Bad Protocol Version

Control Header Setup Request Code CHSR_CRSP_BADJS    3 = Invalid Jumbo datagram option

Control Header Setup Request Code CHSR_CRSP_AUTHNC   4 = Unexpected Authentication in Setup Request

Control Header Setup Request Code CHSR_CRSP_AUTHREQ  5 = Authentication missing in Setup Request

Control Header Setup Request Code CHSR_CRSP_AUTHINV  6 = Invalid authentication method

Control Header Setup Request Code CHSR_CRSP_AUTHFAIL 7 = Authentication failure

Control Header Setup Request Code CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request
Yes, it’s a good point How does the protocol handle the multiple error case explicitly (I’m not sure that we don’t, but more needs to be said, or convert to flags (except that we ran out of 8 bits already, as you point-out!).

I’m leaving this as an open issue for more discussion.


Currently none of the status messages are protected against bit errors (i.e. no checksum or similar).  Would there be benefit in adding that level of protection to the control channel?  This would protect against a bit flip that could cause "misalignment" between what the client / server are "doing."
[acm]
Possibly, the Status PDU could benefit.  The feedback status messages convey critical measurements from, OR the Sending Rate Structure to, the client. Maybe we add a stronger protection at this point in time, to ensure these messages are not spoofed by an on-path attack (Attack in the middle).

I’m leaving this as an open issue for more discussion.


Also within the Section 5 Setup Command I’m guessing the authDigest of the setup request message is intended as a sort of “shared password” the valid clients would use to identify themselves. Would it make sense to mention, as an informative comment it might be worth setting more unique credentials per client via an out of band mechanism, like TR-069, assuming tests are being directed by someone like a service provider?  I know security is a much larger topic, but discouraging any type of shared credential is always good practice in my opinion.
[acm]
Yes, shared password was a feature for the beginning open-source implementation. We didn’t want to put up a protocol with absolutely zero authentication, and Len added this last Summer before the first OB-UDPST Release.
We can make more extensive changes when addressing the question of Security modes and methods, and TR-069 is surely a good OOB example.

I’m leaving this as an open issue for more discussion, which will be subsumed by determining new Security Modes and how to implement them (Section 10).

Please let me know if there are any other ways I can help out, great start on the protocol!
[acm]
Will do, and Thanks again!  Look for an updated draft on Oct 25 at the submission deadline.

Cheers,
Lincoln

On Tue, Oct 19, 2021 at 6:32 PM MORTON JR., AL <[e-mail]<mailto:[e-mail]>> wrote:
Hi IPPM,

Len Ciavattone and I am looking for some feedback on our protocol [0] designed to help measure the Maximum IP-Layer Capacity Metric (which will be published as an RFC shortly).

We are asking folks to take a look at the draft, because we are fairly sure you will have some questions!

One area where we know more development is required is the Modes of operation, which essentially describes how the different aspects/exchanges of the protocol will be made secure. This is pretty-much a green-field in our specification, so suggestions are very welcome.  Section 10 currently describes the different modes that we imagined to be useful (A through F below), but practical aspects of any proposed solution might indicate modes that should be combined, split-up, or new modes.

So, please give the draft and/or the list below a look, and let us know what you think.

thanks!
Al


[0] https://datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-morton-ippm-capacity-metric-protocol-01.txt__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xOFO-hbV$>

   3.  Client-server authentication and integrity protection for
       feedback messages conveying measurements is RECOMMENDED.  To
       accomodate different host limitations and testing circumstances,
       different modes of operation are recommended:

 A. Un-authenticated mode (for all phases)
AND
 B. OPTIONAL Authenticated set-up only
SHA-256 HMAC time-window verification (5 min time stamp verification)
(could add silent failure option)

     -=-=-=-=-=-=-=-=-=-

 C. Encrypted setup and test-activation
(currently using OpenSSL Library, so KISS, but may be too slow for
test packets)

     -=-=-=-=--=- Old/low-power host performance impacts -=-=-=-=-=-=-

 D. Encrypted feedback messages

 E. Integrity protection for test packets SHA-256 HMAC

 F. Encrypted test packets (maybe also valuable to defeat compression on links)

_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xIAIxb4s$>


--
Lincoln Lavoie
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
[e-mail]<mailto:[e-mail]>
https://www.iol.unh.edu<https://urldefense.com/v3/__https:/www.iol.unh.edu__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xBaQGOnn$>
[phone] (m)
[https://docs.google.com/uc?export=download&id=1j_iI6anwrnbQWNpTyuvukMLSNJJ8_8QU&revid=0B_0ujwABDnFZTmJiR3EzK0d1VjFKTjQvMENBWVM0QnA4ajhjPQ]<https://urldefense.com/v3/__https:/www.iol.unh.edu__;!!BhdT!3tvhVp5KCcOOLuqFn3oe5hJS357FIVTqatfgkYHDgtdbpoX9VJk8xBaQGOnn$>