Michael; Perhaps I wasn't clear, I just wanted you to revert the user of 'title' vs 'title_new'. We need to have those names for the processing of the makefile. You are more than welcome to add your section on security. -jason On 6/14/10 6:50 PM, svn@ogf.org wrote:
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.
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg