Author: mbischoff Date: 2010-06-14 19:08:17 -0500 (Mon, 14 Jun 2010) New Revision: 29 Added: security_considerations.tex Modified: / nmc-base.tex Log: Adding first version of security considerations Property changes on: ___________________________________________________________________ Name: svn:ignore + result_codes_new.tex motivation_new.tex messages_new.tex .externalToolBuilders tmp .project .texlipse chaining_new.tex extension_new.tex introduction_new.tex Modified: nmc-base.tex =================================================================== --- nmc-base.tex 2010-06-14 22:50:01 UTC (rev 28) +++ nmc-base.tex 2010-06-15 00:08:17 UTC (rev 29) @@ -122,17 +122,8 @@ The key words ``MUST'' ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' are to be interpreted as described in RFC 2119 \cite{rfc2119}, except that the words do not appear in uppercase. -\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. +\input{security_considerations} -There are no security considerations. - \section{Contributors} \textbf{Jason Zurawski} \\ Added: security_considerations.tex =================================================================== --- security_considerations.tex (rev 0) +++ security_considerations.tex 2010-06-15 00:08:17 UTC (rev 29) @@ -0,0 +1,86 @@ +\section{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. +% TODO insert LINK +% 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\cite{nmwg-base}, +% 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. + +% XXX mb - 2010/6/14 +% Uncertain if I should add (at this time) a section on data integrity like +% vulnerable to tampering (measurement data) + \ No newline at end of file