designing a network interface

When we design an network interface, we should make sure to review the relevant discussions on the list mailing list.

https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html

http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html

So maybe we need a separate construct called network "connection" to actually describe a relationship between an endpoint and a network? If the consensus is that "interface" is a hardware term, then that's good. We just also need a configuration term to describe how an endpoint is configured to use an interface to transmit data on a given network. Following the trail also leads to discussing terms like "socket" and "session", some of which are already authoritatively defined.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Danny Haynes Sent: Tuesday, November 24, 2015 10:19 AM To: sacmwg/draft-ietf-sacm-information-model Subject: [Non-DoD Source] [sacm] [draft-ietf-sacm-information-model] designing a network interface (#34)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

When we design an network interface, we should make sure to review the relevant discussions on the list mailing list.

Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >

Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html >

— Reply to this email directly or view it on GitHub < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 > . Caution-https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif

Hi Danny and Joseph,

To be network and transport agnostic, I suggest subsuming both "connection" and "session" under the application security term "association" (e.g., which can be applied to DTLS between two systems).

The terms "connection" and "session" (especially) have been blurred badly in recent years. The idea of importance though is the application data flow to/from an endpoint and some server system.

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Nov 24, 2015 at 10:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) < joseph.l.wolfkiel.civ@mail.mil> wrote:

So maybe we need a separate construct called network "connection" to actually describe a relationship between an endpoint and a network? If the consensus is that "interface" is a hardware term, then that's good. We just also need a configuration term to describe how an endpoint is configured to use an interface to transmit data on a given network. Following the trail also leads to discussing terms like "socket" and "session", some of which are already authoritatively defined.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Danny Haynes Sent: Tuesday, November 24, 2015 10:19 AM To: sacmwg/draft-ietf-sacm-information-model Subject: [Non-DoD Source] [sacm] [draft-ietf-sacm-information-model] designing a network interface (#34)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

When we design an network interface, we should make sure to review the relevant discussions on the list mailing list.

Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html

Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html >

— Reply to this email directly or view it on GitHub < Caution- https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 > . <Caution- https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

As long as it's defined somewhere. If "association" is where we define the configuration settings, key exchanges, session parameters, etc. that allow an endpoint to identify itself to/on and communicate over a given network for a period of time, then that's also OK.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Tuesday, November 24, 2015 11:04 AM To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald Cc: sacm@ietf.org; sacmwg/draft-ietf-sacm-information-model Subject: Re: [sacm] [Non-DoD Source] [draft-ietf-sacm-information-model] designing a network interface (#34)

Hi Danny and Joseph,

To be network and transport agnostic, I suggest subsuming both

"connection" and "session" under the application security term

"association" (e.g., which can be applied to DTLS between two

systems).

The terms "connection" and "session" (especially) have been

blurred badly in recent years. The idea of importance though

is the application data flow to/from an endpoint and some

server system.

Cheers,

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc Caution-http://sites.google.com/site/blueroofmusic < Caution-http://sites.google.com/site/blueroofmusic > Caution-http://sites.google.com/site/highnorthinc < Caution-http://sites.google.com/site/highnorthinc > Caution-mailto: blueroofmusic@gmail.com < Caution-mailto:blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Nov 24, 2015 at 10:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) <joseph.l.wolfkiel.civ@mail.mil < Caution-mailto:joseph.l.wolfkiel.civ@mail.mil > > wrote:

So maybe we need a separate construct called network "connection" to actually describe a relationship between an endpoint and a network?  If the consensus is that "interface" is a hardware term, then that's good.  We just also need a configuration term to describe how an endpoint is configured to use an interface to transmit data on a given network.  Following the trail also leads to discussing terms like "socket" and "session", some of which are already authoritatively defined.

Joseph L. Wolfkiel
SCM Engineering Lead
DISA ID52
Fort Meade DISA Acquisiton Bldg Cube A4A58E
Work: (301) 225-8820 < tel:%28301%29%20225-8820 > 
Gov Cell: (571) 814-8231 < tel:%28571%29%20814-8231 > 
Joseph.L.Wolfkiel.civ@mail.mil < Caution-mailto:Joseph.L.Wolfkiel.civ@mail.mil > 

-----Original Message-----
From: sacm [Caution-mailto:sacm-bounces@ietf.org < Caution-mailto:sacm-bounces@ietf.org > ] On Behalf Of Danny Haynes
Sent: Tuesday, November 24, 2015 10:19 AM
To: sacmwg/draft-ietf-sacm-information-model
Subject: [Non-DoD Source] [sacm] [draft-ietf-sacm-information-model] designing a network interface (#34)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

________________________________

When we design an network interface, we should make sure to review the relevant discussions on the list mailing list.

Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  < Caution-Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html >  >

Caution-Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html >  < Caution-Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution-http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html >  >

—
Reply to this email directly or view it on GitHub < Caution-Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 < Caution-https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 >  > . <Caution-Caution-https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif < Caution-https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif > >

_______________________________________________
sacm mailing list
sacm@ietf.org < Caution-mailto:sacm@ietf.org > 
Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-https://www.ietf.org/mailman/listinfo/sacm >

Hi Joseph,

Agreed - I suggest that we need to capture the "stack" of connectivity (e.g., IPSec, TLS/DTLS or SSH or ..., and the application layer channel binding) in the proposed "association" container.

And referenced but separate from an "association" we need a "network interface" (vaguely layer 2, although with tunneling this blurs a lot).

Cheers,

On Tue, Nov 24, 2015 at 11:10 AM, Wolfkiel, Joseph L CIV DISA ID (US) < joseph.l.wolfkiel.civ@mail.mil> wrote:

As long as it's defined somewhere. If "association" is where we define the configuration settings, key exchanges, session parameters, etc. that allow an endpoint to identify itself to/on and communicate over a given network for a period of time, then that's also OK.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Ira McDonald Sent: Tuesday, November 24, 2015 11:04 AM To: Wolfkiel, Joseph L CIV DISA ID (US); Ira McDonald Cc: sacm@ietf.org; sacmwg/draft-ietf-sacm-information-model Subject: Re: [sacm] [Non-DoD Source] [draft-ietf-sacm-information-model] designing a network interface (#34)

All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.

Hi Danny and Joseph,

To be network and transport agnostic, I suggest subsuming both

"connection" and "session" under the application security term

"association" (e.g., which can be applied to DTLS between two

systems).

The terms "connection" and "session" (especially) have been

blurred badly in recent years. The idea of importance though

is the application data flow to/from an endpoint and some

server system.

Cheers,

Ira

Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc Caution-http://sites.google.com/site/blueroofmusic < Caution- http://sites.google.com/site/blueroofmusic > Caution-http://sites.google.com/site/highnorthinc < Caution- http://sites.google.com/site/highnorthinc > Caution-mailto: blueroofmusic@gmail.com < Caution-mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434

On Tue, Nov 24, 2015 at 10:53 AM, Wolfkiel, Joseph L CIV DISA ID (US) < joseph.l.wolfkiel.civ@mail.mil < Caution-mailto: joseph.l.wolfkiel.civ@mail.mil > > wrote:
    So maybe we need a separate construct called network "connection"
to actually describe a relationship between an endpoint and a network? If the consensus is that "interface" is a hardware term, then that's good. We just also need a configuration term to describe how an endpoint is configured to use an interface to transmit data on a given network. Following the trail also leads to discussing terms like "socket" and "session", some of which are already authoritatively defined.
    Joseph L. Wolfkiel
    SCM Engineering Lead
    DISA ID52
    Fort Meade DISA Acquisiton Bldg Cube A4A58E
    Work: (301) 225-8820 < tel:%28301%29%20225-8820 >
    Gov Cell: (571) 814-8231 < tel:%28571%29%20814-8231 >
    Joseph.L.Wolfkiel.civ@mail.mil < Caution-mailto:
Joseph.L.Wolfkiel.civ@mail.mil >
    -----Original Message-----
    From: sacm [Caution-mailto:sacm-bounces@ietf.org < Caution-mailto:
sacm-bounces@ietf.org > ] On Behalf Of Danny Haynes Sent: Tuesday, November 24, 2015 10:19 AM To: sacmwg/draft-ietf-sacm-information-model Subject: [Non-DoD Source] [sacm] [draft-ietf-sacm-information-model] designing a network interface (#34)
    All active links contained in this email were disabled. Please
verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
    ________________________________

    When we design an network interface, we should make sure to review
the relevant discussions on the list mailing list.
    Caution-Caution-
https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html

< Caution-Caution- https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html < Caution-https://www.ietf.org/mail-archive/web/sacm/current/msg03199.html
    Caution-Caution-
http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution- http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html > < Caution-Caution- http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html < Caution- http://www.ietf.org/mail-archive/web/sacm/current/msg03531.html > >
    —
    Reply to this email directly or view it on GitHub <
Caution-Caution- https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 < Caution- https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/34 >

. <Caution-Caution- https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif < Caution- https://github.com/notifications/beacon/AKbE0VL-uXRBm9YtcqseHrlPusAVwnZ4ks5pJHdYgaJpZM4Goc5a.gif
    _______________________________________________
    sacm mailing list
    sacm@ietf.org < Caution-mailto:sacm@ietf.org >
    Caution-https://www.ietf.org/mailman/listinfo/sacm < Caution-
https://www.ietf.org/mailman/listinfo/sacm >

The other way to look at is that the IM is not sufficient if it doesn't support enough information about an endpoint to determine if two sensors evaluating an endpoint are evaluating the same endpoint or a different endpoint. It should also provide enough metadata about an endpoint for the same sensor to determine if a endpoint it evaluated at a previous time is the same endpoint currently under evaluation.

Endpoint identification through matching of some data set is, I think, a critical function of any SACM solution.

Or are you saying that the "specific data models" will contain data elements that are not in the IM? If that's the case, then is the IM really important?

If interoperability is a goal of the standard (maybe it isn't), then the ability to share device identities between products that implement the standard seems like a critical requirement.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, December 01, 2015 9:30 PM To: sacmwg/draft-ietf-sacm-requirements Subject: Re: [sacm] [draft-ietf-sacm-requirements] Matching Algorithms (#73)

I don't see this a something that needs to be mentioned in this document. I would expect that the exact matching algorithm used is going to be highly proprietary and dependent on specific data models. At this point is is not even clear if the IM would provide the necessary points to hang the result of the matching algorithm is expressed as this implies This means that it would not even be clear at this point how the result of a matching algorithm is even expressed.

We have not even expressed that there is a set of operations that needs to be supported.

— Reply to this email directly or view it on GitHub < Caution-https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-161159674 > . Caution-https://github.com/notifications/beacon/AKbE0Z7IuoKGp1MBV90XzcmG5xAGVlXJks5pLk8agaJpZM4GlJCy.gif

1) I would agree that the current IM "is not sufficient if you want it to support enough information about an endpoint to determine if two sensors evaluating an endpoint are evaluating the same endpoint or a different endpoint. It should also provide enough metadata about an endpoint for the same sensor to determine if a endpoint it evaluated at a previous time is the same endpoint currently under evaluation." I would ask the WG if they agree?

2) "Endpoint identification through matching of some data set is, I think, a critical function of any SACM solution." I would ask the WG if they agree?

3) I don't think that the "specific data models" would offer a sufficient, or efficient solution. (I would think more about: an aggregation of data models, or (maybe an utopia) a mega Cyber Model (Ontology))

4) As we agreed, so far, that "the model must let SACM components and humans reason with uncertainty. There are no facts, only assertions." I only see mechanisms to support 1) under uncertainty, but with acceptable (or highest) level of accuracy, confidence, etc. (NB: the mechanisms/algorithms I envision are not possible with the current IM)

5) "If interoperability is a goal of the standard (maybe it isn't), then the ability to share device identities between products that implement the standard seems like a critical requirement." I would ask the WG if they agree?

2015-12-02 16:32 GMT+03:00 Wolfkiel, Joseph L CIV DISA ID (US) joseph.l.wolfkiel.civ@mail.mil:

The other way to look at is that the IM is not sufficient if it doesn't support enough information about an endpoint to determine if two sensors evaluating an endpoint are evaluating the same endpoint or a different endpoint. It should also provide enough metadata about an endpoint for the same sensor to determine if a endpoint it evaluated at a previous time is the same endpoint currently under evaluation.

Endpoint identification through matching of some data set is, I think, a critical function of any SACM solution.

Or are you saying that the "specific data models" will contain data elements that are not in the IM? If that's the case, then is the IM really important?

If interoperability is a goal of the standard (maybe it isn't), then the ability to share device identities between products that implement the standard seems like a critical requirement.

Joseph L. Wolfkiel SCM Engineering Lead DISA ID52 Fort Meade DISA Acquisiton Bldg Cube A4A58E Work: (301) 225-8820 Gov Cell: (571) 814-8231 Joseph.L.Wolfkiel.civ@mail.mil

-----Original Message----- From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, December 01, 2015 9:30 PM To: sacmwg/draft-ietf-sacm-requirements Subject: Re: [sacm] [draft-ietf-sacm-requirements] Matching Algorithms (#73)

I don't see this a something that needs to be mentioned in this document. I would expect that the exact matching algorithm used is going to be highly proprietary and dependent on specific data models. At this point is is not even clear if the IM would provide the necessary points to hang the result of the matching algorithm is expressed as this implies This means that it would not even be clear at this point how the result of a matching algorithm is even expressed.

We have not even expressed that there is a set of operations that needs to be supported.

— Reply to this email directly or view it on GitHub < Caution-https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/73#issuecomment-161159674 > . Caution-https://github.com/notifications/beacon/AKbE0Z7IuoKGp1MBV90XzcmG5xAGVlXJks5pLk8agaJpZM4GlJCy.gif

sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm

There is a very basic draft definition of a networkInterface IE. Other IEs suggested for inclusion in this IE, include: domain, default gateway, DNS server, and FQDN, first configure time, and time of last communication. Some network interfaces might have additional information such as: SIM card identifier, telephone number, carrier, network type, etc. For those who have participated in this thread, please review the draft IE and thread and suggestion revisions.

sacmwg / draft-ietf-sacm-information-model

designing a network interface #34