Subject: Re: [sacm] Comments on Network Interface

From: Clifford Kahn <[email-masked]>
Date: Sun, 1 Feb 2015 14:39:10 +0000

Henk,
Belated response here.

As I understand you, you would remove the class "session", mentioned in the diagram and in section 4.10 of draft-ietf-sacm-information-model. Is that true? 

I realize there is more to your proposal. But I want to respond to removing "session". Let's consider why sessions were there. 

Suppose an endpoint's layer 2 interface comes online after a RADIUS exchange. Some of us would say a layer 2 session has begun; that may be misuse of the word "session". Anyway, the RADIUS server knows:
- the endpoint's MAC address
- the credentials used in the RADIUS authentication 
- the authorization that it granted (VLAN, a filter-id denoting firewall rules)
- the endpoint's compliance, if NEA checking was done during the RADIUS exchange
- sometimes, an IP address (if the switch does DHCP snooping and reports its findings in RADIUS Accounting messages)

That information is relevant for SACM. Authorization is relevant because endpoints that have access to sensitive resources may be subject to more stringent compliance policies. (Hm. Do we have that in our use cases? Should we?) 

Perhaps we don't need a session in the model. Perhaps the RADIUS server can just make an endpoint attribute assertion stating the above attributes. I like the simplification. 

Other kinds of network sessions (TCP connections, etc.) are certainly relevant for security. But they seem to be outside of the SACM WG's charter. 

In sum, I cannot see a reason to keep "session" in the information model.  

What do others think?

Best,
			Cliff

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2014 11:39 AM
To: [email-masked]
Subject: [sacm] Comments on Network Interface

Hi all,

the new draft (draft-ietf-sacm-information-model-00) now includes a 
combined section for "Network Session" and "Network Interface" (4.10.).

My recommendation is to divide the elements Network Session, Network 
Interface and potentially (Network) Address into separate sections of 
the same level (4.x).

While both terms are related, of course, there are several (more or less 
important) reasons for this:
A session typically involves multiple participants (e.g. endpoints, or - 
broken down - eventually addresses or interfaces) and typically has a 
limited life-time. An interface, in contrast, is a singular entity that 
can exist over the complete life-cycle of an endpoint (virtual 
interfaces can have a foreseeable limited life-time). As Ira pointed 
out, an interface typically provides connectivity to a network on layer 
two to three, while a network session is typically associated with 
layers above those.

Although closely related, they are quite different, semantically, and 
may even need separate representations in the SACM IM.

My proposal for a separate "Network Interface" section:

---snip---
Network Interface

An endpoint is connected to a network via one or more interfaces. 
Interfaces can be physical or virtual. Interfaces of an endpoint can 
operate on different layers, most prominently what is now commonly 
called layer 2 and 3. Within a layer, interfaces can be nested.
On layer 2, a root interface is typically associated with a physical 
interface port and nested interfaces are virtual interfaces. In the case 
of a virtual endpoint, a root interface can be a virtual interface. 
Virtual layer 2 interfaces of one or more endpoints can also
constitute an aggregated group of links that act as one.
On layer 3, nested interfaces typically constitute virtual tunnels or 
networks.
Examples include: physical Ethernet port, layer 2 VLAN interface, a 
MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress.
---snap---

A small addition to the "Address" section, analogously:

---snip---
Network Address

Network addresses are layer specific and follow layer specific address 
schemes. Each interface of a specific layer can be associated with one 
or more addresses appropriate for that layer.
There is no guarantee that an address is globally unique. In general, 
there is a scope to an address in which it is intended to be unique.
Examples include: physical Ethernet port with a MAC address, layer 2 
VLAN interface with a MAC address, layer 3 interface with multiple IPv6 
addresses, layer 3 tunnel ingress or egress with an IPv4 address.
---snap---

Sometimes, the complexity a setup of interfaces can incorporate is a 
little bit underestimated, IMHO. The proposed text above only includes 
the most common cases and does not touch emerging practices, such as 
physical interface modules that provide a set of single physical 
interfaces, which are associated with multiple distinguishable endpoints 
at the same time.

In order to address network centric security/monitoring processes, 
effectively, the SACM IM should be able to handle the complexity of 
applied common practice in its definition of "Network Interface", I think.

Best,

Henk

---

From: Clifford Kahn <[email-masked]>
Date: Sun, 1 Feb 2015 15:38:20 +0000

Henk,
First, a correction. I said, incorrectly, that you had proposed removing the idea of "session". You actually proposed separating it from "interface". (I do suggest we remove "session" altogether.) 

Second, I like your suggestion of promoting section 4.10.1, "Address", to a 4.x section. 

Third, I like your addition to the "Address" section. 

Fourth, let's consider taking it further. In a side conversation you pointed out that a port number is really part of an address. The port number matters for some purposes, but not for others. One place where it matters: you pointed out that compliance policies about network ingress make a lot of sense. For example, a policy could disapprove of an endpoint listening on the MSSQL port (1433). Many successful attacks have been made on ports unintentionally left open, so this is well motivated. 

How would we model this? Is 1.1.1.1:1433 a sub-address of 1.1.1.1? 

Fifth, and most central: you write that we should capture the nested and layered structure of interfaces to "address network centric security/monitoring processes, effectively". I don't understand yet how a network based attribute collector (a "sensor") would know or care.  A sensor observes or injects network traffic. It knows addresses. How can it be aware of network interfaces? How can it discern whether one interface nests in another? 

An attribute collector that runs on the endpoint, or that queries the endpoint using a management protocol, may discern the nesting. But it is not a sensor. Would information from the two kinds of collectors have to be combined? 

Best,
			Cliff

-----Original Message-----
From: Clifford Kahn 
Sent: Sunday, February 01, 2015 9:39 AM
To: 'Henk Birkholz'; [email-masked]
Subject: RE: [sacm] Comments on Network Interface

Henk,
Belated response here.

What do others think?

Best,
			Cliff

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]]
Sent: Tuesday, November 04, 2014 11:39 AM
To: [email-masked]
Subject: [sacm] Comments on Network Interface

Hi all,

the new draft (draft-ietf-sacm-information-model-00) now includes a combined section for "Network Session" and "Network Interface" (4.10.).

My recommendation is to divide the elements Network Session, Network Interface and potentially (Network) Address into separate sections of the same level (4.x).

While both terms are related, of course, there are several (more or less
important) reasons for this:
A session typically involves multiple participants (e.g. endpoints, or - broken down - eventually addresses or interfaces) and typically has a limited life-time. An interface, in contrast, is a singular entity that can exist over the complete life-cycle of an endpoint (virtual interfaces can have a foreseeable limited life-time). As Ira pointed out, an interface typically provides connectivity to a network on layer two to three, while a network session is typically associated with layers above those.

Although closely related, they are quite different, semantically, and may even need separate representations in the SACM IM.

---snip---
Network Interface

An endpoint is connected to a network via one or more interfaces. 
Interfaces can be physical or virtual. Interfaces of an endpoint can operate on different layers, most prominently what is now commonly called layer 2 and 3. Within a layer, interfaces can be nested.
On layer 2, a root interface is typically associated with a physical interface port and nested interfaces are virtual interfaces. In the case of a virtual endpoint, a root interface can be a virtual interface. 
Virtual layer 2 interfaces of one or more endpoints can also constitute an aggregated group of links that act as one.
On layer 3, nested interfaces typically constitute virtual tunnels or networks.
Examples include: physical Ethernet port, layer 2 VLAN interface, a MC-LAG setup, layer 3 Point-to-Point tunnel ingress or egress.

---snip---
Network Address

Network addresses are layer specific and follow layer specific address schemes. Each interface of a specific layer can be associated with one or more addresses appropriate for that layer.
There is no guarantee that an address is globally unique. In general, there is a scope to an address in which it is intended to be unique.
Examples include: physical Ethernet port with a MAC address, layer 2 VLAN interface with a MAC address, layer 3 interface with multiple IPv6 addresses, layer 3 tunnel ingress or egress with an IPv4 address.
---snap---

Sometimes, the complexity a setup of interfaces can incorporate is a little bit underestimated, IMHO. The proposed text above only includes the most common cases and does not touch emerging practices, such as physical interface modules that provide a set of single physical interfaces, which are associated with multiple distinguishable endpoints at the same time.

In order to address network centric security/monitoring processes, effectively, the SACM IM should be able to handle the complexity of applied common practice in its definition of "Network Interface", I think.

Best,

Henk

---

From: Ira McDonald <[email-masked]>
Date: Sun, 1 Feb 2015 11:09:22 -0500

Hi Cliff,

I'll let Henk respond to most of your questions.

But I wanted to clarify the terms "address" and "session" a bit.

In your example, "1.1.1.1" is a layer 3 (IP) network layer address (a host
device address).
Applications do not "listen" directly to such an address.

OTOH, "1.1.1.1:1433" is a layer 4 (TCP, UDP, or SCTP) transport layer
address (often
called an endpoint application address).

Firewalls mostly operate on layer 4 (and above) addresses.  The port *is*
always
present in a layer 4 address - it's not separate.  Firewall port masks
select allowed
incoming (and separate outgoing) sets of port numbers.

An application layer gateway (ALG) is sometimes incorporated into a
firewall and
will inspect the headers (and sometimes the data for IPR protection) in a
layer 5
(session), layer 6 (presentation), or layer 7 (application) packet (e.g.,
the headers
in an HTTP PUT request).

The term "connection" is only correctly used for a layer 4 pair of
endpoints that
uses a reliable transport protocol (e.g., TCP) that re-orders received
packets,
eliminates duplicates, retransmits as necessary, and catches dropped packets
(ones not fixed by retransmission).  In all cases an unrecoverable dropped
packet MUST result in a closed connection.

The term "session" is only correctly used for a layer 5 or higher pair of
endpoints.
Here, a number of packets may make up a single "message" (such as HTTP PUT
request).

The term "association" can be used at any level from layer 2 on up.  A
"security
association" is simply a refinement of an "association" (that has some
specific
security attributes and guarantees).  It's possible to have an
"association" using
any connectionless datagram protocol (e.g., IP at layer 3 and UDP at layer
4).

We now return you to your regular discussion...

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
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Sun, Feb 1, 2015 at 10:38 AM, Clifford Kahn <[email-masked]>
wrote:

> Henk,
> First, a correction. I said, incorrectly, that you had proposed removing
> the idea of "session". You actually proposed separating it from
> "interface". (I do suggest we remove "session" altogether.)
>
> Fourth, let's consider taking it further. In a side conversation you
> pointed out that a port number is really part of an address. The port
> number matters for some purposes, but not for others. One place where it
> matters: you pointed out that compliance policies about network ingress
> make a lot of sense. For example, a policy could disapprove of an endpoint
> listening on the MSSQL port (1433). Many successful attacks have been made
> on ports unintentionally left open, so this is well motivated.
>
> Fifth, and most central: you write that we should capture the nested and
> layered structure of interfaces to "address network centric
> security/monitoring processes, effectively". I don't understand yet how a
> network based attribute collector (a "sensor") would know or care.  A
> sensor observes or injects network traffic. It knows addresses. How can it
> be aware of network interfaces? How can it discern whether one interface
> nests in another?
>
> An attribute collector that runs on the endpoint, or that queries the
> endpoint using a management protocol, may discern the nesting. But it is
> not a sensor. Would information from the two kinds of collectors have to be
> combined?
>
> Best,
>                         Cliff
>
> As I understand you, you would remove the class "session", mentioned in
> the diagram and in section 4.10 of draft-ietf-sacm-information-model. Is
> that true?
>
> I realize there is more to your proposal. But I want to respond to
> removing "session". Let's consider why sessions were there.
>
> Suppose an endpoint's layer 2 interface comes online after a RADIUS
> exchange. Some of us would say a layer 2 session has begun; that may be
> misuse of the word "session". Anyway, the RADIUS server knows:
> - sometimes, an IP address (if the switch does DHCP snooping and reports
> its findings in RADIUS Accounting messages)
>
> That information is relevant for SACM. Authorization is relevant because
> endpoints that have access to sensitive resources may be subject to more
> stringent compliance policies. (Hm. Do we have that in our use cases?
> Should we?)
>
> Perhaps we don't need a session in the model. Perhaps the RADIUS server
> can just make an endpoint attribute assertion stating the above attributes.
> I like the simplification.
>
> Other kinds of network sessions (TCP connections, etc.) are certainly
> relevant for security. But they seem to be outside of the SACM WG's charter.
>
> Interface and potentially (Network) Address into separate sections of the
> same level (4.x).
>
> limited life-time. An interface, in contrast, is a singular entity that can
> exist over the complete life-cycle of an endpoint (virtual interfaces can
> have a foreseeable limited life-time). As Ira pointed out, an interface
> typically provides connectivity to a network on layer two to three, while a
> network session is typically associated with layers above those.
>
> Although closely related, they are quite different, semantically, and may
> even need separate representations in the SACM IM.
>
> operate on different layers, most prominently what is now commonly called
> layer 2 and 3. Within a layer, interfaces can be nested.
> interface port and nested interfaces are virtual interfaces. In the case of
> a virtual endpoint, a root interface can be a virtual interface.
> Virtual layer 2 interfaces of one or more endpoints can also constitute an
> aggregated group of links that act as one.
> Examples include: physical Ethernet port, layer 2 VLAN interface, a MC-LAG
> setup, layer 3 Point-to-Point tunnel ingress or egress.
> ---snap---
>
> schemes. Each interface of a specific layer can be associated with one or
> more addresses appropriate for that layer.
> Examples include: physical Ethernet port with a MAC address, layer 2 VLAN
> interface with a MAC address, layer 3 interface with multiple IPv6
> little bit underestimated, IMHO. The proposed text above only includes the
> most common cases and does not touch emerging practices, such as physical
> interface modules that provide a set of single physical interfaces, which
> are associated with multiple distinguishable endpoints at the same time.
>
> effectively, the SACM IM should be able to handle the complexity of applied
> common practice in its definition of "Network Interface", I think.
>
> Best,
>
> Henk
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 2 Feb 2015 15:10:09 +0100

Hello Cliff,

In essence, 1.1.1.1:1433 could be seen as a sub-address of 1.1.1.1, and 
if the inherent ambiguousness of IP-addresses cannot be addressed (e.g. 
by associating an artificial identifier with each collected IP-address 
TVP), a concept that combines both ports and addresses has to be used in 
parallel to the simpler concepts "IP-address" and "Port".

More thoughts on that in the next mail :)

Cheers,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 2 Feb 2015 15:39:37 +0100

And now a more detailed view on this:

Yes, a port number is effectively a layer 4 address, I think. Typically, 
ports are always active but are only used for services when an 
application (this includes the OS in some occasions, or even a dedicated 
IPMI endpoint co-located on the endpoint itself), which runs on an 
endpoint, binds them on a specific address. This includes, for example, 
the very ambiguous loopback addresses. There is a strong relationship 
between layer 4 port associations and endpoint security posture 
regarding software/applications.

I think it is important to capture and incorporate three concepts here:
- active ports can be bound only to a subset of the layer 3 addresses 
associated with an endpoint,
- addresses are always bound to specific interfaces, and
- interfaces (of various layers) have a relationships to each other 
(e.g. nested, bridged/forwarding).

Regarding security posture of an endpoint, it might be considered "okay" 
that a vulnerable application running on it is providing a service 
(thereby controlling a corresponding ingress listening port) via one of 
the many layer 3 addresses of the endpoint, because this specific 
address might be associated with an interface that is considered 
connected to an "inside" or "securely managed" network (and not to, 
e.g., an internet-facing interface). This is of course only true if 
there is no sophisticated packet mangling or frame forwarding done on 
the endpoint.

In essence, addresses (among other things) should be modeled in an 
unambiguous way to correctly associate security related data with them. 
Combining port and IP-address in an additional concept is one way to do 
it, but I am not sure that will eliminate ambiguousness in every case. 
Assigning artificially created identifiers to them would be an alternate 
route. We should discuss which further alternatives there are and which 
would work best for SACM, I think.

Cheers,

Henk

p.s. in hindsight my expression "to address network centric 
security/monitoring processes" seems to be quite misleading. It was not 
my intend to refer to a "network based attribute collector" but to local 
endpoint attributes regarding the interconnected relationship of the 
endpoint with its neighboring endpoints connected via the network.

---

From: Clifford Kahn <[email-masked]>
Date: Tue, 3 Feb 2015 19:58:14 +0000

Henk, 
Could you provide a small UML class diagram that will model active ports, addresses, interfaces, and the relationships among them that you would like to see modeled?  

Could you provide a short list of compliance monitoring goals served by this mini-model? 

I'd rather err with simplicity rather than with complexity. A simpler model would have no sessions and no interfaces, just:

          Endpoint ---------------------- Address
                           1                      *

An Address instance could be a layer 2 address (usually MAC), a layer 3 address (usually IP), a layer 4 address (usually IP:port), etc. 

I am trying to learn the advantages you see for SACM in your more sophisticated model.  

Thanks,
			Cliff

-----Original Message-----
From: Henk Birkholz [mailto:[email-masked]] 
Sent: Monday, February 02, 2015 9:40 AM
To: Clifford Kahn; [email-masked]
Subject: Re: [sacm] Comments on Network Interface

Cheers,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 4 Feb 2015 10:01:16 +0100

First of all, I have to say that it was not my initial intend to include 
Layer 4 addresses into the model at this point. That's why I did not 
include that concept in the small addition to section 4.10. My goal was 
simply to add some text that highlights the inherent complexity of the 
"class" Network Interface (and Network Address, analogously).

The first two examples below will show two simple scenarios that refer 
to the proposed additions to 4.10. The third example is intended as a 
first step towards answering and discussing your question about layer 4 
addresses, Cliff. It uses terminology from SCAP-AI. In general, the 
examples use instantiations of "classes" (the elements in the diagram) 
and only show the values of the TVP.

The representation used in the current draft:

       Endpoint----N.Interface----Address
               1  *           1  *

And a small (new) addition to represent nested interfaces corresponding 
to the proposed text:

                      +---+
                      |*  |1
       Endpoint----N.Interface----Address
               1  *           1  *

Example 1: "An endpoint for 'office use' must not forward frames from 
one network segment (l2 broadcast domain) to another" This is a common 
network security rule regarding network separation.

Endpoint attributes collected from a target endpoint (endpoint under 
assessment) in the current representation (I omitted the L2 addresses to 
keep it simple):

       L2Interface1
         |
         |
       EndpointA---BridgingVirtualInterface(BVI)
         |
         |
       L2Interface2

While the collected security posture attributes show that there is a 
virtual bridging interface, there is no data to show if this interface 
is actually bridging the two physical Interfaces. The existence of a 
virtual bridging interface on an "office endpoint" might be interpreted 
as potentially not "compliant".

Endpoint attributes collected from an endpoint under assessment with the 
addition of relationships between interfaces in the representation:

       L2Interface1
         |
         |
       EndpointA---BridgingVirtualInterface(BVI)
         |                |
         |                |
       L2Interface2-------+

While Interface2 is part of the bridge, Interface1 is not, and the 
endpoint is therefore "compliant". It might still also be a suspicious 
"office" endpoint due the uncommon use of a virtual bridging interface 
that has already one associated physical interface.

Example 2: "192.0.2.0/24 is an internal network using public addresses 
that must not be exposed to an 'outside' interface". This is also a 
common network security rule regarding network separation.

Endpoint attributes collected from a target endpoint in the current 
representation (I omitted the L2 addresses and L3 interfaces to keep it 
simple). L2Interface1 is the 'outside' interface:

       L2Interface1-----------123.123.12.12
         |
         | +----VLAN1 ID 10---192.0.2.114
         | |
         | | +--VLAN2 ID 20---203.0.113.1
         | | |
       EndpointA
         | | |
         | | +--VLAN3 ID 30---198.51.100.1
         | |
         | +----VLAN4 ID 40---172.21.11.114
         |
       L2Interface2-----------10.112.0.1

The collected endpoint attributes do not contain information about how 
the interfaces are associated with each other and it is not possible to 
discern if the virtual interface with the address in 192.0.2.0/24 is 
facing the 'outside' or the 'inside' network.

Endpoint attributes collected from a target endpoint with the addition 
of relationships between interfaces in the representation:

            +--VLAN2 ID 20----203.0.113.1
            |
       L2Interface1-----------123.123.12.12
         |  |
         |  +--VLAN4 ID 40----172.21.11.114
         |
       EndpointA
         |
         |  +--VLAN1 ID 10----192.0.2.114
         |  |
       L2Interface2-----------10.112.0.1
            |
            +--VLAN3 ID 30----198.51.100.1

In this endpoint attribute collection, virtual interfaces are now always 
associated with their corresponding physical interfaces. The endpoint is 
"compliant" due to VLAN3 ID 10 being associated with the inside 
interface and there being no virtual bridging interface that might 
forward frames to the 'outside' interface.

Example 3: "A proxy service must not be reachable from an outside 
network". This is a variation of Example 1 based on the following 
extended model, which - please mind - is not by any means meant to be a 
final proposal.

Active Ports could be modeled as attributes of the "class" Service, 
which is associated with the "class" Software Instance similar to 
SCAP-AI (this still ignores the ambiguousness of addresses):

                    +---+
                    |*  |1
       Endpoint----Interface----Address
          |1   1  *         1  *   |1
          |*                       |
       Software                    |*
       Instance-----------------Service
               1               *

Endpoint attributes collected from a target endpoint with the addition 
of relationships between interfaces and also the "class" Services in the 
representation (I omitted the L2 addresses and L3 interfaces to keep it 
simple), L2Interface2 is the 'outside' interface:

                          +-------------------------------Squid_Instance
                          |                                 |
                          |                                 |
       L2Interface1----EndpointA----BVI----192.0.2.114----Proxy_at_8080
                          |          |
                          |          |
                    L2Interface2-----+

The collected set of associated attributes shows that the only 
IP-address of the target endpoint is associated with the virtual 
bridging interface. The endpoint is not "compliant", because the proxy 
service provided by a running squid instance is reachable via the 
'outside' interface.

You could alternatively call the new element Port instead of Service, or 
include every active port of an l3 address in one instance of Service. 
Some might consider the introduction of Service scope creep.

In any case, I hope this - rather long, please excuse me - illustration 
conveys why a simplified abstraction of endpoint-addresses associations 
will not be able to correctly express desired states about network 
configuration.

IHTH,

Henk