E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   When locked, which comes first, NR_WRITE_PROTECT or message checking? (http://www.rdmprotocol.org/forums/showthread.php?t=1293)

shawn November 14th, 2018 08:13 PM

When locked, which comes first, NR_WRITE_PROTECT or message checking?
 
I have a question about the interpretation of when to send a NR_WRITE_PROTECT NACK response when a device is in a locked state.

When a device is in some lock state, E1.37-1 says that it should return NR_WRITE_PROTECT for those PID's that require locking. Should this be returned before even looking at a message, or should the message first be examined for format or content errors and then the NR_WRITE_PROTECT sent?

There are really three cases for when a message/PID gets denied. Either it has an unknown PID, the command class is not supported, or it has some bad formatting or content errors. The question of when to send the NR_WRITE_PROTECT arises for all three.

If we send the NR_WRITE_PROTECT first, it makes the code easier to write, because there's only one check at the top. If it's sent only after a message is checked (with associated potential NR_UNKNOWN_PID, NR_UNSUPPORTED_COMMAND_CLASS, or NR_FORMAT_ERROR/NR_DATA_OUT_OF_RANGE), then those other errors have priority and are returned first.

Thoughts?

sblair November 14th, 2018 11:12 PM

Hey Shawn,

Welcome to the RDM forums! It's a good question and you are likely to get different answers from different people. The standard is not specific about order things must be validated in so it is largely up to your implementation.

Some people are very strict in their implementations and like to fully validate the message header before trying to act on the contents. As you indicate it also tends to be how your parser is written as well.

I generally try to take an accepting view that if I can understand the message contents then I'll try and act on it, regardless if there is some benign formatting issue.

That being said, I tend to prefer inspecting the Command Class and the PID first. Most everything after that is more subjective. Even if you have a Write Protect you will still need to respond to Get Commands and there may be some Set Commands that are still considered valid. So it really just depends on your implementation. My belief is that without a valid Command Class and PID, you really don't fully know what the intent of the message is to properly NACK the contents.

shawn November 14th, 2018 11:21 PM

Thanks for your quick response, Scott.

My WRITE_PROTECT code is already only at the top of the part that examines SET messages (per section 3.7 of E1.37-1, where it says that LOCK plus WRITE_PROTECT is for SET_COMMAND).

I think that I'll return NR_WRITE_PROTECT before checking message format and data, but I'm still considering whether to return NR_WRITE_PROTECT before checking for UNKNOWN_PID and before UNSUPPORTED_COMMAND_CLASS.

Here's why I'm debating this. On trusted systems and setups, I don't see a problem broadcasting information about what is and isn't supported on the device. However, if someone took the trouble to lock things down (even with a minimal capability like E1.37-1's LOCK), then is it more security conscious to not leak this information? Maybe this is overthinking it too much on what isn't really a secure system anyway.

So then the other consideration is what would be "nice to have" from the controller's point of view? WRITE_PROTECT on all SET commands or WRITE_PROTECT on only supported SET commands?

sblair November 14th, 2018 11:29 PM

The Write Protect mechanism is weak security at it's best.... which was all it was meant to be. It can be cracked with a simple for() loop by a malicious controller.

Generally speaking I think it is more useful to give a useful response to the controller. If PID or Command Class is wrong I tend to favor that over the more specific NR codes as there is something more blindingly wrong. If you can tell what the intent of the message was and then you have a WP scenario I would return the NR_WRITE_PROTECT at that point.

prwatE120 November 15th, 2018 01:06 AM

I would encourage you to treat this like any other PID.

Check that the Header is correct (Sub StartCode/Target UID/Checksum/Message Count field etc).

Check that you support the PID (ie there is one or more situations where you WILL action a SET request or provide data to a GET request)

Check that the COMMAND class is appropriate for the current PID

Check that the FORMAT of the data (essentially the PDL) is appropriate for the supplied PID.

At this point I would either validate the DATA or issue the WRITE PROTECT dependent on the lock state you are in.

From a systems perspective it would be unhelpfull to respond with WRITE PROTECT even when the PID is unsupported or the PID is incorrectly formated. I regard WP as an error that should stop being returned if I were to legitimately unlock the device by whatever means. Having unlocked the device I would reasonably expect the request to be actioned, not replaced by another NACK message "Ha Ha you wasted your time unlocking as I dont actually support the PID"

As others have said, the LOCK mechansim was never intended to be super high security, just a simple means of reducing the probability of accidental changes being made.

Peter

prwatE120 November 15th, 2018 01:09 AM

Quote:

So then the other consideration is what would be "nice to have" from the controller's point of view? WRITE_PROTECT on all SET commands or WRITE_PROTECT on only supported SET commands?
To answer this, I would argue, as per my earlier response

WRITE_PROTECT on only supported SET commands, when the message FORMAT is otherwise correct.

I would accept assertion of WP even if the data is out of range.

Peter

shawn November 15th, 2018 10:18 AM

I’ve chosen to send the write-protect NACK after checking for UNKNOWN_PID, UNSUPPORTED_COMMAND_CLASS, and FORMAT_ERROR, but before DATA_OUT_OF_RANGE.

Thanks for everyone’s suggestions!

ericthegeek November 16th, 2018 11:38 AM

I agree with most of what's been said, but want to add one more items:


In my opinion NR_SUB_DEVICE_OUT_OF_RANGE should be the first thing you check for.



If the message is sent to a sub-device that doesn't exist (or to any sub-device on a root-only responder) it should be NACK'd with this reason code regardless of the PID and CC.



This is a common mistake: Root-only responders often don't validate the sub-device field, which can have disastrous consequences when the controller sends a broadcast set to a sub-devices.

shawn November 16th, 2018 12:48 PM

I forgot to add that to my list of things I look at in my previous responses. I don't even look at the message if it's for a non-existent sub-device. But thank you for the reminder. :)

I wonder if there are any more "extreme" RDM tests, beyond everything the RDM test suite in OLA provides.


All times are GMT -6. The time now is 06:44 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.