- nmc-wg - lists.ogf.org

[ogf nmc-base svn commit] r32 - /
by svn＠ogf.org 22 Jun '10

22 Jun '10

Author: zurawski Date: 2010-06-22 09:39:59 -0500 (Tue, 22 Jun 2010) New Revision: 32 Modified: nmc-base.pdf Log: Draft for OGF 29 -jason Modified: nmc-base.pdf =================================================================== (Binary files differ)

1 0

Re: [Nmc-wg] Call 6/10 @ 15:00 UTC
by romradz＠man.poznan.pl 18 Jun '10

18 Jun '10

Thanks Michael. In general I think it would be perfect if NMC could support both approaches of data transfer (streaming and separate data channel). btw. could you write what's the difference between Flow MA (or Flow Subscription MA) and Flow Subscription MP. It's not clear to me (the picture https://wiki.man.poznan.pl/perfsonar-mdm/images/perfsonar-mdm/2/28/JRA1_Net… is confusing). ... and do you have examples of control NMC messages you were using for setting up tunnel(s). Roman On Wed, 16 Jun 2010, Michael Bischoff wrote: > Well the old, and really old is still on the wiki: > https://wiki.man.poznan.pl/perfsonar-mdm/index.php/Flow_Subscription_MP/Imp… > > The (over?) simplified rundown is as follows: > > ---------------------------------------------------- > On perfsonar layer(control channel): > Subscribe message( subject(what do you want a stream of) + > target(setup tunnel to where) -> > <- key > ... > keepalive(with key) -> > <- ok > ... > Unsubscribe -> > <- clean tear down > ---------------------------------------------------- > On the transport layer(data channel): > (pre condition -> subscribe request) > perfsonar service creates a tunnel to target. > write data to service end of tunnel > > Now an extension upon the NMC-base that would standardize the > 'persfonar as control channel + data channel' would > need to ratify a couple of things like tunnel type negotiation(current > zebadee is simply assumed and used), some > definition over what protocols are allowed(they should probably be > 'open') and other things that I can't remember right > now. > > papers describing different implementations(non-perfsonar/nmc) should > be widely available. > The short, as most of the papers I've seen also seem to comment, is > that setting up a separate data channel is > costly and one needs to be able to justify this cost. Such an approach > is only useful in cases where you know > beforehand that there is going to be a lot of data. Other issue is the > cost of converting data because the data- > channel can 'speak' anything it wants it doesn't require conversion > which might be, a big enough safe that it offsets > the cost of setting up the separate channel. a Perfsonar specific > advantage is that it allows for smoother transition > to perfsonar as you can utilize perfsonar to discover services but > still receive in know format and process it using > (non-perfsonar) tools that are already available. (this avoids the all > or nothing barrier) > > Where there any specifics you wanted to know? > > Best regards, > > Michael > > > On Wed, Jun 16, 2010 at 1:18 PM, romradz(a)man.poznan.pl > <romradz(a)man.poznan.pl> wrote: >> >> Hi Michael, >> >> is there the documentation of control channel approach which was implemented >> in flow subscription MA? >> >> Cheers, >> Roman >> >> >> On Fri, 11 Jun 2010, Michael Bischoff wrote: >> >>> I guess we postponed or something went really wrong.. >>> I've set up a doodle so people can indicate their availability for next >>> week: >>> http://doodle.com/m7vh8pd6exbaqf29 >>> >>> A proposal for streaming in NMC is here: >>> (mind you in still a work in progress/draft and it hasn't been proof >>> read/spell checked) >>> https://docs.google.com/a/controplex.com/View?id=dpn9385_1fmtsx7g9 >>> In it's current form should be good enough for gettign the discussion >>> started. >>> >>> Best regards, >>> >>> Michael >>> On Thu, Jun 10, 2010 at 4:03 PM, Michael Bischoff >>> <Michael.bischoff(a)controplex.nl> wrote: >>> That is a possibility I suppose, I don't know about the availability >>> of others. >>> Who is going to be available as it currently stands? >>> >>> >>> On Thu, Jun 10, 2010 at 3:14 PM, romradz(a)man.poznan.pl >>> <romradz(a)man.poznan.pl> wrote: >>> >>> Hi, >>> >>> it will be very difficult to me to join the meeting today :( Can we >>> postpone it? >>> >>> Roman >>> >>> >>> On Tue, 8 Jun 2010, Jason Zurawski wrote: >>> >>> All; >>> >>> There will be an NMC call this thursday at 15:00 UTC. The meeting will >>> be run by Michael, and the agenda is to discus altering the protocol to >>> allow streaming (the response in particular). The notes and agenda will >>> be posted here: >>> >>> >>> https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201006… >>> >>> Thanks; >>> >>> -jason >>> _______________________________________________ >>> Nmc-wg mailing list >>> Nmc-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/nmc-wg >>> >>> >>> >>> >> >

2 1

Call 6/10 @ 15:00 UTC
by Jason Zurawski 16 Jun '10

16 Jun '10

All; There will be an NMC call this thursday at 15:00 UTC. The meeting will be run by Michael, and the agenda is to discus altering the protocol to allow streaming (the response in particular). The notes and agenda will be posted here: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/201006… Thanks; -jason

3 7

Reminder on Upcoming Meetings
by Jason Zurawski 16 Jun '10

16 Jun '10

All; OGF 29 is June 20-22nd. We will be holding 2 NMC sessions, but dial in will not be available. The regular conference calls on June 24th, July 8th, and July 22nd will be postponed unless there is a volunteer to set the agenda and lead. I will be unavailable on those dates. Thanks; -jason

1 0

NMC Streaming Call - Canceled
by Jason Zurawski 16 Jun '10

16 Jun '10

All; It seems that the MCU prevented most from joining today, and due to other commitments some of us needed to leave for other meetings. We will try to hold this call sometime in the future, or add it to the agenda for our regular meetings. We will also need to explore having a backup MCU available. I will check to see if the ESnet or Internet2 MCUs would be available at our regular meeting times. Thanks; -jason

2 2

[ogf nmc-base svn commit] r31 - /
by svn＠ogf.org 15 Jun '10

15 Jun '10

Author: zurawski Date: 2010-06-15 06:04:09 -0500 (Tue, 15 Jun 2010) New Revision: 31 Modified: acknowledgements.tex conclusion.tex nmc-base.pdf nmc-base.tex Log: Movin the security section before the notational conventions. Minor cleanups to ack/conc that were left out of a commit. -jason Modified: acknowledgements.tex =================================================================== --- acknowledgements.tex 2010-06-15 00:17:13 UTC (rev 30) +++ acknowledgements.tex 2010-06-15 11:04:09 UTC (rev 31) @@ -1,4 +1,8 @@ \section{Acknowledgements} \label{s:acknowledgements} -The authors gratefully acknowledge the contributions of the perfSONAR consortium to this work. Specifically staff and member institutions from ESnet, Geant, Internet2, and RNP have provided extensive input and feedback into the implementation of this and all NMC-WG protocols. +The authors gratefully acknowledge the contributions of the perfSONAR consortium +to this work. Specifically staff and member institutions from ESnet, G\'{E}ANT, +Internet2, and RNP have provided extensive input and feedback into the +implementation of this and all NMC-WG protocols. + Modified: conclusion.tex =================================================================== --- conclusion.tex 2010-06-15 00:17:13 UTC (rev 30) +++ conclusion.tex 2010-06-15 11:04:09 UTC (rev 31) @@ -5,4 +5,11 @@ % % Conclusion is weak, this needs to be two paragraphs and sum up the work. -The preceding work has described a simple protocol that will form the basis of communication for software exchanging both network measurements and topological information. This protocol is both minimal and flexible --- extension to specific use cases is possible and expected. This work has been careful to retain the concepts described in other working groups including \textbf{NM-WG} and \textbf{NML-WG} in an effort to remain compatible with the primary data types. +The preceding work has described a simple protocol that will form the basis of +communication for software exchanging both network measurements and topological +information. This protocol is both minimal and flexible --- extension to +specific use cases is possible and expected. This work has been careful to +retain the concepts described in other working groups including \textbf{NM-WG} +and \textbf{NML-WG} in an effort to remain compatible with the primary data +types. + Modified: nmc-base.pdf =================================================================== (Binary files differ) Modified: nmc-base.tex =================================================================== --- nmc-base.tex 2010-06-15 00:17:13 UTC (rev 30) +++ nmc-base.tex 2010-06-15 11:04:09 UTC (rev 31) @@ -118,12 +118,12 @@ \input{acknowledgements} +\input{security_considerations} + \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. -\input{security_considerations} - \section{Contributors} \textbf{Jason Zurawski} \\

1 0

[ogf nmc-base svn commit] r30 - /
by svn＠ogf.org 15 Jun '10

15 Jun '10

Author: mbischoff Date: 2010-06-14 19:17:13 -0500 (Mon, 14 Jun 2010) New Revision: 30 Modified: security_considerations.tex Log: added missing label to \section{Security Considerations} Modified: security_considerations.tex =================================================================== --- security_considerations.tex 2010-06-15 00:08:17 UTC (rev 29) +++ security_considerations.tex 2010-06-15 00:17:13 UTC (rev 30) @@ -1,4 +1,5 @@ \section{Security Considerations} +\label{s:security_considerations} \subsection{Quality of service and resource control} \label{s:Quality_of_service_and_resource_control}

1 0

[ogf nmc-base svn commit] r29 - /
by svn＠ogf.org 15 Jun '10

15 Jun '10

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

1 0

[ogf nmc-base svn commit] r28 - /
by svn＠ogf.org 14 Jun '10

14 Jun '10

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.

2 1

[ogf nmc-base svn commit] r25 - /
by svn＠ogf.org 14 Jun '10

14 Jun '10

Author: mbischoff Date: 2010-06-14 16:34:16 -0500 (Mon, 14 Jun 2010) New Revision: 25 Modified: nmc-base.tex Log: Added first version of security considerations Modified: nmc-base.tex =================================================================== --- nmc-base.tex 2010-05-27 18:15:38 UTC (rev 24) +++ nmc-base.tex 2010-06-14 21:34:16 UTC (rev 25) @@ -102,17 +102,17 @@ \newpage -\input{introduction_new} +\input{introduction} -\input{motivation_new} +\input{motivation} -\input{messages_new} +\input{messages} -\input{chaining_new} +\input{chaining} -\input{result_codes_new} +\input{result_codes} -\input{extension_new} +\input{extension} \input{conclusion} @@ -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} \\

2 1