Actuator Profile Subcommittee,
Vasileios Mavroeidis from the University of Oslo identified a need for an ICMP target type in the SLPF. The ip_connection target type with the protocol field
set to â1â is insufficient because it will not include the ICMP types.
I will take the liberty of cooking up a pull request to include an ICMPv4 and v6 targets.
VR
Joe Brule
-Vasileios
On Feb 11, 2019 4:51 PM, "Brule, Joseph M" <jmbrule@radium.ncsc.mil> wrote:
In the context of the file target, you are correct. I will wordsmith something and bounce it off the subcommittee, but nobody should argue with logic.
In the context of ICMP, My original logic (or lack thereof) was along the lines that in the five tuple accommodates src addy, dest addy, source port, dest port and protocol, so
if you wanted to block (or allow) ICMP, you set the protocol field to â1â. I failed to consider that we will want to be able to block or allow specific ICMP messages. Oooooops!
I think the best way to handle it is put two targets in table 2.1.2.2. call it something like slpf:icmpv4 and slpf:icmpv6 with properties of the ip address and the ICMP ID.
Sound logical to you?
From: Everett, Alex D <alex.everett@unc.edu>
Sent: Saturday, February 9, 2019 12:05 PM
To: Vasileios Mavroeidis <vasileim@ifi.uio.no>; Brule, Joseph M <jmbrule@radium.ncsc.mil>
Cc: Vasileios Mavroeidis <vasileim@ifi.uio.no>
Subject: [Non-DoD Source] Re: Regarding the OpenC2 SLPF
I also think there is a little use case for allow/deny icmp codes; need the ones for ipv6 too.
Could have that in ipconn fields, seems simple.
From: Vasileios Mavroeidis <vasileim@ifi.uio.no>
Sent: Saturday, February 9, 2019 11:48 AM
To: jmbrule@radium.ncsc.mil
Cc: Vasileios Mavroeidis; Everett, Alex D
Subject: Re: Regarding the OpenC2 SLPF
Hello all,
Joe, I just read your ânew pull requestâ. I think the specification overall is really better now. Great work. Well explained. I guess the explanation of OpenC2 commands in 2.3 is good enough to easily understand the difference between ipv4_net vs ipv4_connection.
I made a pull request to your doc in your repository (some minor corrections - maybe it will save some time).
I have another 2 minor concerns regarding the specification.
First regarding the file target. The name is required but not the path. In my mind by giving the complete path of a file (last / with the file name) will mitigate any problems regarding having 2 files with the same name in an environment. In any case its
not important.
Important is how do we handle the ICMP protocol. Why? ICMP is used in many operations and not only to ping appliances or giving simple responses back. In IPV6 it is used to assign IPV6 addresses to end points ( e.g., router advertisement and router solicitation).
Do we specify those as extra arguments if we want to block specific IDs?
This is something standardised and maybe it should be taken into consideration.
Vasileios Mavroeidis â Research Fellow
Research Group of Information and Cyber Security
SecurityLab
University of Oslo
+47 40347666
+44 7490469651
Alex, Vasileios,
I have put some thought in this, and simply stated, I do not think that we can go with the notion of treating 'ip_addr' as a special case of 'ip_connection'. The fundamental problem is, the elements within the ip_connection are logical 'OR's and we need a
way to communicate 'source ip address' AND 'destination address'. I really could not come up with a way to do this other than cooking up some sort of kluge, which in my opinion will come back to bite us.
The lang spec created an 'ipv4_net' and 'ipv6_net' targets which more or less accomplish what the old ip_addr did.
I created a pull request that defines a whole bunch of conformance profiles (A total of 22) because Duncan does not want the orchestrators to have to handle more than one target and he does not want a 'complete' vs 'basic' profile. The only way I could accommodate
was to create a unique profile for each optional command.
I wanted you to be in the loop.
VR
Joe Brule
Engineering (Y2D122)
FNX-3, B4A335
410.854.4045
'Adnius ad retinedam puritem noster peciosus corporalis fluidorum...'
I welcome VSRE emails. Learn more at http://vsre.info/
|