Clarify if "L4 Protocol" is limited to cited values

[dlemire60]

Section 3.4.2.10 describes L4 Protocol as "Value of the protocol (IPv4) or next header (IPv6) field in an IP packet", and provides a table that enumerates 4 values (icmp, tcp, udp, sctp). The IANA registry of protocol values currently contains 143 assigned values. The LS should be clear if any IANA-registered value is allowed for L4 Protocol, or if only values specifically enumerated in the LS are permitted.

(source: HII software team)

[dlemire60]

Reviewing the text of section 3.4.2.10, it reads:

Value of the protocol (IPv4) or next header (IPv6) field in an IP packet. Any IANA value, [RFC5237]

However, RFC 5237 is a procedural RFC that "revises the IANA guidelines for allocating new Protocol field values in the IPv4header." If the usage is "any IANA value", I believe the text should be revised to reference the "Assigned Internet Protocol Numbers" list, which records all of the assigned values for for the IPv4 Protocol / IPv6 Next Header fields. This should be handled with a new normative reference that points to the AIPN list.

The text above is followed by a table with four specific protocols enumerated (the enumeration numbers in the table match the IANA protocol list). Given the "any IANA value", I believe the table is illustrative rather than definitive, but this creates the problem of how does the LS reference an external source for the values of an enumeration? I don't think we want to directly incorporate the IANA list into the LS. However, it probably needs to somehow be ingested into the JADN-based schema called for in issue #361.

[dlemire60]

This was discussed at the 8/3 working meeting, and there was consensus that the value isn't restricted to the enumeration in the LS and referencing the IANA registry is the appropriate solution. This has two dimensions:

• properly referencing the IANA registry (which is online and doesn't have version numbers) within the LS
• automation needed to incorporate the relevant registry content in the JADN when developing schemas for the LS

This is labeled address_in_next_vrsn but is actually relevant when the TC is ready to publish a schema with the LS (which is hopefully the next version)

[dlemire60]

I went looking for a similar example at OASIS and found something in the STIX 2.1 spec, referencing IANA's port numbers registry:

[Port Numbers] J.Touch, A. Mankin, E. Kohler, et. al., “Service Name and Transport Protocol PortNumber Registry”, IANA, January 2017. [Online]. Available:http://www.iana.org/assignments/service-names-port-numbers/service-namesport-numbers.xhtml[

and uses that reference in specifying “protocols”:

The protocol names SHOULD come from the service names defined in the Service Name column of the IANA Service Name and Port Number Registry [Port Numbers]. In cases where there is variance in the name of a network protocol not included in the IANA Registry, content producers should exercise their best judgement, and it is recommended that lowercase names be used for consistency with the IANA registry.

No versioning is mentioned. The reference cites January 2017, buy If you follow the link, you get the current registry, which happens to have been updated this week (2022-08-08).

We need to reference the IANA registry of protocol values, similar to how STIX references port numbers. I think we also need to

1. define L4-Protocol as an enumeration from 0-255, because it's an 8-bit field
2. define the interpretation of that field as being defined in the referenced registry

We could include language to scope the interpretation along the lines of

"... MUST support values recorded in the registry as of the publication date of this specification, and MAY support any value currently recorded in the registry."

but I don't really think it's necessary. STIX imposed no such restrictions.

[dlemire60]

Addressed by PR #405, which has been merged, so closing this issue.