Clarify ipv4_connection and ipv6_connection

[alevere]

This section should be clarified as the way it is written is ambiguous regarding what fields are to be sent (or not), especially with ICMP. Since this is specified at the language spec, we should provide and example and clarify say send the ICMP type number in the src_port field. For other protocols, maybe do not send the unused fields at all.

ipv4_connection If the protocol = ICMP, the five-tuple is: src_addr, dst_addr, icmp_type, icmp_code, protocol where the ICMP types and codes are defined in [RFC2780] If the protocol = TCP, UDP or SCTP, the five-tuple is: src_addr, src_port, dst_addr, dst_port, protocol For any other protocol, the five-tuple is: src_addr, unused, dst_addr, unused, protocol

same goes for ipv6

[alevere]

Also, what should occur if protocol is not set, but port(s) are? Should protocol be an integer or String? What occurs if an actuator doesnt support SCTP or ICMP

[jmbrule]

Regarding the question 'what occurs if an actuator doesn't support SCTP or ICMP'. We are making a filtering decision based on whether or not the packet presented to it is in fact an ICMP packet (or not), so the notion of 'an actuator doesn't support SCTP or ICMP' should not matter? That is, you dont need to support a protocol to base a filtering decision on whether or not the packet originated from a node that is using ICMP.

[jmbrule]

If a deny is issued and the protocol is not set, but the ports are set, then it seems that a packet that matches the port should be denied regardless of the protocol setting (in the packet being evaluated)

[Vasileios-Mavroeidis]

This issue would also be solved if we can get a schema with the exact requirements of action/target pairs from the actuator.

Nevertheless, the protocol "any" is a bit problematic. One solution would be to have the protocol required. The simplest example that I can think of is: deny ipv4_connection with only the IP addresses populated. Undefined protocol would mean that at least tcp, udp, and icmp rules would be submitted. deny ipv4_connection with IP addresses and a port populated would mean that at least tcp and udp is populated, and an icmp rule is not possible since ports are defined. Btw, in the first case, i didnt want to submit an ICMP firewall rule, but it could pass since the minimum that you want for an ICMP rule is IP addresses.

So if we want to keep the protocol any (for me doesn't make that much sense, this helps only in the traditional cases (which yes I agree are the most) that we want to allow or block an IP address and we want both a tcp and udp rule. The advantage is that we would need one openc2 command for that. The same command though also entails quite many disadvantages.

In addition, when we include requirements, of how to populate the tuple in each protocol, the protocol "any" still doesn't make that much sense because we are explicitly saying that each protocol has different requirements. The any would be ok in cases that the tuple of the 5 elements no matter what can be understood by the protocol, and that each protocol perceives the 5 tuple in a similar way.

[davaya]

The current (CS02) language schema is https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/Schemas/Combined/IDL/oc2ls-v1.0.1_gen.jidl (or its equivalent in Markdown property tables, JADN source, or JSON Schema).

There isn't an "any" in the schema itself. The text in section 3.2.4.10 "Value of the protocol (IPv4) or next header (IPv6) field in an IP packet. Any IANA value, [RFC5237]" is intended to mean that the schema can be modified to include any IANA-registered protocol value, not that the current schema would accept anything other than the 4 defined values. (The "protocol" field in section 3.4.1.10 is optional, which if omitted might be interpreted as "any", but the LS currently doesn't say.)

I haven't reviewed the SLPF spec CS01 recently, but the section 2.1.2.1 text is incompatible with the Language Spec. The LS defines the IP Connection target, and SLPF cannot arbitrarily change the definition to say "If the protocol = ICMP, the five-tuple is: src_addr, dst_addr, icmp_type, icmp_code, protocol where the ICMP types and codes are defined in [RFC2780]". If the SLPF needs a different target, it will need to define a new one itself, or add a new target to the LS.

Note, "L4-Protocol" is currently defined as a string, because it is type "Enumerated", which means the value is taken from the Name column. If it were type Enumerated.ID, the value would be taken from the ID column.

Dave

On Wed, Feb 12, 2020 at 6:16 AM Vasileios Mavroeidis < notifications@github.com> wrote:

This issue would also be solved if we can get a schema with the exact requirements of action/target pairs from the actuator.

Nevertheless, the protocol "any" is a bit problematic. One solution would be to have the protocol required. The simplest example that I can think of is: deny ipv4_connection with only the IP addresses populated. Undefined protocol would mean that at least tcp, udp, and icmp rules would be submitted. deny ipv4_connection with IP addresses and a port populated would mean that at least tcp and udp is populated, and an icmp rule is not possible since ports are defined. Btw, in the first case, i didnt want to submit an ICMP firewall rule, but it could pass since the minimum that you want for an ICMP rule is IP addresses.

So if we want to keep the protocol any (for me doesn't make that much sense, this helps only in the traditional cases (which yes I agree are the most) that we want to allow or block an IP address and we want both a tcp and udp rule. The advantage is that we would need one openc2 command for that. The same command though also entails quite many disadvantages.

In addition, when we include requirements, of how to populate the tuple in each protocol, the protocol "any" still doesn't make that much sense because we are explicitly saying that each protocol has different requirements. The any would be ok in cases that the tuple of the 5 elements no matter what can be understood by the protocol, and that each protocol perceives the 5 tuple in a similar way.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter/issues/119?email_source=notifications&email_token=AESEALFKYKNF4WJDHVXQ4L3RCPK7PA5CNFSM4KTEGGH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELQMYEA#issuecomment-585157648, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESEALEGZYGV4KKGCWRDVSLRCPK7PANCNFSM4KTEGGHQ .

[Vasileios-Mavroeidis]

I see what you are saying Dave. This is the reason I suggested the “protocol” field to be required. Then the requirements for each protocol regarding the construction of the 5-tuple make sense to exist. The other field, except the protocol could be treated as any when they are not populated. I find the requirements for each portal specified in SLPF reasonable and actually quite important. So I suggest transferring them in the language spec.

-Vasileios

[davaya]

I agree.

The logical way to structure that would be to parallel the IP stack - "protocol" is in the IP header, and the other fields are in the next header as determined by "protocol". The schema for that would look like:

IPv4-Selector = Choice {
   1 icmp      ICMPv4-Selector,
   6 tcp       TCPv4-Selector,
  17 udp       UDPv4-Selector,
 132 sctp      SCTP-Selector
}

ICMPv4-Selector = Record {
   1 src_addr  IPv4-Addr optional,
   2 dst_addr  IPv4-Addr optional,
   3 type      ICMP-Type optional,
   4 code      ICMP-Code optional
}

TCPv4-Selector = Record {
   1 src_addr  IPv4-Addr optional,
   2 src_port  Port optional,
   2 dst_addr  IPv4-Addr optional,
   3 dst_port  Port optional
}

We'd have to declare a new OpenC2 major version if we decided to change the definition of IP-Connection. Fortunately, it's mis-named anyway (udp and icmp are not connection-oriented protocols), and SLPF uses these to select which packets to filter. So it's easy to define a new target with a new name without breaking compatibility.

[Vasileios-Mavroeidis]

sounds logical. That way we are more structured than what I suggested. My way was just an improvement in the SLPF. Your way solves the problem of extensibility and syntax for any additional protocol at the language spec. Very nice 👍

[jmbrule]

I actually like the approach but I have a pragmatic concern, Question: What sort of guidance do we give profile writers if their actuator uses a protocol that is not widely deployed? There are in excess of a 100 in use. Will we require ALL of these to be exported to the language spec? Even if it is not widely used?

In the SLPF we stated that the five tuple is src, address, src port, dest address, dst port and next protocol then we spelled out an exception if it was ICMP, then the five tuple is what davaya has listed in the ICMP selector.

I will grant you that it is not as 'pure' of a solution, but it is simpler, does push the complexity and details to the profiles. The academically pure solution adds a layer of complexity to the lang spec.

Thoughts?