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

[Lincoln Lavoie <[e-mail]>]

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

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

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.

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

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

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.

Please let me know if there are any other ways I can help out, great start
on the protocol!

Cheers,
Lincoln

On Tue, Oct 19, 2021 at 6:32 PM MORTON JR., AL <[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
>
>    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]
> https://www.ietf.org/mailman/listinfo/ippm
>


-- 
*Lincoln Lavoie*
Principal Engineer, Broadband Technologies
21 Madbury Rd., Ste. 100, Durham, NH 03824
[e-mail]
https://www.iol.unh.edu
[phone] (m)
<https://www.iol.unh.edu>