E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old November 14th, 2018   #1
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 19
Default 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?
shawn is offline   Reply With Quote
Old November 14th, 2018   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 14th, 2018   #3
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 19
Default

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?
shawn is offline   Reply With Quote
Old November 14th, 2018   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 15th, 2018   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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 is offline   Reply With Quote
Old November 15th, 2018   #6
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old November 15th, 2018   #7
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 19
Default

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!
shawn is offline   Reply With Quote
Old November 16th, 2018   #8
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old November 16th, 2018   #9
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 19
Default

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.
shawn is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Queued Message for SubDevices sandor RDM Interpretation Questions 2 May 14th, 2018 02:10 AM
Status Message Markers hamish RDM General Implementation Discussion 4 December 9th, 2010 11:12 PM


All times are GMT -6. The time now is 12:41 AM.


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