Port ranges should be limited to OS port limits

[IvanDrag0]

Describe the bug

Currently, the OSCAL schema allows the user to add a network port range (part of the oscal-implementation-common) model. However, an OS (Windows and Linux) has a logical port range of 0-65535, while the schema allows for any number. The schema should be edited to bound the port range to what an OS can utilize.

Who is the bug affecting

Component and POAM writers. This "bug" is more of a sanity check than anything else.

What is affected by this bug

Metaschema, Modeling

How do we replicate this issue

Set the protocol port range to any number.

Expected behavior (i.e. solution)

The protocol port range should only allow whole numbers between 0 and 65535.

Other comments

No response

Revisions

No response

[GaryGapinski]

This is an apt observation.

I will add that the "obvious" reserved ports (see IANA Service Name and Transport Protocol Port Number Registry) should be excluded (namely, 0, 1023, 1024, 49151). I say "obvious" because other port reservations are dependent on transport type as well as historic IANA actions.

See also #1674.

[IvanDrag0]

So does that mean that the current OSCAL schema already support this feature? Since #1674 has been merged.

Except port 0 (since it's a wildcard port), I don't think it would be a good idea to exclude known protocols since some systems could use those ports for something else (even though they shouldn't).

Also, I'm not sure if it's possible to do with a JSON/XML schema, but adding a check to make sure that multiple components dont have the same ports/port ranges, might be a good idea.

[GaryGapinski]

So does that mean that the current OSCAL schema already support this feature? Since #1674 has been merged.

As of pre-release v1.0.5 there are no [edit: additional] constraints — in the schema — on start and end.

Placing the constraints I mentioned is possible.

[GaryGapinski]

Also, I'm not sure if it's possible to do with a JSON/XML schema, but adding a check to make sure that multiple components dont have the same ports/port ranges, might be a good idea.

Such is not possible with a simple schema. It is possible using Schematron for XML.

Components may share port usage. For example, multiple components using the HTTPS protocol might all declare the use of port 443.

Worthy of note:component/protocol/port-range does not denote the nature (client or service) of the component.

[IvanDrag0]

Worthy of note:component/protocol/port-range does not denote the nature (client or service) of the component.

This is actually a good point. With the current rise of web-based applications and interfaces, it might be a good idea to include a client/server tag and/or add network direction (ingress/egress/both).

[brian-ruf]

I just came across this thread while researching an unrelated port start/end issue.

While I can agree with the idea of limiting ports to only those possible in the IP specification (0 - 65,535), I want to caution that the IANNA registry is to govern the public Internet. It is possible that private, air-gapped networks are using those reserved ports without issue, and would still need to document them via OSCAL.

When limiting ports, please stick only to the IP spec as originally suggested by @IvanDrag0 .

[IvanDrag0]

Hi @brian-ruf,

Thank you for taking a look at the issue. When you mention "reserved ports", are you referring to ports above 65,535? Since a TCP/UDP port is an unsigned integer, it has a maximum of 65,535. Anything above that would not be an unsigned integer and the OS will not be able to process it.

[aj-stein-gsa]

I just came across this thread while researching an unrelated port start/end issue.

While I can agree with the idea of limiting ports to only those possible in the IP specification (0 - 65,535), I want to caution that the IANNA registry is to govern the public Internet. It is possible that private, air-gapped networks are using those reserved ports without issue, and would still need to document them via OSCAL.

@brian-ruf, how could you use reserved or IANA specifications that are not within the IPv4 specification limit of those ranges? Or are we talking about the protocol/@name flag here and I got confused by the implication here?

[brian-ruf]

I was agreeing the OSCAL spec should constrain the port values to the IP spec of 0 - 65,535. Full stop.

I was expressing concern with the suggestion that the OSCAL spec also probits the use of IANNA reserved port numbers.

I do not agree with OSCAL syntax validation blocking IANNA reserved ports in the port field for several reasons.

The SSP and AR are for documenting actual configuration of a system.

There is a small chance air gapped or non-Internet routed networks are not compliant with IANNA. They don't need to be. OSCAL syntax should not block the accurate documentation of these networks.

Also, a system may be configured and functioning, while inadvertantly using an IANNA reserved port. OSCAL validation rules should not block content authors from reporting this in SSP or AR content.

Finally, those ports are reserved for a reason. They are only to be used in certain circumstances that don't apply to most systems. But, there may be a system that needs to use them for that reserved purpose. OSCAL syntax enforcement shouldn't block this.

Again, I 100% support a constraint that limits the port field values to the range 0 - 65,535, but view additional blocking of IANNA reserved port enforcement as an over-reach for OSCAL syntax validation.

[aj-stein-gsa]

I was agreeing the OSCAL spec should constrain the port values to the IP spec of 0 - 65,535. Full stop.

OK, thanks for confirming.

I was expressing concern with the suggestion that the OSCAL spec also probits the use of IANNA reserved port numbers.

I do not agree with OSCAL syntax validation blocking IANNA reserved ports in the port field for several reasons.

The SSP and AR are for documenting actual configuration of a system.

There is a small chance air gapped or non-Internet routed networks are not compliant with IANNA. They don't need to be. OSCAL syntax should not block the accurate documentation of these networks.

That is understandable, but that rationale over-extends what IANA (and IETF RFC 6335) document as reasons for reserved ports without registered port numbers and/or protocol names; you they do not necessarily only occur in air-gapped or other than those protocols that not routed on Internet.

o Reserved: Reserved port numbers are not available for regular
assignment; they are "assigned to IANA" for special purposes.
Reserved port numbers include values at the edges of each range,
e.g., 0, 1023, 1024, etc., which may be used to extend these
ranges or the overall port number space in the future.

In order to keep the size of the registry manageable, IANA typically
only records the Assigned and Reserved service names and port numbers
in the registry. Unassigned values are typically not explicitly
listed. (There are very many Unassigned service names and
enumerating them all would not be practical.)

That said, given what you did write here, the rationale does not matter. I agree to your point here. It would seem, having the name flag for a given protocol as required, separating of defining any port range is part of the issue at hand here. Anything service can use a port with the 16-bit range allowed by TCP/UDP/transport protocols inside of IPv4 and IPv6, so we should not force a name. The documents indicate that is commonly the IANA service name. That, or in OSCAL we have people add superfluous names like "other" or "private" or "reserved" without merit.