Port ranges should be limited to OS port limits #1772
Comments
|
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. |
|
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. |
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: |
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). |
|
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 . |
|
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. |
@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 |
|
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. |
OK, thanks for confirming.
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.
That said, given what you did write here, the rationale does not matter. I agree to your point here. It would seem, having the |
Per discussion with community members and the nature of port, protocol, and service declarations in a OSCAL SSP model instances for RMF use cases, like FedRAMP and others. It would appear the model, per the Metaschema declarations and documentation, require a port range has a name that is commonly the IANA service name, which should be optional. Otherwise, developers and security officials will need to create an arbitrary name that does not strictly conform to the documentation. More details can be found in the issue thread referenced below by URL. usnistgov#1772 (comment)
|
For others interested in this topic and a possible fix that is conducive to comments made above, I have proposed #2069 for consideration as part of a possible patch release (e.g. 1.1.3 release). |
Per discussion with community members and the nature of port, protocol, and service declarations in a OSCAL SSP model instances for RMF use cases, like FedRAMP and others. It would appear the model, per the Metaschema declarations and documentation, require a port range has a name that is commonly the IANA service name, which should be optional. Otherwise, developers and security officials will need to create an arbitrary name that does not strictly conform to the documentation. More details can be found in the issue thread referenced below by URL. usnistgov#1772 (comment)
Per discussion with community members and the nature of port, protocol, and service declarations in a OSCAL SSP model instances for RMF use cases, like FedRAMP and others. It would appear the model, per the Metaschema declarations and documentation, require a port range has a name that is commonly the IANA service name, which should be optional. Otherwise, developers and security officials will need to create an arbitrary name that does not strictly conform to the documentation. More details can be found in the issue thread referenced below by URL. #1772 (comment)
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
The text was updated successfully, but these errors were encountered: