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

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Mar 2016 01:05:57 -0800

I have several times suggested that the GRASP text needs the notion of an "instance".
Ther MUST be a "secure/ACP" instance, meaning that any information that an agent
passes into this "instance" MUST be guaranteed by GRAP to be only passed on across
other ACP links. That IMHO is the core instance of GRASP we need in ANIMA.

There are a lot of reasons for addition instances that hae other purposes. I menioned
in my last mail eg: an instance per L2 interface to help finding neighbors for the ACP.
Thats an example of insecure instances.

What would be an example of sending a ot of traffic via GRASP ? Eg: WOuld i
try to send a router-firmware-upgrade via GRASP ? ;-))

If i need to do that, then i could see how extensions to GRASP could transparently
and securely use the data-plane:

-> GRASP wants p2p communication with a remote neighbor. It also knows
   it needs throughput:
-> It needs to use the secure/ACP instance of GRAP to learn of that peer
   a) data-plane address (IPv6/IPv4)
   b) ACP cert.
-> It can then optimize communication by setting up an SSL data plane 
   connection to that peer.

If we have a clear use-case, we could investigate this further. Remember
that two AN devices that can talk to each other via ACP may not be able
to talkk to each other via data plane, eg: there could be NAT, VRFs etc. pp.
be in the way.

If the GARP p2p connection is TCP/SCTP, then we could also do the
switchover not in the GARP layer, but inside of MP-TCP/SCTP. These
protocols would aleviate the need to exchange the cert because they
do exchange (if i recall correctly) some challenge token across
the established connection (ACP), that they then use to setup another
connection - eg: via data-plane.

I do describe the MP-TCP/SCTP idea in the stable connectivity draft.
The main complexity would be that we would want "auto-security" so
the additional path across data-plane would have to have an auttomatically
build security association underneath. Eg: dTLS. I have to ask some
transport folks if there has already been any work in this direction.

To summarize and divide and conquer:
- GRASP should have a notion of non-conflicting instances.
  GRP messages received are associated to an instance based on
  how they are received from. Eg: received with the primary defined
  encap across ACP: assigned to ACP instance.

- For ANIMA we need to define appropriately in GRASP and/or another draft
  that our primary GRASP instance is a Secure/ACP one, where all
  connections are across ACP so agents know that when sending/receiving
  GRASP messages into/from this instance it is secure.

- Everything else is cool, but secondary.

Cheers
    Toerless

On Fri, Feb 05, 2016 at 08:06:03AM +1300, Brian E Carpenter wrote:
> 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.
> > 
> > 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)
> 
> 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.
> 
> > 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). 
> 
> 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
> 
> > 
> > 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?
> >>
> >>    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
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/anima
> > 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
Toerless Eckert, [email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Mar 2016 13:25:58 -0800

On Thu, Mar 03, 2016 at 08:11:28AM +1300, Brian E Carpenter wrote:
> I have been thinking of that as a *mode* not an instance, i.e. the GRASP engine
> comes up by default in "insecure" mode which restricts the operations it will
> accept, and then either changes to "ACP" mode when it determines that the ACP is up,
> or to "TLS" mode if there is no ACP but there is a certificate infrastructure.
> 
> It's probably correct that we need to tag individual interfaces as "insecure"
> rather than assuming all interfaces are the same.

If i run just GRASP across an interface insecure to discover candidate ACP
neighbors, that is signaling that has nothing to do with the GRASP running
inside the ACP, and "instance" to me is the best expression to indicate that there
should be no interaction between them.

> Why is that GRASP? Surely it will be an individual ASA that wants such
> communication with another ASA?

I don't know if GRASP should or would be used for sessions requring a  good
amount of bandwidth. When HTTP was invented i think it too was seen unlikely
that you'd end up transporting every type of big data across it.

> Indeed. But does GRASP have any advantage for that over plain TLS?
> I don't understand the advantage of that to the ASAs.

Right. See above Nothing GRASP specific here. Just: IF some protocol
between ASAs wants to transfer a lot of data, it would be good if that
would automatically use the data plane - if data plane is available. And
my description was just explaining how.

> If they don't conflict, they are either in totally orthogonal
> address spaces, or on totally orthogonal interfaces, or use
> a different LL multicast address and well-known port. (Or we
> add a network-wide instance identifier to the protocol, which
> seems like a horrible idea.)

Exactly. Thats what i call "instance" ;-)

Cheeers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2016 13:03:52 +1300

> Exactly. Thats what i call "instance" ;-)

So, I'm thinking that any text about this belongs in the Reference Model
draft, not in the protocol spec.

    Brian