Subject: [sacm] Notes from Information Model Discussion

From: "Adam W. Montville" <[email-masked]>
Date: Thu, 24 Jul 2014 16:30:34 -0400

All:

This morning a few of us attempted a deeper dive on the “Ice Station Zebra” usage scenario to gain better understanding of the data that would be required between two SACM participants.  

Before getting into that, toward the end of the meeting we found ourselves asking what success looks like.  We seemed to generally agreed that success is getting the Control Plane, Data Plane, and essential configuration assessment items in place.  This would include information models needed for Control Plane administration/configuration and configuration assessment.

The following “things that we should do” and “things we need to discuss” are based on the “Frame Of Reference” bit below (thanks for sharing your notes Lisa!) and on notes I took.  If others have things to add or alter, please do so.

Some things that we should do:

Pick term, define it in terminology draft, use it - a comment was heard that we tend to switch around on terminology, so let’s try to pick one, document it, and stick with it.
We should work on security considerations for authentication and delegation of authentication
We should not preclude ecosystem possibilities, but we should be explicit about what we intend to standardize and what we intend to restrict (thus drawing a line between what we will do and what we will leave to be possible in the future).
Define taxonomy or functional taxonomy in the terminology document

Things we need to discuss:

We need to have a discussion about authorization.  There is authorization at the Control Plane level, but are there more granular authorizations for which we need to provide?  What provides that more granular authorization (i.e. Control Plane, Provider, delegate, something else)?
How do we define that we need a service to provide a taxonomy of, for example, enterprise-relevant tags?  We believe this should go into the architecture draft.
How can queries be filtered?  Concrete list, wildcard, metadata characteristics…  And, does the Provider do the filtering or the Proxy or…
One way to allow Providers to announce the availability of a functional taxonomy is to use a registry with some standard entries, but with extension guidance for unimagined functional taxonomies

<FrameOfReference>
Prior to participation, registration must occur.

Registration (station endpoint management system, university admin)
Each client publishes its capabilities (“I know this stuff”)
So far, no data about any assets has been exchanged
Endpoints are provisioned into endpoint management database
Device identity information that’s important to SACM
Not traveling over a SACM transport
Administrator constructs a query
I want to consume information you have about assets I’m interested in
Method of query is based on what the provider registered as capability
Can ask me over the grid or by this direct RESTful API, etc.

Control Plane:
	Does:
Capture Capability announcements
Provides auth capability (protocol TBD)
Provides resource to find capability providers

Capability Definition
Provider and/or consumer data
Ability to exchange taxonomy (language about schemas provided)
Optional/MAY
Data transfer protocol(s)
Data model(s)
Authentication protocol(s) - direct, indirect/SSO
</FrameOfReference>

Regards,

Adam

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 24 Jul 2014 17:15:55 -0400

On 7/24/2014 4:30 PM, Adam W. Montville wrote:
> All:
>
> This morning a few of us attempted a deeper dive on the “Ice Station
> Zebra” usage scenario to gain better understanding of the data that
> would be required between two SACM participants.
>
> Before getting into that, toward the end of the meeting we found
> ourselves asking what success looks like.  We seemed to generally agreed
> that success is getting the Control Plane, Data Plane, and essential
> configuration assessment items in place.  This would include information
> models needed for Control Plane administration/configuration and
> configuration assessment.
>
> The following “things that we should do” and “things we need to discuss”
> are based on the “Frame Of Reference” bit below (thanks for sharing your
> notes Lisa!) and on notes I took.  If others have things to add or
> alter, please do so.
>
>   * Pick term, define it in terminology draft, use it - a comment was
>     heard that we tend to switch around on terminology, so let’s try to
>     pick one, document it, and stick with it.
>   * We should work on security considerations for authentication and
>     delegation of authentication
>   * We should not preclude ecosystem possibilities, but we should be
>     explicit about what we intend to standardize and what we intend to
>     restrict (thus drawing a line between what we will do and what we
>     will leave to be possible in the future).
>   * Define taxonomy or functional taxonomy in the terminology document
>
>
>   * We need to have a discussion about authorization.  There is
>     authorization at the Control Plane level, but are there more
>     granular authorizations for which we need to provide?  What provides
>     that more granular authorization (i.e. Control Plane, Provider,
>     delegate, something else)?
>   * How do we define that we need a service to provide a taxonomy of,
>     for example, enterprise-relevant tags?  We believe this should go
>     into the architecture draft.
>   * How can queries be filtered?  Concrete list, wildcard, metadata
>     characteristics…  And, does the Provider do the filtering or the
>     Proxy or…
>   * One way to allow Providers to announce the availability of a
>     functional taxonomy is to use a registry with some standard entries,
>     but with extension guidance for unimagined functional taxonomies
>
>
>
> <FrameOfReference>

Must it?

An alternative would be to simply broadcast its existence, such as is 
done with an LMAnnounce.  Some drawbacks:
  * Must periodically re-announce so newcomers get the message
  * Won't cross network boundaries unless rules are created at the 
network level
  * Doesn't scale

Another alternative it to not announce, but to respond to broadcast 
queries that it matches -- such as is done with ARP.  Much more 
scalable, but, again, won't inherently cross network boundaries. 
Although a possible response to such a query could be information that 
resolves the query conditions for a node on another network.

And if there is registration, registration with what?  An authoritative 
server?  In that case the server must already be known, along with 
mutual authentication information.

>
>  1. Registration (station endpoint management system, university admin)
>      1. Each client publishes its capabilities (“I know this stuff”)
>      2. So far, no data about any assets has been exchanged
>  2. Endpoints are provisioned into endpoint management database
>      1. Device identity information that’s important to SACM
>      2. Not traveling over a SACM transport
>  3. Administrator constructs a query
>      1. I want to consume information you have about assets I’m
>         interested in
>      2. Method of query is based on what the provider registered as
>         capability
>          1. Can ask me over the grid or by this direct RESTful API, etc.

Is it anticipated that a SACM participant not be required to implement, 
at a minimum, a common query method and data model?

If it is allowed that SACM participants can interact using a free choice 
of method, that then leads to two possibilities:

1) A consumer can only make queries of endpoints for which it has 
implemented the matching query method.  Portions of the network will, 
therefore, be inaccessible to it.

2) Every consumer has to implement every possible query method.

>
>
> Control Plane:
> Does:
>
>   * Capture Capability announcements
>   * Provides auth capability (protocol TBD)
>   * Provides resource to find capability providers
>
>
> Capability Definition
>
>   * Provider and/or consumer data
>       o Ability to exchange taxonomy (language about schemas provided)
>       o Optional/MAY
>   * Data transfer protocol(s)
>   * Data model(s)
>   * Authentication protocol(s) - direct, indirect/SSO
>
> </FrameOfReference>
>
>
> Regards,
>
> Adam
>
>
>
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Jul 2014 18:08:09 -0400

Hi,

I'm a bit concerned that this WG has chosen to use the term "Control Plane".

SACM is about configuration (charter: Standardized protocols to collect,
verify, and update system security configurations) and continuous
monitoring, 

That would seem to put it into the management plane (which many consider a
subset of the control plane).

Defining part of the management plane as being the "control plane" seems a
poor choice of terminology.

I tried to find the definition in the terminology draft, but it's not there.

I tried to find it in the use cases draft but it's not there.

I finally found it in one of the architecture drafts.

Since the IETF is all about the Internet, "control plane" seems a term of
art related to routing and networking, such as OSPF and BGP.

Recognizing that I might not know about non-router usages, I looked up
"control plane" in Wikipedia, which redirects "control plane" to "routing
control plane".

I checked a few other web sites that discuss control plane versus management
plane.

<http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html>
http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html

 <http://whatis.techtarget.com/definition/plane-in-networking>
http://whatis.techtarget.com/definition/plane-in-networking

<http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security
/configuration/guide/syssec_cg41crs_chapter7.html>
http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/
configuration/guide/syssec_cg41crs_chapter7.html

 <http://en.wikipedia.org/wiki/Telecommunications_network>
http://en.wikipedia.org/wiki/Telecommunications_network

This group's use of control plane appears to be slightly different than the
rest of the networking industry.

It appears a SACM "control plane" is a broker for AAA services, so why not
call it a AAA broker?

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: sacm [mailto:[email-masked]] On Behalf Of Adam W. Montville
Sent: Thursday, July 24, 2014 4:31 PM
To: [email-masked]
Subject: [sacm] Notes from Information Model Discussion

All:

This morning a few of us attempted a deeper dive on the "Ice Station Zebra"
usage scenario to gain better understanding of the data that would be
required between two SACM participants.  

Before getting into that, toward the end of the meeting we found ourselves
asking what success looks like.  We seemed to generally agreed that success
is getting the Control Plane, Data Plane, and essential configuration
assessment items in place.  This would include information models needed for
Control Plane administration/configuration and configuration assessment.

The following "things that we should do" and "things we need to discuss" are
based on the "Frame Of Reference" bit below (thanks for sharing your notes
Lisa!) and on notes I took.  If others have things to add or alter, please
do so.

*	Pick term, define it in terminology draft, use it - a comment was
heard that we tend to switch around on terminology, so let's try to pick
one, document it, and stick with it.
*	We should work on security considerations for authentication and
delegation of authentication
*	We should not preclude ecosystem possibilities, but we should be
explicit about what we intend to standardize and what we intend to restrict
(thus drawing a line between what we will do and what we will leave to be
possible in the future).
*	Define taxonomy or functional taxonomy in the terminology document

*	We need to have a discussion about authorization.  There is
authorization at the Control Plane level, but are there more granular
authorizations for which we need to provide?  What provides that more
granular authorization (i.e. Control Plane, Provider, delegate, something
else)?
*	How do we define that we need a service to provide a taxonomy of,
for example, enterprise-relevant tags?  We believe this should go into the
architecture draft.
*	How can queries be filtered?  Concrete list, wildcard, metadata
characteristics.  And, does the Provider do the filtering or the Proxy or.
*	One way to allow Providers to announce the availability of a
functional taxonomy is to use a registry with some standard entries, but
with extension guidance for unimagined functional taxonomies

<FrameOfReference>

1.	Each client publishes its capabilities ("I know this stuff")
2.	So far, no data about any assets has been exchanged

1.	Device identity information that's important to SACM
2.	Not traveling over a SACM transport

1.	I want to consume information you have about assets I'm interested
in
2.	Method of query is based on what the provider registered as
capability

Control Plane:

          Does:

Capability Definition

*	Ability to exchange taxonomy (language about schemas provided)
*	Optional/MAY

</FrameOfReference>

Regards,

Adam

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Jul 2014 18:20:46 -0400

> 2) Every consumer has to implement every possible query method.

If every participant can interact using a free choice of method, leading to
non-interoperability, that raises the question: 
Why are we doing this in the IETF?

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 24 Jul 2014 22:48:48 +0000

Or...

3) we define MTI transports and data formats to enable interop.

Dave

David Harrington
[email-masked]
+1-603-828-1401

---

From: Lisa Lorenzin <[email-masked]>
Date: Thu, 24 Jul 2014 23:02:14 +0000

Hi David,

I believe we've agreed in previous discussions that we will
standardize and require data format(s) and transport protocol(s)
that will be mandatory to implement, to ensure interoperability,
but include extensibility points to accommodate participants
choosing other data format(s) and transport protocol(s).

If desired, I can dig through the notes so far and see if I
can find a citation for that decision. :)

                                                        Regards,

                                                                Lisa

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Thursday, July 24, 2014 6:21 PM
To: [email-masked]
Subject: Re: [sacm] Notes from Information Model Discussion

David Harrington
[email-masked]
+1-603-828-1401

---

From: Lisa Lorenzin <[email-masked]>
Date: Thu, 24 Jul 2014 23:02:13 +0000

Hi David,

I agree with your concern about creating our own definition of
a term that's already in wide use with a different meaning!

However, in the architecture discussions, we've envisioned
that the control plane could operate in one of several modes -
so far we've identified:
* broker - CP receives a request from a consumer and returns
instructions to the consumer on how to obtain requested data
from appropriate provider(s)
* proxy - CP receives a request from a consumer, gathers the
information from appropriate provider(s), and returns the
information to the consumer itself
* repository - providers publish information directly to the
CP; CP receives a request from a consumer and returns
information from its store of published data
as the three primary modes.

So we need to find a term that encompasses more than just
the broker mode...

                                        Regards,

                                                Lisa

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of David Harrington
Sent: Thursday, July 24, 2014 6:08 PM
To: [email-masked]
Subject: Re: [sacm] Notes from Information Model Discussion

Hi,

SACM is about configuration (charter: Standardized protocols to collect, verify, and update system security configurations) and continuous monitoring,

That would seem to put it into the management plane (which many consider a subset of the control plane).

Defining part of the management plane as being the "control plane" seems a poor choice of terminology.

Since the IETF is all about the Internet, "control plane" seems a term of art related to routing and networking, such as OSPF and BGP.

Recognizing that I might not know about non-router usages, I looked up "control plane" in Wikipedia, which redirects "control plane" to "routing control plane".

I checked a few other web sites that discuss control plane versus management plane.

http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html <http://blog.ipspace.net/2013/08/management-control-and-data-planes-in.html>

http://whatis.techtarget.com/definition/plane-in-networking <http://whatis.techtarget.com/definition/plane-in-networking>

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/configuration/guide/syssec_cg41crs_chapter7.html <http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/configuration/guide/syssec_cg41crs_chapter7.html>

http://en.wikipedia.org/wiki/Telecommunications_network <http://en.wikipedia.org/wiki/Telecommunications_network>

This group's use of control plane appears to be slightly different than the rest of the networking industry.

It appears a SACM "control plane" is a broker for AAA services, so why not call it a AAA broker?

David Harrington

[email-masked] <mailto:[email-masked]>

+1-603-828-1401

All:

This morning a few of us attempted a deeper dive on the "Ice Station Zebra" usage scenario to gain better understanding of the data that would be required between two SACM participants.

The following "things that we should do" and "things we need to discuss" are based on the "Frame Of Reference" bit below (thanks for sharing your notes Lisa!) and on notes I took.  If others have things to add or alter, please do so.

*       Pick term, define it in terminology draft, use it - a comment was heard that we tend to switch around on terminology, so let's try to pick one, document it, and stick with it.
*       We should work on security considerations for authentication and delegation of authentication
*       We should not preclude ecosystem possibilities, but we should be explicit about what we intend to standardize and what we intend to restrict (thus drawing a line between what we will do and what we will leave to be possible in the future).
*       Define taxonomy or functional taxonomy in the terminology document

*       We need to have a discussion about authorization.  There is authorization at the Control Plane level, but are there more granular authorizations for which we need to provide?  What provides that more granular authorization (i.e. Control Plane, Provider, delegate, something else)?
*       How do we define that we need a service to provide a taxonomy of, for example, enterprise-relevant tags?  We believe this should go into the architecture draft.
*       How can queries be filtered?  Concrete list, wildcard, metadata characteristics...  And, does the Provider do the filtering or the Proxy or...
*       One way to allow Providers to announce the availability of a functional taxonomy is to use a registry with some standard entries, but with extension guidance for unimagined functional taxonomies

<FrameOfReference>

        1.      I want to consume information you have about assets I'm interested in
        2.      Method of query is based on what the provider registered as capability

Control Plane:

          Does:

Capability Definition

</FrameOfReference>

Regards,

Adam

---

From: "David Harrington" <[email-masked]>
Date: Thu, 24 Jul 2014 19:37:45 -0400

Hi,

What's an MTI transport?
MTI does not appear to be mentioned in any of the sacm documents.

Assuming (thanks Wikipedia) you mean message type indicator, that would
still imply 1) interoperability between nodes only with matching query
mechanisms (i.e., not vendor-neutral interoperability), or 2) everybody has
to implement everything.
If you sent me a message in Russian, and had a language indicator that told
me it was Russian, I still wouldn't be able to read the message.

David Harrington
[email-masked]
+1-603-828-1401

> From: Waltermire, David A. [mailto:[email-masked]]
> Sent: Thursday, July 24, 2014 6:49 PM
> To: David Harrington; [email-masked]

---

From: Lisa Lorenzin <[email-masked]>
Date: Fri, 25 Jul 2014 00:15:40 +0000

I read it as Mandatory To Implement...

Regards,
Lisa

Please pardon brevity - sent from my HTC EVO running Junos Pulse

----- Reply message -----
From: "David Harrington" <[email-masked]>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <[email-masked]>, "[email-masked]" <[email-masked]>

Hi,

What's an MTI transport?

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Jul 2014 00:28:43 +0000

Mandatory to implement is what I intended.
Thanks,
Dave

Lisa Lorenzin <[email-masked]> wrote:

Regards,
Lisa

----- Reply message -----
From: "David Harrington" <[email-masked]>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <[email-masked]>, "[email-masked]" <[email-masked]>

Hi,

What's an MTI transport?

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Waltermire, David A." <[email-masked]>
Date: Fri, 25 Jul 2014 00:34:34 +0000

Regards,
Lisa

----- Reply message -----
From: "David Harrington" <[email-masked]>
Date: Thu, Jul 24, 2014 19:37
Subject: [sacm] Notes from Information Model Discussion
To: "&apos;Waltermire, David A.&apos;" <[email-masked]>, "[email-masked]" <[email-masked]>

Hi,

What's an MTI transport?

David Harrington
[email-masked]
+1-603-828-1401

---

From: Gunnar Engelbach <[email-masked]>
Date: Thu, 24 Jul 2014 21:48:24 -0400

> choosing other data format(s) and transport protocol(s).

Yes, it would be nice of us if we describe an architecture that can also 
be used with other data formats and transport protocols.  But as soon as 
a node starts using one of those other formats/protocols that data 
interchange is no longer a SACM conversation.

Being able to act as a SACM node will require a software implementation 
on the endpoint, and that's not going to happen on all endpoints -- 
legacy equipment, for example, or closed devices that just chose to not 
implement.

These endpoints will still be network denizens that need to be 
evaluated, it just won't happen directly as a SACM participant.  So at 
some point, something will need to broker the SACM request/response into 
something that can interact with the non-SACM endpoints -- a proxy.

And the closer that happens to the endpoint the better, since that 
minimizes the number of places that non-SACM formats/protocols need to 
be implemented.

So, SACM itself should have no need to support other formats/protocols.

If the SACM architecture is such that it can and this makes it useful 
for other purposes -- wonderful.

Does anybody else read this differently?

--gun

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 25 Jul 2014 07:12:57 -0400

On Jul 24, 2014, at 9:48 PM, Gunnar Engelbach <[email-masked]> wrote:

> Yes, it would be nice of us if we describe an architecture that can also be used with other data formats and transport protocols.  But as soon as a node starts using one of those other formats/protocols that data interchange is no longer a SACM conversation.
> 
> Being able to act as a SACM node will require a software implementation on the endpoint, and that's not going to happen on all endpoints -- legacy equipment, for example, or closed devices that just chose to not implement.
> 
> These endpoints will still be network denizens that need to be evaluated, it just won't happen directly as a SACM participant.  So at some point, something will need to broker the SACM request/response into something that can interact with the non-SACM endpoints -- a proxy.
> 
> And the closer that happens to the endpoint the better, since that minimizes the number of places that non-SACM formats/protocols need to be implemented.
> 
> If the SACM architecture is such that it can and this makes it useful for other purposes -- wonderful.
> 
> 

I’m sure others on the list will chime in.  Here are my thoughts.  To be successful, SACM needs to define its control plane (using that term again until we figure it out), it’s data plane, and some information models to get through the pipes.  We’re going to start this with an eye toward getting adoption in the field.  Adoption from security tool vendors who probably already have their own methods of doing these things and collecting data from endpoints.  In some cases, they use broker networks, in others it’s point to point.  In some cases, they use agents, in others they don’t.  We need to look at this not only as an architecture for the future, but as an architecture that is flexible enough to enable generalized interoperability between vendors’ tools.  

Put another way, SACM has a need to support the formats and protocols it needs to support.  We don’t know exactly what that set is today, and we should not preclude what we cannot envision.

---

From: "Adam W. Montville" <[email-masked]>
Date: Fri, 25 Jul 2014 07:17:12 -0400

On Jul 24, 2014, at 6:08 PM, David Harrington <[email-masked]> wrote:

> Hi,
>  
> I’m a bit concerned that this WG has chosen to use the term “Control Plane”.
> Defining part of the management plane as being the “control plane” seems a poor choice of terminology.
>  
> I tried to find the definition in the terminology draft, but it’s not there.
> I tried to find it in the use cases draft but it’s not there.
> Since the IETF is all about the Internet, “control plane” seems a term of art related to routing and networking, such as OSPF and BGP.
> Recognizing that I might not know about non-router usages, I looked up “control plane” in Wikipedia, which redirects “control plane” to “routing control plane”.
> http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-1/security/configuration/guide/syssec_cg41crs_chapter7.html
> This group’s use of control plane appears to be slightly different than the rest of the networking industry.
> It appears a SACM “control plane” is a broker for AAA services, so why not call it a AAA broker?

It’s not just AAA services, but your point about management plane vs. control plane is well taken.  We’ll have to work this one out, because we do not intend to confuse other WGs or the public relying on these specifications.  To defend a bit about the term and it’s lack of presence in terminology, though, it’s all a work in progress so, of course things aren’t as “tight” as we would ultimately like them to be.