Subject: Re: [Anima-signaling] GRASP issue 49: More text about inter-domain GRASP

From: Brian E Carpenter <[email-masked]>
Date: Tue, 2 Aug 2016 13:39:35 +1200

Hi,

I came up with an idea of how to tackle this: state that any such inter-domain
operation MUST be a separate (D)TLS-based instance of GRASP that does not
share common data structures with the normal (ACP-based) instance.

    Brian
On 01/08/2016 09:11, Brian E Carpenter wrote:
> Hi,
> 
> Here's another issue for design team comments.
> 
>    o  49.  Section 3.3.1 should say more about signaling between two
>       autonomic networks/domains.
> 
> I need ideas about what to say.
> 
> Regards
>    Brian
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Aug 2016 04:50:54 -0700

Its really hard to define requirements when you don't know what the
communication should ultimately do.

So, for example:

In our Cisco implementation, we allow services to run on systems that
do not have ACP - just because its evolving work to get the ACP onto
such systems. Eg: TFTP servers, Radius Servers - or the like. SO there's
a leg of the ACP that's unencrypted. And the deployment requirement is
to physcially protect this segment - aka: router with ACP co-located with
those servers n a secure NOC room. And we use mDNS there.

The same setup would make sense to me to accelerate deployment also of
course with GRAP - instead of mDNS.

So, this is an example of expanding the secured insance of GRASP across
a segment thats not cryptographically (IPsec) but physically protected.

Now i could easily imagine that the next step would be to have multiple
disjoined autonomic networks, but a shared NOC. In that case, the
reason that we don't use encryption is not only "server systems suck, have no ACP",
but also: If a server should provide objectives (services) to multiple
autonomic networks, then we would need to solve how it could be cryptographically
part of multiple ACPs. Thats even more work.

If i take your text and would want to build a solution around it, then
i could think of some gateway-device thats part of two ACPs, and
has an ASA participating in each ACPs GRASP instance and is filtering/forwarding
objectives that should be allowed to be used across ACPs. Makes sense too...

Cheers
    Toerless

On Tue, Aug 02, 2016 at 01:39:35PM +1200, Brian E Carpenter wrote:
> _______________________________________________
> Anima-signaling mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-signaling

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 11:56:02 -0400

> those servers n a secure NOC room. And we use mDNS there.

I was under the impression that we'd make this secure either by physical
means (as you write), or by putting those services in containers or VMs, and
connect them to devices/routers that would have ACP on them.

    > part of multiple ACPs. Thats even more work.

I'm not sure it's that big a deal to be part of multiple ACPs.
Depends a lot upon the details of the service.

For some services build upon a multi-tier architecture (anything RESTful,
such as NETCONF...) then putting a front-end server into two ACPs while
connecting to middle-ware on a common back-end network would be trivial.

Ditto: Radius things, you can always add a layer of radius proxy.
TFTP servers... not a huge deal, just NFS mount /tftpboot across a backend
LAN from the real machine and have multiple TFTP servers in multiple ACPs.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 2 Aug 2016 09:05:22 -0700

> connect them to devices/routers that would have ACP on them.

Right. Those are the easily managed approaches.

> LAN from the real machine and have multiple TFTP servers in multiple ACPs.

Yes, there are a lot of different ways to do this, but i think they
all involve some additional SW design, which may be trivial, but needs to
be implemented, and i am not sure we have a sufficient strong use-case for
any specific optoin to mandate or even suggest any such extension right now -
as opposed to any other option.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Aug 2016 08:40:06 +1200

> communication should ultimately do.

Absolutely. And we shouldn't stretch the protocol spec to cover future
application scenarios that we don't understand. I'd rather limit what
we say to guaranteeing security properties.

> objectives that should be allowed to be used across ACPs. Makes sense too...

Yes. I keep coming back to my old love: diffserv and how to deploy it between
domains. I can see ASAs being deployed as inter-domain bandwidth brokers,
but interworking with intra-domain bandwidth brokers, exactly as you say.

Rgds,
   Brian