Author: mbischoff Date: 2010-06-14 16:37:17 -0500 (Mon, 14 Jun 2010) New Revision: 26 Added: security_considerations.tex Log: Added first version of security considerations Added: security_considerations.tex =================================================================== --- security_considerations.tex (rev 0) +++ security_considerations.tex 2010-06-14 21:37:17 UTC (rev 26) @@ -0,0 +1,89 @@ +\section{Security Considerations} +% XXX jz - 1/28/2010 +% +% A comment from Michael: +% +% Security considerations seem to be absent, like the transport layer that soap +% uses should provide integrity and privacy protection to avoid MITM-attacks +% etc. + +There are no security considerations. + +\subsection{Quality of service and resource control} +\label{s:Quality_of_service_and_resource_control} + +Any service that processes requests from external sources, will not respond or +progress requests (in a timely matter) if the resources that the service acts +upon are saturated. Given any request always causes some resource utilization, +resources can always be saturated by simply sending a lot of requests. This is +known as a Denial of Service(DoS) attack. NMC-based services might be more +likely to suffer successful attacks as their underlying function(collect, +perform or analyse network measurements) are resource intensive, thus requiring +fewer requests to to saturate the service. + +Implementers and deployers should assert how prone there service is to attack +and implement, configure or deploy countermeasures. Because information on this +subject matter is widely available, we will only mention that NMC facilitates +Authentication and Authorization; which could play a role in protecting the +service. + +Beyond this, a NMC service might in turn act upon external resources. Because of +this an NMC service could be prone to be abused to perform, boost or amplify DoS +attacks. Related; there is the subtle problem that emerges when the external +resource has some for of protection against abuse: + +A NMC service may obtain a 'bad reputation' given it emits certain request +patterns, a 'bad reputation' skews measurements. For example, given a NMC +service(A) performs a measurement of resource(B), if such a measurement is +performed frequent enough, resource(B) might presume that it's being attacked by +service(A) and therefore, opt to block service(A). Given that service(A) is now +being blocked, the service might falsely report that resource(B) is unavailable. + +These issues could be solved by tracking the actions performed by the service +and based upon this information opt to not perform certain requests at that +point in time. Given that this is the case opt to return to the client that it +should try later(insert footnote with link to respond code) or 'throttle' the +measurements. +% XXX mb - 2010/6/14 +% +% given trottling increases processing time should we let the client know this +% is goign to take longer and if so how? +Alternatively, if the service can assert that the action to be triggered would +have a too great of an impact upon the network it can opt to refuse to perform +it all together and instead inform the client that it should break the action up +into smaller actions if possible.(insert footnote with link to result code) + +\subsection{Data protection and privacy} +\label{Data_sensitivity_privacy} + +As outlined by Martin Swany in An Extensible Schema for Network Measurement and +Performance Data, +% TODO insert citation +Data passing through NMC services might be sensitive. Implementers should +provide means to control distribution of such data and deployers should +configure their services as well as manage the environment to prevent +unauthorised access to the data. + +In select cases part of the data that is invariant towards analysis can be +anonymised to prevent information being available to unauthorised parties while +still allowing measurements and analysis to take place. In such cases, to +ensure that the information is correctly interpreted, results must always +clearly advertise if and what information is anonymised.(insert link to section +that describes a standardised? way to do advertise this.) % TODO insert link + +% should we add an example to clarify? - source and or destination with respect +% to gathering statistics on the type of communication that passes trough a +% certain point. and or the relationship between consuming different types of +% communication can still be asserted Or given a list of ip's and protocols used +% the ip's could be randomised in such a way that the ip <-> protocol pairs +% still exist while the ip themself cannot be traced to any person. + +% Allowing a client to assert what information it can obtain might be useful +% with respect to user friendliness - like delay login promt or asserting what +% authorisation/roles it's missing. + +Given sensitive information is provided by a service to a authorized party one +has to prevent ease-dropping(or snooping), NMC-WG protocols will provide no +protection as we delegate this responsibility to the underlying transport. This +means implementers and deployers should take care in choosing which +transport(NMC-WG binding) to use.