[Nmc-wg] [ogf nmc-base svn commit] r26 - /

[svn at ogf.org]

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.