Subject: [Anima] Addressing ASAs or nodes?

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2015 13:18:55 +1200

While doing some thinking in the context of the signaling
design team, I came upon another addressing question.

A single physical node might contain several independent
autonomic service agents (ASAs) handling different resources.

Will those ASAs all use the same layer 3 address, or will
they have an address each?

This matters for the signaling design, because if they all
have the same address, it isn't clear how they could share
a listen port. At the least, it creates a complicated
demultiplexing requirement. (We have that anyway for
incoming discovery messages, but they are distinguished by
an 'objective' parameter.)

draft-behringer-anima-autonomic-addressing-00 describes one
address per node, as far as I can tell.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 15 May 2015 02:34:13 +0000

In my opinion, addressing per ASA would be ideal. But it is too ideal to be taken as a common assumption. The signaling should be able to support the scenario that ASAs share the same layer 3 address. One address per ASA could be considered as a subset of it. I personally believe the current design has already support this.

Sheng

>-----Original Message-----
>From: Anima [mailto:[email-masked]] On Behalf Of Brian E
>Carpenter
>Sent: Friday, May 15, 2015 9:19 AM
>To: Anima WG
>Subject: [Anima] Addressing ASAs or nodes?
>
>_______________________________________________
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Fri, 15 May 2015 00:30:27 -0300

Hi.
I think that all ASAs must use the same layer 3 address.
As a demux approach, a valid analogy is the presence of multiple SNMP
agents in a node. Thus, something like the
contextEngineID/snmpEngineID could be used.
Best.

Jéferson Campos Nobre
PhD Student
Computer Networks Group -  Institute of Informatics
Federal University of Rio Grande do Sul
http://www.inf.ufrgs.br/~jcnobre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2015 15:35:54 +1200

> contextEngineID/snmpEngineID could be used.

Actually we have a SessionID in the GDNP design. I will have to check,
but I think that occurs in all cases where we would need to demultiplex.
As long as it is allocated uniquely per-node (rather than per-ASA), that
would be enough.

   Brian

---

From: John Strassner <[email-masked]>
Date: Sat, 16 May 2015 11:38:37 -0700

I agree with Sheng. In general, agents should be at least semi-autonomous,
as they will have different purposes and targets. Therefore, they should
have the freedom to use their own unique address.

regards,
John

On Thu, May 14, 2015 at 8:35 PM, Brian E Carpenter <
[email-masked]> wrote:

> >> In my opinion, addressing per ASA would be ideal. But it is too ideal
> to be taken as a common assumption. The signaling should be able to support
> the scenario that ASAs share the same layer 3 address. One address per ASA
> could be considered as a subset of it. I personally believe the current
> design has already support this.
> >>
> >> Sheng
> >>

-- 
regards,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 May 2015 07:50:02 +1200

> have the freedom to use their own unique address.

Certainly we shouldn't have any arbitrary restrictions. It does interact
with the authentication mechanisms, though. Does an ASA inherit its trust
from the device, and how does that work if there are several ASAs with
different addresses in the same device?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 May 2015 08:08:05 +1200

OK, answering half of my own quetion...
> different addresses in the same device?

While working on the next update of the signaling protocol, I reached a firm
conclusion that an ASA needs to inherit the trust credentials of the device
that contains it. Otherwise each ASA would have to go through the trust
bootstrap process for itself, and that seems like a perverse requirement.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 18 May 2015 01:17:08 +0000

>bootstrap process for itself, and that seems like a perverse requirement.

I agree that the above inheriting of the trust credential from the device to ASA should be default behavior. Furthermore, I still believe only one security level is NOT enough. Some specific ASAs may have higher requirements for itself. They should be allowed to have their own authentication on the top of the default trust credential.

Best regards,

Sheng

>>>>> On Thu, May 14, 2015 at 11:34 PM, Sheng Jiang
><[email-masked]>
>>>> wrote:

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 18 May 2015 08:39:34 +0000

Hi Brian, Sheng,

> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Monday, May 18, 2015 9:17 AM
> To: Brian E Carpenter; John Strassner
> Cc: Jéferson Campos Nobre; Anima WG
> Subject: Re: [Anima] Addressing ASAs or nodes?
> 
> >> Certainly we shouldn't have any arbitrary restrictions. It does
> >> interact with the authentication mechanisms, though. Does an ASA
> >> inherit its trust from the device, and how does that work if there
> >> are several ASAs with different addresses in the same device?
> >
> >While working on the next update of the signaling protocol, I reached a
> >firm conclusion that an ASA needs to inherit the trust credentials of
> >the device that contains it. Otherwise each ASA would have to go
> >through the trust bootstrap process for itself, and that seems like a
> perverse requirement.
> I agree that the above inheriting of the trust credential from the device to
> ASA should be default behavior. Furthermore, I still believe only one security
> level is NOT enough. Some specific ASAs may have higher requirements for
> itself. They should be allowed to have their own authentication on the top of
> the default trust credential.

[Bing] I also agree:
1. an ASA needs to inherit the trust credentials of the device that contains 
2. ASAs might have their own authentication on the top of the secure channel based on the trust credential

But I guess you didn't implicitly mean ASAs need dedicated IP addresses due to the above reasons, right? 
My understanding is that the trust credential and the ASA authentication do not necessarily rely on IP addresses.

Best regards,
Bing

> >>>>> As a demux approach, a valid analogy is the presence of multiple
> >>>>> SNMP agents in a node. Thus, something like the
> >>>> Actually we have a SessionID in the GDNP design. I will have to
> >>>> check, but I think that occurs in all cases where we would need to
> demultiplex.
> >>>> As long as it is allocated uniquely per-node (rather than per-ASA),
> >>>> that would be enough.
> >>>>
> >>>>    Brian
> >>>>
> >>>>> Best.
> >>>>>
> >>>>> Jéferson Campos Nobre
> >>>>> PhD Student
> >>>>> Computer Networks Group -  Institute of Informatics Federal
> >>>>> University of Rio Grande do Sul http://www.inf.ufrgs.br/~jcnobre
> >>>>>
> >>>> the scenario that ASAs share the same layer 3 address. One address
> >>>> per
> >ASA
> >>>> could be considered as a subset of it. I personally believe the
> >>>> current design has already support this.
> >>>>>>
> >>>>>> Sheng
> >>>>>>
> >>>>>>> While doing some thinking in the context of the signaling design
> >>>>>>> team, I came upon another addressing question.
> >>>>>>>
> >>>>>>> Will those ASAs all use the same layer 3 address, or will they
> >>>>>>> have an address each?
> >>>>>>>
> >>>>>>> This matters for the signaling design, because if they all have
> >>>>>>> the same address, it isn't clear how they could share a listen
> >>>>>>> port. At the least, it creates a complicated demultiplexing
> >>>>>>> requirement. (We have that anyway for incoming discovery
> >>>>>>> messages, but they are distinguished by an 'objective'
> >>>>>>> parameter.)
> >>>>>>>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 18 May 2015 12:54:33 +0000

> Sent: 17 May 2015 22:08
> To: John Strassner
> Cc: Jéferson Campos Nobre; Anima WG; Sheng Jiang
[...]
> bootstrap process for itself, and that seems like a perverse requirement.

We've been chewing on this for a long time as well. You need to de-mux the ASAs that are hosted on an autonomic node. The protocols should be able to provide that demux function, and I think that's more elegant than demuxing with ip address space... So I would also suggest: One IP address for an autonomic node, some instance ID for an ASA. However, this instance ID needs to be consistent across the protocols the ASAs use. 

Regarding the security level, I would argue that the ANI sets and automatically enforces a default security level, which has certain properties. If there are specific ASAs that require higher-than-normal security standards, then they could still use for example an additional security layer, specifically between ASAs with those requirements. Certainly for commercial products we should be able to have a "good enough" security level by default. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 May 2015 08:38:39 +1200

Hi Michael,

On 19/05/2015 00:54, Michael Behringer (mbehring) wrote:
> We've been chewing on this for a long time as well. You need to de-mux the ASAs that are hosted on an autonomic node. The protocols should be able to provide that demux function, and I think that's more elegant than demuxing with ip address space... 

We can consider this in the signaling DT, but GDNP currently assumes you
can demux on the Objective ID (to get the correct ASA) and then on a Session ID
(to get the correct thread within the ASA).

This doesn't exclude using separate IP addresses but I agree they should
not be a requirement.

> So I would also suggest: One IP address for an autonomic node, some instance ID for an ASA. However, this instance ID needs to be consistent across the protocols the ASAs use. 

Using the Objective ID should satisfy this. But if we need to add an
ASA instance ID, that would be quite easy.

> Regarding the security level, I would argue that the ANI sets and automatically enforces a default security level, which has certain properties. If there are specific ASAs that require higher-than-…

Agreed. We might even have cases of lower-than-normal security, who knows?
(Note however that SNMPv3 took a different approach by going for its own
security solution.)

    Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 18 May 2015 22:02:15 +0000

> I agree that the above inheriting of the trust credential from the device to ASA should be default behavior. Furthermore, I still believe only one security level is NOT enough. Some specific ASAs m…

Secure bootstrapping requires an initial credential but I’d be open to the idea that the existing credential could be either the initial device credential or a locally issued device credential. Enrollment protocols should support “higher requirements” such as two factor authentication. Also it makes sense for the existing credential to be used to obtain a limited use (one time?) token that can be used for an enrollment. This provides methods for virtualized ASA’s to “inherit” the existing credential w/o expecting to provide the necessary interfaces to use the device credential in real time during the enrollment. 

- max

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 19 May 2015 06:55:01 +0000

> (Note however that SNMPv3 took a different approach by going for its own

If we do our job in the ANI so nicely with security, people won't see a need for protocol specific security, such as SNMPv3. However, this will only happen if the ANI guarantees security. This is why I'm hesitant about "downgrading" security. 

Lots of exceptions to take care of for now though, for example, mixed AN/non-AN environments. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 08:01:26 +1200

Hi Michael,

> If we do our job in the ANI so nicely with security, people won't see a need for protocol specific security, such as SNMPv3. However, this will only happen if the ANI guarantees security. This is w…

Indeed. It would have to be very careful. One possible case would be if
two operators wanted to allow AN across their mutual boundary, for a certain
purpose only.

> Lots of exceptions to take care of for now though, for example, mixed AN/non-AN environments. 

Indeed. That can create weak points.

For now perhaps these issues belong in the security section of the reference model?

    Brian

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Tue, 19 May 2015 17:37:34 -0300

Hi Max.

> Secure bootstrapping requires an initial credential but I’d be open to the idea that the existing credential could be either the initial device credential or a locally issued device credential. Enr…

Just to add up: I think the use of temporary ID should be also used to
avoid eavesdropping.

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Tue, 19 May 2015 17:38:09 -0300

Hi Brian.

> two operators wanted to allow AN across their mutual boundary, for a certain

I think this is the right approach: what are the cases for
"downgrading security"?  I am also hesitant about this.

> For now perhaps these issues belong in the security section of the reference model?

+1

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 12:41:48 +1200

Hi,
> "downgrading security"?  I am also hesitant about this.

In my example, ASA1 in ISP1 needs a 1:1 trust relationship with
ASA2 in ISP2, and that is quite distinct from the mutual trust
between all ASAs inside a single ISP.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 20 May 2015 01:52:23 +0000

>>>> If we do our job in the ANI so nicely with security, people won't see a
>need for protocol specific security, such as SNMPv3. However, this will only
>happen if the ANI guarantees security. This is why I'm hesitant about
>"downgrading" security.
>>>

I don't think we properly explore the area regarding to domain at all. Up to now, we have an assumption that when we talk about autonomic node, it belongs to one and only one default autonomic network domain. This would be a reasonable start point since we could solve all complex issues from the very beginning. However, rigid single domain is certainly not enough to handle these complicated real requirements. So, multiple domain and domain-relevant operation is really worth of deep exploring.

Regards,

Sheng

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 14:20:45 +1200

Hi Sheng,

> I don't think we properly explore the area regarding to domain at all. Up to now, we have an assumption that when we talk about autonomic node, it belongs to one and only one default autonomic netw…

Agreed. I suppose it is out of WG charter scope at the moment,
but we need to be sure that we do not block these possibilities
in the initial design.

   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 20 May 2015 03:27:59 +0000

>>>>>>> (Note however that SNMPv3 took a different approach by going for
>its
>>> own
>>>>>>> security solution.)
>>>>>>
>> I don't think we properly explore the area regarding to domain at all. Up to
>now, we have an assumption that when we talk about autonomic node, it
>belongs to one and only one default autonomic network domain. This would
>be a reasonable start point since we could solve all complex issues from the
>very beginning. However, rigid single domain is certainly not enough to handle
>these complicated real requirements. So, multiple domain and
>domain-relevant operation is really worth of deep exploring.
>

I believe it is in the WG scope, but not in the current charter as work items. We would be possible to add it into next charter, if people are willing to work on it. Your concern "not block these possibilities in the initial design" is certainly valuable.

Regards,

Sheng

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 20 May 2015 12:49:49 +0000

Hi Max,

> Secure bootstrapping requires an initial credential but I'd be open to the
> idea that the existing credential could be either the initial device credential
> or a locally issued device credential. 
[Bing] If we use locally issued device credential, then how to assure the local procedure to be secure?

> Enrollment protocols should support
> "higher requirements" such as two factor authentication. Also it makes
> sense for the existing credential to be used to obtain a limited use (one time?)
> token that can be used for an enrollment. This provides methods for
> virtualized ASA's to "inherit" the existing credential w/o expecting to
> provide the necessary interfaces to use the device credential in real time
> during the enrollment.
[Bing] This consideration makes a lot sense. It might be a bit too vulnerable to let the ASAs directly use the credential. So tokenization might even be a requirement for ASAs inheriting the credential? 

Best regards,
Bing

> >>>>> As long as it is allocated uniquely per-node (rather than
> >>>>> per-ASA), that would be enough.
> >>>>>
> >>>>>   Brian
> >>>>>
> >>>>>> Best.
> >>>>>>
> >>>>>> Jéferson Campos Nobre
> >>>>>> PhD Student
> >>>>> to be taken as a common assumption. The signaling should be able
> >>>>> to
> >> support
> >>>>>>>> From: Anima [mailto:[email-masked]] On Behalf Of Brian
> >>>>>>>> E Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 May 2015 17:23:57 +1200

> I believe it is in the WG scope, but not in the current charter as work items. We would be possible to add it into next charter, if people are willing to work on it. Your concern "not block these p…

Indeed. What is a bit complicated is that it seems we will need partly
overlapping trust domains. In the present protocol design we have no way
to express that, but it would be quite easy to add a domain-related
option to the messages later, if necessary.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 21 May 2015 06:01:58 +0000

> >> Indeed. It would have to be very careful. One possible case would be
> >> if two operators wanted to allow AN across their mutual boundary, for
> >> a certain purpose only.
> >
> ASA2 in ISP2, and that is quite distinct from the mutual trust between all
> ASAs inside a single ISP.

Brian, 

This is not too difficult, we can make this work quite easily. 
- if two nodes are in the same domain, they use a default security model (which I still insist should be high)
- if they are in different domains, two sub cases:   
  + common trust anchor (ie, sub-domains)
  + no common trust anchor

If no common trust anchor, they have to exchange root certs in some way. Then, in all cases, the nodes can authenticate each other. 
For authorization, in the two cases with different domains, intent says what to do. 

Concrete example: 
Intent in SP 1: "Trust BGP speakers from SP 2 with root cert x for: BGP authentication. No ACP, nothing else". 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2015 08:09:16 +1200

Hi Michael,
> Intent in SP 1: "Trust BGP speakers from SP 2 with root cert x for: BGP authentication. No ACP, nothing else". 

I agree, conceptually it is very possible. Would you engineer this as an
extension to the ACP model? How do you think the writer of an ASA would
see this, a special security API?

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 May 2015 10:57:14 -0400

> need for protocol specific security, such as SNMPv3. However, this will
    > only happen if the ANI guarantees security. This is why I'm hesitant
    > about "downgrading" security.

ANI = Autonomic Network Infrastructure?

I don't see how IP-layer security (as we normally practice it) can provide
for role-based access control into the "routers".   Sure, we could provide
5-tuple based IPsec or TLS security that would permit roles to be
communicated, but that seems like a big stretch.

Maybe I mis-understand.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 May 2015 11:03:25 -0400

> I don't think we properly explore the area regarding to domain at
    > all. Up to now, we have an assumption that when we talk about autonomic
    > node, it belongs to one and only one default autonomic network
    > domain. This would be a reasonable start point since we could solve all
    > complex issues from the very beginning. However, rigid single domain is
    > certainly not enough to handle these complicated real requirements. So,
    > multiple domain and domain-relevant operation is really worth of deep
    > exploring.

I think that the AN gives us a number of important things that can be
*leveraged* to provide ISP1<->ASA2.
  1) ISP1 and ISP2 now have a domain.
     (we might want to consider interactions, aka "bridge CA"s into the SIDR
     space...)

  2) all the devices in ISP1 and ISP2's domains all have locally relevant
     identities.

So, ISP1 and ISP2 don't need to try to trust Verisign or
self-signed-certificate#4 (with all the legal and operations issues
involved), they can now much more easily write a bilateral trust agreement.
So ASA2 can be explicitely configured as to what it authorizes ISP1
to do to it.  Perhaps that can be autonomically configured if some higher
level intent says, "cooperate with ISP1, including providing ISP1 with
FOOBAR access", then the the FOOBAR authorization could be configured
autonomically on the machine(s) that are providing the FOOBAR service.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 May 2015 09:00:03 +1200

> autonomically on the machine(s) that are providing the FOOBAR service.

Let me equate FOOBAR with an Anima objective (i.e. a specific parameter
that we are trying to manage, where the parameter could be single-valued
or a more complex data structure). Then yes, my idea is that trust and
authorization should be possible at that granularity. This might be
bundled up rather like an Android app: An ASA, when it joins a domain,
says "I want to be trusted for the following list of objectives:....".

Then the bilateral trust agreement would be manifested as a special
domain with a very restricted set of available objectives.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 25 May 2015 16:15:02 +0000

> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 23 May 2015 16:57
> To: Anima WG
> Cc: Michael Behringer (mbehring)

Yes. Sorry for the acronym... 
 
> communicated, but that seems like a big stretch.

Not sure we're on the same page either, so let me expand: 

The Autonomic Control Plane (ACP) gives you by default protection against "the outside", the channels are encrypted and the messages are authenticated as coming from a node from the same trust group. 

Roles come into play in two flavours here: 
- SSH / telnet / etc access to devices, with AAA allows for role based authorization. This is for the "things" accessing nodes. 
- Nodes themselves can have a role, which can be attested in their certificate. Autonomic functions can therefore be limited to nodes with certain roles. 

Does this shoot in the right direction? 
Michael

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 25 May 2015 16:30:28 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 21 May 2015 22:09
> To: Michael Behringer (mbehring); Jéferson Campos Nobre
> Cc: John Strassner; Anima WG; Sheng Jiang
> >> need for protocol specific security, such as SNMPv3. However, this
> >> will only happen if the ANI guarantees security. This is why I'm
> >> hesitant about "downgrading" security.
> >>>>
> >>>> Indeed. It would have to be very careful. One possible case would
> >>>> be if two operators wanted to allow AN across their mutual
> >>>> boundary, for a certain purpose only.
> >>>
> > If no common trust anchor, they have to exchange root certs in some way.
> Then, in all cases, the nodes can authenticate each other.
> extension to the ACP model? 

No. The ACP is only one way autonomic nodes interact. Inside a trusted domain it's the default mode. 

Nodes negotiate something I would call "interaction schemata". This could be a collection of protocols and security mechanisms associated with a type of "peering" between nodes. The simplest one is to bring up the ACP. 

For example, an SP PE router could have a specific schema for that peering type. It could bring up some default routing, secure it automatically, possibly assign address space to the CE, etc. 

Intent says "with any node from domain x (say a customer), do: use authenticated OSPF, bring into VPN of <customer>, SLA tracking template <x>".  (note you need the trust anchor from <customer> for this to work). 

> How do you think the writer of an ASA would

An ASA needs to "understand" its role in the system, and be able to interpret intent. Likely, we'll provide the possibility to limit the capabilities of ASAs. 

Michael

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 May 2015 13:11:09 -0400

> domain with a very restricted set of available objectives.

Let me turn FOOBAR service a concrete example, so that I'm sure that I
know what kinds of things you are talking about.

Let's say ISPA and ISPB have a peering.  They run DIFFSERV...
Let FOOBAR == service that transforms high-level signed SLA statement
into DSCP.   So, ISPA needs to discover that ISPB runs the FOOBAR service
for peering point X, on device Y.
This is why ISP1 needs to interact with the FOOBAR service on ISP2.

Brian, Is this the kind of thing that you are thinking about?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 08:31:06 +1200

> Brian, Is this the kind of thing that you are thinking about?

I would dig a couple of millimetres deeper and suggest that FOOBAR
as a technical objective would be a mapping of SLA parameters
into a set of diffserv code points. So it would actually be a
data structure  mapping items like 'jitter<100' into 'EF' (that's
still over-simplified, of course). So ASA1 would discover that ASA2
supports the FOOBAR objective, and could then negotiate jitter
targets etc and the corresponding DSCP values. And that reqires to
be mutually authorized in both domains.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2015 13:51:42 +1200

Back to this thread after a few days...

> No. The ACP is only one way autonomic nodes interact. Inside a trusted domain it's the default mode. 

OK, so we could for example assume that two ASAs in different admin domains
could communicate 1:1 via TLS, using a public CA. We still need to see
how authorization works in such a case.

> An ASA needs to "understand" its role in the system, and be able to interpret intent. Likely, we'll provide the possibility to limit the capabilities of ASAs. 

That can only be done by intent, I think, because that's supposed to
be the only source of human input.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 29 May 2015 13:59:33 +0000

> OK, so we could for example assume that two ASAs in different admin
> domains could communicate 1:1 via TLS, using a public CA. We still need to
> see how authorization works in such a case.

You still use the certs, but in this case you need to have the trust anchor of the other domain. 
 
> > Nodes negotiate something I would call "interaction schemata". This could
> be a collection of protocols and security mechanisms associated with a type
> of "peering" between nodes. The simplest one is to bring up the ACP.
> >
> > For example, an SP PE router could have a specific schema for that peering
> type. It could bring up some default routing, secure it automatically,
> possibly assign address space to the CE, etc.
> >
> > Intent says "with any node from domain x (say a customer), do: use
> authenticated OSPF, bring into VPN of <customer>, SLA tracking template
> <x>".  (note you need the trust anchor from <customer> for this to work).
> >
> >> How do you think the writer of an ASA would see this, a special
> >> security API?
> >
> > An ASA needs to "understand" its role in the system, and be able to
> interpret intent. Likely, we'll provide the possibility to limit the capabilities
> of ASAs.
> 
> That can only be done by intent, I think, because that's supposed to be the
> only source of human input.

The node *knows* it's an eBGP speaker, peering with AS x. This is self-knowledge. Intent will say "anyone peering with AS x: authenticate BGP autonomically".  I guess this is what you meant, just to be 100% clear. :-) 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2015 08:04:26 +1200

> The node *knows* it's an eBGP speaker, peering with AS x. This is self-knowledge. Intent will say "anyone peering with AS x: authenticate BGP autonomically".  I guess this is what you meant, just t…

Yes, exactly. (The intent "language" will need to be pretty flexible, I can see.)

   Brian