Subject: [Anima] GRASP Issue 42: ACP bypass?

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Feb 2016 13:48:30 +1300

o  42.  Do we need a feature whereby an ASA can bypass the ACP and
      use the data plane for efficiency/throughput?  This would require
      discovery to return non-ACP addresses and would evade ACP
      security.

Personal opinion: This is probably a bad idea. Trading security for
efficiency in network management seems like a mistake, even in
autonomic management.

WG input, please...

Regards
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 4 Feb 2016 17:47:34 +0000

Brian, 

I think you're asking the wrong question :-)   I believe we had come to the conclusion that an ASA is essentially just a piece of code, which can do anything it wants; specifically, we can't force it to use the ACP, it could also connect through the normal data plane to non-autonomic devices. The use case was that an autonomic agent on a physical device may well control other devices which are possibly non-autonomic. This transaction would not be inside the ACP (because the other device is non autonomic). So an ASA can have ACP based interactions, and non-ACP based interactions. 

I think there are different aspects to what you're saying: 

- GRASP should ONLY run in the ACP. (I think this is what you mean, really, and I think we agree on that)
- But GRASP can negotiate ANYTHING. In fact, one negotiation objective could be the IP address of the peer node in the data plane. Why not?

So the negotiation itself is in the ACP, the data exchanged may refer to something outside the ACP, and now *IF* you were to do a connection to that address, you wouldn't be protected by the ACP any more. 

But that's ok (in my opinion), as long as the context is explicit. I.e. the ASA *knows* it's dealing with something outside the ACP. I had proposed a long time ago a "context", which could then point to the data plane (or other virtual contexts). 

Michael

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 04 February 2016 01:49
> To: Anima WG <[email-masked]>
> Subject: [Anima] GRASP Issue 42: ACP bypass?
> 
> Personal opinion: This is probably a bad idea. Trading security for efficiency in
> network management seems like a mistake, even in autonomic
> management.
> 
> WG input, please...
> 
> Regards
>    Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Feb 2016 08:06:03 +1300

Hi Michael,

On 05/02/2016 06:47, Michael Behringer (mbehring) wrote:
> Brian, 
> 
> I think you're asking the wrong question :-) 

I suspect it wasn't my question originally ;-)

> I believe we had come to the conclusion that an ASA is essentially just a piece of code, which can do anything it wants;
specifically, we can't force it to use the ACP, it could also connect through the normal data plane to non-autonomic devices.
The use case was that an autonomic agent on a physical device may well control other devices which are possibly non-autonomic.
This transaction would not be inside the ACP (because the other device is non autonomic). So an ASA can have ACP based
interactions, and non-ACP based interactions.
> - GRASP should ONLY run in the ACP. (I think this is what you mean, really, and I think we agree on that)

Yes, or in a TLS wrapper in the absence of an ACP.

> - But GRASP can negotiate ANYTHING. In fact, one negotiation objective could be the IP address of the peer node in the data plane. Why not?

The IP address, or FQDN if you prefer. Certainly possible.

> But that's ok (in my opinion), as long as the context is explicit. I.e. the ASA *knows* it's dealing with something outside the ACP. I had proposed a long time ago a "context", which could then poi…

Right. What I think would be dangerous is for GRASP discovery to return an address which is
not secured, i.e. is not an ACP or TLS-wrappable address. That would allow an ASA to slide
gently from secure to insecure without knowing about it.

So I think this can be resolved by some text in the Security Considerations.

Thanks
   Brian