QoS marking at PC - security risk?

[mitchell helton]

Good afternoon!

We are working on fine tuning our QoS policies and have considered tagging certain traffic at the PC level using Windows Group Policy.  Therefore, the access ports connecting to these devices would trust the tags.

The majority of our users are not local administrators and we will be doing 802.1x port authentication in the near future.  Is this a security concern to create an unconditional trust boundary at the access layer port?  Or am I just being paranoid?

Thanks for your time... I look forward to hearing your thoughts!

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yes, you do open yourself up to some risk that someone may abuse the QoS trust.

What we done in a similar situation is police special QoS markings at expected normal usage rates.  For example, we allow 300 Kbps (per user port) for EF marked traffic.  Above that, we remark excess to default.  This doesn't preclude someone from using the EF marking for non-realtime traffic, but at least it won't be much abuse.

[mitchell helton]

Thanks Joe... that seems like a reasonable approach.

What brought this on was Lync 2010.  We were planning on tagging this traffic as it was leaving PCs, but didn't want a user to be able to abuse this - although it would probably be unlikely.

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Yup, it's unlikely, doesn't mean it won't happen. This doesn't mean you need to make sure it can't happen.  Best to consider risk vs. cost.

More of a problem for an instant messaging app, is it also being used (licitly) to transfer large files.  If the platform supports microflow policing, you can target excess use per flow with certain markings.