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

[Jason Zurawski]

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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg