[Anima] Fwd: [nmrg] RFC 8316 on Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations

[Jéferson Campos Nobre]

-- Forwarded message -
From: 
Date: ter, 13 de fev de 2018 23:12
Subject: [nmrg] RFC 8316 on Autonomic Networking Use Case for Distributed
Detection of Service Level Agreement (SLA) Violations
To: , , <
irtf-annou...@irtf.org>
Cc: , , <
rfc-edi...@rfc-editor.org>


A new Request for Comments is now available in online RFC libraries.


RFC 8316

Title:  Autonomic Networking Use Case for
Distributed Detection of Service Level Agreement
(SLA) Violations
Author: J. Nobre,
L. Granville,
A. Clemm,
A. Gonzalez Prieto
Status: Informational
Stream: IRTF
Date:   February 2018
Mailbox:jcno...@unisinos.br,
granvi...@inf.ufrgs.br,
lud...@clemm.org,
agonzalez...@vmware.com
Pages:  16
Characters: 40002
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-irtf-nmrg-autonomic-sla-violation-detection-13.txt

URL:https://www.rfc-editor.org/info/rfc8316

DOI:10.17487/RFC8316

This document describes an experimental use case that employs
autonomic networking for the monitoring of Service Level Agreements
(SLAs).  The use case is for detecting violations of SLAs in a
distributed fashion.  It strives to optimize and dynamically adapt
the autonomic deployment of active measurement probes in a way that
maximizes the likelihood of detecting service-level violations with a
given resource budget to perform active measurements.  This
optimization and adaptation should be done without any outside
guidance or intervention.

This document is a product of the IRTF Network Management Research
Group (NMRG).  It is published for informational purposes.

This document is a product of the Network Management Research Group of the
IRTF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce, rfc-dist and IRTF-Announce
lists.To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
  https://www.irtf.org/mailman/listinfo/irtf-announce

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
nmrg mailing list
n...@irtf.org
https://www.irtf.org/mailman/listinfo/nmrg
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Review comments//RE: WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

[Jéferson Campos Nobre]

Dear All.
It seems that we have the same "author information" as RFC 8321. I had
understood reading a previous email that this was not possible.
Thus, I suggest to maintain our current configuration (Michael as Editor
and everybody else as authors) and wait for the IESG review.
Best.
Jéferson

Em ter, 30 de jan de 2018 às 22:29, Toerless Eckert 
escreveu:

> Brian:
>
> The commits do not show all contributions to text.
> I often provided text in email to michael to merge in the past
> when i didn't want to bother about github.  But i am not insisting
> on editor status, but as indicated only author status, and
> for that the question of direct editing on github is irrelevant.
>
> I suggest we move everyone who explicitly wants to be
> listed as contributor into that section, otherwise we keep
> the list of authors (including Michael as only
> editor) as it is right now and we will see what happens during
> IESG review.
>
> There are also new RFCs coming out with 8 authors, eg: rfc8321.
>
> Cheers
> Toerless
>
> On Tue, Jan 30, 2018 at 10:24:54AM +1300, Brian E Carpenter wrote:
> > On 30/01/2018 09:00, Toerless Eckert wrote:
> > > If its ok. with the other contributors,
> > > i would appreciate if i could be listed as well as an editor.
> >
> > It's always a judgment call. Who's done most of the editing?
> > Certainly Michael Behringer.
> > (See https://github.com/mbehring/ANIMA-Reference-Model/commits/master)
> >
> > My view of this tricky topic:
> > https://tools.ietf.org/html/draft-carpenter-whats-an-author
> >
> >Brian
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] WGLC on draft-ietf-anima-reference-model-05 - Respond by January 22nd, 2018

[Jéferson Campos Nobre]

Dear Anima.
I am also a co-author of this draft and I think it is in a good shape to
advance. Besides that, I believe the publication of the reference model is
an important step for the WG.
Best.
Jéferson

Em ter, 9 de jan de 2018 às 19:32, Brian E Carpenter <
brian.e.carpen...@gmail.com> escreveu:

> Hi,
>
> I am a co-author of this draft. I do believe that it is ready to advance,
> and that it's useful to get it published soon so that it can indeed act as
> a reference model. We know that a second edition will probably be needed to
> include future work.
>
> (At least one minor correction is pending in the XML source:
> https://github.com/mbehring/ANIMA-Reference-Model/commit/163999c1d03599 )
>
> Regards
>Brian Carpenter
>
> On 09/01/2018 19:26, Sheng Jiang wrote:
> > Hi all,
> >
> > This message starts the two-week ANIMA Working Group Last Call to
> advance draft-ietf-anima-reference-model-05, A Reference Model for
> Autonomic Networking. This document's intended status is Informational. At
> present, there is no IPR file against this document.
> >
> > Please send your comments by January 22nd, 2018. If you do not feel this
> document should advance, please state your reasons why.
> >
> > Sheng JIANG is the assigned document shepherd.
> >
> > Regards,
> >
> > Sheng (co-chair, Toerless who as a co-author stayed neutral on the
> content side)
> >
> >
> >
> >
> > ___
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec. 12, 2017

[Jéferson Campos Nobre]

Dear ANIMA.
I read and support the adoption of this document.
Best.
Jéferson

Em qui, 7 de dez de 2017 07:07, Michael H. Behringer <
michael.h.behrin...@gmail.com> escreveu:

> I also support the adoption of this document.
>
> Michael
>
> On 29/11/2017 6:35 AM, Sheng Jiang wrote:
> > During the IETF100, there was a consensus that draft-liu-anima-grasp-api
> > is fully consistent with the current ANIMA charter, under the condition
> > it intends to be an Informational document. After the meeting, the
> > authors have updated the document. The current intended status is
> > Informational. There was an adoption call on this document as a ANIMA
> > working group document in the ANIMA session, IETF100. There were
> > supports and no objection as far as chairs heard. As an official
> > procedure, we now confirm the adoption in the ANIMA mailing list. This
> > message starts a two-week adoption call on draft-liu-anima-grasp-api.
> >
> >
> >
> >   Title:  Generic Autonomic Signaling Protocol Application Program
> > Interface (GRASP API)
> >
> >   Authors :   Liu, et al.
> >
> >   Filename:   draft-liu-anima-grasp-api
> >
> >   https://tools.ietf.org/html/draft-liu-anima-grasp-api-06
> >
> >
> >
> > Please express your support or rejection. If you think this document
> > should _not_ be adopted, please also explicitly indicate the reasons.
> >
> >
> >
> > This adoption call will end on December 12, 2017.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Sheng + Toerless
> >
> >
> >
> >
> >
> > ___
> > Anima mailing list
> > Anima@ietf.org 
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
> --
>
> Dr. J.W. Atwood, Eng. tel:   +1 (514) 848-2424 x3046
> Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
> Department of Computer Science
> and Software Engineering
> Concordia University EV 3.185 email:william.atw...@concordia.ca
> 1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
> 
> Montreal, Quebec Canada H3G 1M8
>
>
> References:
>
>   * [Anima] Adoption call for draft-liu-anima-grasp-api-06, ends Dec.
> 12, 2017
> <
> https://mailarchive.ietf.org/arch/msg/anima/zjl6w5PUysz-ZtZKQFU_Lu3dzDA>
> Sheng Jiang 
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Reference draft: New Security Considerations Section

[Jéferson Campos Nobre]

Hi.
I respectfully disagree on C.I.A. and re-play, but I can live with the
Michael's original text :) My changes are aimed at the style of the
described list.
Best.
Jéferson

Em qua, 18 de out de 2017 às 11:01, Artur Hecker 
escreveu:

> Hi
>
>
> Please find below some short additional comments, hopefully on time :-)
> Michael, these things are indeed a pain to formulate correctly, so please
> feel free to disregard, if it becomes too bulky.
>
>
> > Somehow I was afraid someone would say this. :-(  It's not easy to
> explain, in simple terms...
> >
> > How does this sound:
> >
> > "In an outsider attack all network elements and protocols are securely
> managed and
> > operating, and an outside attacker can sniff packets in transit, inject
> and replay packets.
> > In an insider attack, the attacker has access to an autonomic node, or
> can insert packets
> > directly into the protected ACP."
>
> [[AH] ] Minor point: as an attack is a practical instantiation of
> potential threats exploiting some vulnerabilities, I believe that what we
> describe here is better called a "threat model". We can still call those
> presumed actors "inside attacker" and "outside attacker" respectively, both
> being "threat agents", but I wouldn't talk about "inside attack".
> (Rationale: a specific attack could be an arbitrary combination of all
> these.)
>
> Besides, I would suggest addition of "destroy/suppress packets", to fully
> cover MitM capabilities of an "on the wire" attacker.
>
> For the second phrase, I would add something like: "<...> access to an
> autonomic node or any other means (e.g. remote code execution in the node
> by exploiting ACP-independent vulnerabilities in the node platform) that
> would allow the attacker to produce arbitrary payloads of the protected ACP
> channels".
>
> Finally, probably it would be good to categorize these "arbitrary
> payloads": if the inside attackers only produce some twisted packets and
> wrong syntax, we can discover them by sanity checks of ACP related
> protocols. But for more complex scenarios, we would seem to need
> behavioural node analysis or majority votes, etc., which imo still have too
> many false positives / negatives. I guess we cannot require TC/TPM with
> remote attestation? Especially, because all this is somehow orthogonal to
> ANIMA...
>
>
> >>o  protected against modification.
> >>
> >>o  authenticated.
> >>
> >>o  protected against replay attacks.
> >>
> >>o  encrypted."
> >> - I'd rather be consistent using "protection on Confidentiality,
> >> Integrity, Availability, and Non-repudiation".
>
> > That's not the same :-)  You don't cover re-play attacks.
>
> [[AH] ] I would agree with Michael here. C.I.A. refers to data protection,
> we talk about a protocol. I would even add MitM specifically in the list
> above, as it very probably will be the first choice... (See KRACK).
>
>
> Greetings
> artur
>
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] Reference draft: New Security Considerations Section

[Jéferson Campos Nobre]

Hi Michael.
I think the security section looks good, but I have some comments, to
clarify some passages
My comments:

In Section 9:
"... transit, inject and replay packets "on the wire".  In an insider
   attack, the attacker has access to an autonomic node, or can insert
   packets directly into the ACP."
- I understand the difference between "on the wire" and "directly into the
ACP", but I think this should be better explained.

In Section 9.1:
"...as well as mechanisms specific to
   an autonomic network (such as a secured MASA server)."
- I believe "secured MASA server" can be replaced by "MASA service".

 "AN specific protocols and methods must also follow traditional
   security methods, in that all packets that can be sniffed or injected
   by an outside attacker are:

   o  protected against modification.

   o  authenticated.

   o  protected against replay attacks.

   o  encrypted."
- I'd rather be consistent using "protection on Confidentiality, Integrity,
Availability, and Non-repudiation".

  "Most AN messages run inside the cryptographically protected ACP.  The
   not protected AN messages outside the ACP are limited to a simple
   discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]:
   The "Discovery Unsolicited Link-Local (DULL)" message, with detailed
   rules on its usage."
- Since it is a important exception, I think the usage rules should be
replicated here instead of just using a reference to the GRASP I-D.

Cheers.
Jéferson

Em qui, 12 de out de 2017 às 06:23, Michael H. Behringer <
michael.h.behrin...@gmail.com> escreveu:

> As mentioned before, the Security Considerations section needed work. I
> have now restructured and to a large extent re-written that section.
>
> The main focus is on the fact that while AN is auto-protecting, in the
> case of a vulnerability, protocol design error, operational error, the
> attack surface is huge.
>
> All, especially co-authors: Please read the new section and comment!
>
> Right now only on github:
>
> https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.txt
>
> Other than that:
> - on sections 7.6 and 7.7 I'm waiting for feedback from John.
> - otherwise, to my knowledge, all other input received has been taken
> into account.
>
> Once 7.6, 7.7 and the security considerations are stable, I'll push a
> new version. Co-authors: Comment now! :-)
>
> Michael
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] What is intent ?

[Jéferson Campos Nobre]

Hi.
The current wording in draft-du-anima-an-intent is "ANIMA Intent Policy".
This sounds a little repetitive, but it highlights the problematic nature
of intent in ANIMA.
I'm not sure if only parameters can be enough, but it is also depends on
the definition of "parameters"... Maybe some form of policies (for example,
ECA rules) can be included in the discussion. In any case, I believe this
could be addressed in draft-du-anima-an-intent.
I agree with Brian, the intent "philosophical" discussion fits better the
NMRG. BTW, there is a discussion about it in Prague and this could lead to
a new NMRG workshop (like the autonomic ones).
Best.
Jéferson

Em ter, 25 de jul de 2017 às 20:04, Brian E Carpenter <
brian.e.carpen...@gmail.com> escreveu:

> Distribution trimmed to Anima:
>
> Whenever I've asked "Is X Intent?", I've usually been told "No" except for
> cases where X is too abstract to interpret algorithmically.
>
> But in practice, I believe that many ASAs will need instructions from
> the NOC to modify their default behaviour. I don't care what we call
> those instructions; for the prefix management use case we just called
> them "parameters".
>
> So maybe Anima should focus on parameter distribution more than on
> Intent. I think that's the point of draft-liu-anima-grasp-distribution.
> A fairly simple change to the wording of draft-du-anima-an-intent
> would adapt it to generic parameter distribution.
>
> Converting abstract Intent to concrete parameters can be completely
> separate from this, and could well be a centralised operation.
>
> Or we could spend another 6 months discussing how to know Intent
> when we see it. But I would prefer that to happen in NMRG.
>
> Regards
>Brian
>
> On 26/07/2017 08:34, Toerless Eckert wrote:
> > I have an autonomic network, and i want for another customer another
> > L3VPN service instance in it.  How would i tell the network that i want
> > this ? Via intent or via something else ?
> >
> > If it is something else, what is it ? I do not see any other information
> flow from
> > operator to network beside intent in RFC7575 or
> draft-ietf-anima-reference-model.
> > Maybe i am missing something.
> >
> > If it is intent, how would it look like ? Could it simply be a definition
> > of an L3VPN service instance in the model defined in rfc8049 ? If not,
> why not ?
> >
> > IMHO: Intent in ANIMA includes service definitions such as what rfc8049
> is,
> > except that we would reserve the right to eliminate all parameters of
> rfc8049
> > for which we figure out autonomic ways to determine them. Which alas
> seems to
> > be quite difficult for most parameters.
> >
> > Other folks in the IETF clearly think that a service definition is NOT
> intent,
> > but intent can only be some yet unclear high level policy. If thats the
> > prevailing opinion/wisdom in the IETF, then IMHO we need to be more
> explicit about the
> > fact that Intent is not the only input into the network but that there is
> > also other input. Such as services. And anything else that people do not
> want to
> > call Intent.
> >
> > Lets assume service and other necessary data operator->network should not
> > be called intent. But lets say the superset of intent + services +
> everything
> > else is called eg: "information". I think that draft-du-anima-an-intent
> > would equally apply to all information we would want to distribute into
> > an autonomic network.
> >
> > Cheers
> > Toerless
> >
> > ___
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima
> >
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] New release of Python3 GRASP prototype

[Jéferson Campos Nobre]

Hi Brian.
I don't have my flight ticket yet, but I hope to join you at the Hackathon
on Sunday.
Cheers.
Jéferson

Em qui, 2 de fev de 2017 às 17:12, Brian E Carpenter <
brian.e.carpen...@gmail.com> escreveu:

> Hi,
>
> I've uploaded a new release of the Python3 GRASP prototype and
> demonstration ASAs
> to https://www.cs.auckland.ac.nz/~brian/graspy/.
>
> These use an updated version of the GRASP API (with numeric error codes
> instead
> of English-language strings) so they are *incompatible* with all earlier
> releases. There will be new versions of draft-liu-anima-grasp-api and
> draft-carpenter-anima-ani-objectives soon, and the Python code is intended
> to correspond to these drafts.
>
> And -- who wants to play at a GRASP hackathon in Chicago, and who has
> some code to bring along?
>
> Regards
>Brian
>
>
> ___
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima