Author: mbischoff
Date: 2010-06-14 17:50:01 -0500 (Mon, 14 Jun 2010)
New Revision: 28
Removed:
notational_conventions.tex
security_considerations.tex
Modified:
nmc-base.tex
Log:
reverting back to revision 24 per request.
Modified: nmc-base.tex
===================================================================
--- nmc-base.tex 2010-06-14 21:38:16 UTC (rev 27)
+++ nmc-base.tex 2010-06-14 22:50:01 UTC (rev 28)
@@ -102,26 +102,37 @@
\newpage
-\input{introduction}
+\input{introduction_new}
-\input{motivation}
+\input{motivation_new}
-\input{messages}
+\input{messages_new}
-\input{chaining}
+\input{chaining_new}
-\input{result_codes}
+\input{result_codes_new}
-\input{extension}
+\input{extension_new}
\input{conclusion}
\input{acknowledgements}
-\input{notational_conventions}
+\section{Notational Conventions}
-\input{security_considerations}
+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.
+
+There are no security considerations.
+
\section{Contributors}
\textbf{Jason Zurawski} \\
Deleted: notational_conventions.tex
===================================================================
--- notational_conventions.tex 2010-06-14 21:38:16 UTC (rev 27)
+++ notational_conventions.tex 2010-06-14 22:50:01 UTC (rev 28)
@@ -1,3 +0,0 @@
-\section{Notational Conventions}
-
-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.
Deleted: security_considerations.tex
===================================================================
--- security_considerations.tex 2010-06-14 21:38:16 UTC (rev 27)
+++ security_considerations.tex 2010-06-14 22:50:01 UTC (rev 28)
@@ -1,89 +0,0 @@
-\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.
