[ 
https://issues.apache.org/jira/browse/HDDS-16308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dian-Xuan Yang updated HDDS-16308:
----------------------------------
    Description: 
h3. Problem
Wildcard addresses ({{0.0.0.0}}, {{::}}) and scoped IPs ({{fe80::1%eth0}}) are 
valid for _binding_, but must never be used as _advertised_ endpoints (peers, 
clients, Kerberos, or certificates). For instance, zone identifiers in scoped 
IPs cannot be encoded in an X.509 certificate.

A separate gap is the textual form of the configured value. Since HDDS-16307 an 
ambiguous authority no longer fails at startup; it resolves to a different 
address instead, so the misconfiguration is silent:

{code}
ozone.om.address = 2001:db8::1:9862

  intended:  host 2001:db8::1         port 9862
  actual:    host 2001:db8::1:9862    port 9862 (the default)
{code}

Both readings are valid IPv6 literals, so nothing in the value itself 
distinguishes them.

h3. Solution
Implement validation to reject wildcard, link-local, and scoped addresses for 
advertised endpoint settings.
* Reuse existing predicates ({{HddsServerUtil.isValidInetForCsr}} and 
{{isScopedOrMaskingIPv6Address}}).
* The error must explicitly name the offending property and value.
* Do not silently strip zone identifiers to force the address to be valid.
* Reject an unbracketed IPv6 literal in a host-and-port property. This is a 
check on the configured text, not on the resolved address: {{2001:db8::1:9862}} 
is itself a valid global unicast address, so both predicates above accept it. 
The error must show the bracketed form the operator most likely meant.

h3. Open Questions (Need Clarification)
# *Target Properties:* What is the exact set of advertised properties?
(_Proposal: Include peer/client keys like {{ozone.om.address}}, 
{{ozone.scm.client.address}}, {{ozone.scm.names}}, SCM/OM HA per-node keys, and 
{{hdds.datanode.hostname}}. Exclude all {{*.bind.host}} keys since wildcards 
are legitimate there._)
# *Failure Timing:* Should an invalid advertised address fail fast immediately 
at startup, or only later at the point of registration/publication?
# *Bare IPv6 Literals in Host-and-Port Keys:* Should a property such as 
{{ozone.om.address}} accept a bare IPv6 literal at all? The OEP allows a bare 
literal only for host-only configuration, and requires brackets wherever a port 
may follow. Accepting both forms is exactly what makes the example above 
ambiguous. Requiring brackets removes the ambiguity, at the cost of rejecting 
{{ozone.om.address=::1}}, which parses today.

h3. Testing
Add component tests for the agreed set of properties to verify:
* *Accepted:* DNS names, IPv4 literals, global IPv6 literals.
* *Rejected:* Wildcard, link-local, and scoped addresses.
* *Rejected:* Unbracketed IPv6 authorities such as {{2001:db8::1:9862}}.

h3. Related
The SPNEGO principal for a wildcard bind host is a different problem and is 
tracked separately. With a {{::}} bind host, {{HttpServer2.Builder.build()}} 
falls back to the first endpoint's host, so {{_HOST}} expands to a bracketed 
wildcard and no keytab matches. That fix has to decide what {{_HOST}} should 
resolve to, rather than reject a configured value.

  was:
h3. Problem
Wildcard addresses ({{0.0.0.0}}, {{::}}) and scoped IPs ({{fe80::1%eth0}}) are 
valid for _binding_, but must never be used as _advertised_ endpoints (peers, 
clients, Kerberos, or certificates). For instance, zone identifiers in scoped 
IPs cannot be encoded in an X.509 certificate.

h3. Solution
Implement validation to reject wildcard, link-local, and scoped addresses for 
advertised endpoint settings.
* Reuse existing predicates ({{HddsServerUtil.isValidInetForCsr}} and 
{{isScopedOrMaskingIPv6Address}}).
* The error must explicitly name the offending property and value.
* Do not silently strip zone identifiers to force the address to be valid.

h3. Open Questions (Need Clarification)
# *Target Properties:* What is the exact set of advertised properties? 
(_Proposal: Include peer/client keys like {{ozone.om.address}}, 
{{ozone.scm.client.address}}, {{ozone.scm.names}}, SCM/OM HA per-node keys, and 
{{hdds.datanode.hostname}}. Exclude all {{*.bind.host}} keys since wildcards 
are legitimate there._)
# *Failure Timing:* Should an invalid advertised address fail fast immediately 
at startup, or only later at the point of registration/publication?

h3. Testing
Add component tests for the agreed set of properties to verify:
* *Accepted:* DNS names, IPv4 literals, global IPv6 literals.
* *Rejected:* Wildcard, link-local, and scoped addresses.


> Validate advertised addresses before startup, registration, and publication
> ---------------------------------------------------------------------------
>
>                 Key: HDDS-16308
>                 URL: https://issues.apache.org/jira/browse/HDDS-16308
>             Project: Apache Ozone
>          Issue Type: Sub-task
>            Reporter: Dian-Xuan Yang
>            Assignee: Dian-Xuan Yang
>            Priority: Major
>
> h3. Problem
> Wildcard addresses ({{0.0.0.0}}, {{::}}) and scoped IPs ({{fe80::1%eth0}}) 
> are valid for _binding_, but must never be used as _advertised_ endpoints 
> (peers, clients, Kerberos, or certificates). For instance, zone identifiers 
> in scoped IPs cannot be encoded in an X.509 certificate.
> A separate gap is the textual form of the configured value. Since HDDS-16307 
> an ambiguous authority no longer fails at startup; it resolves to a different 
> address instead, so the misconfiguration is silent:
> {code}
> ozone.om.address = 2001:db8::1:9862
>   intended:  host 2001:db8::1         port 9862
>   actual:    host 2001:db8::1:9862    port 9862 (the default)
> {code}
> Both readings are valid IPv6 literals, so nothing in the value itself 
> distinguishes them.
> h3. Solution
> Implement validation to reject wildcard, link-local, and scoped addresses for 
> advertised endpoint settings.
> * Reuse existing predicates ({{HddsServerUtil.isValidInetForCsr}} and 
> {{isScopedOrMaskingIPv6Address}}).
> * The error must explicitly name the offending property and value.
> * Do not silently strip zone identifiers to force the address to be valid.
> * Reject an unbracketed IPv6 literal in a host-and-port property. This is a 
> check on the configured text, not on the resolved address: 
> {{2001:db8::1:9862}} is itself a valid global unicast address, so both 
> predicates above accept it. The error must show the bracketed form the 
> operator most likely meant.
> h3. Open Questions (Need Clarification)
> # *Target Properties:* What is the exact set of advertised properties?
> (_Proposal: Include peer/client keys like {{ozone.om.address}}, 
> {{ozone.scm.client.address}}, {{ozone.scm.names}}, SCM/OM HA per-node keys, 
> and {{hdds.datanode.hostname}}. Exclude all {{*.bind.host}} keys since 
> wildcards are legitimate there._)
> # *Failure Timing:* Should an invalid advertised address fail fast 
> immediately at startup, or only later at the point of 
> registration/publication?
> # *Bare IPv6 Literals in Host-and-Port Keys:* Should a property such as 
> {{ozone.om.address}} accept a bare IPv6 literal at all? The OEP allows a bare 
> literal only for host-only configuration, and requires brackets wherever a 
> port may follow. Accepting both forms is exactly what makes the example above 
> ambiguous. Requiring brackets removes the ambiguity, at the cost of rejecting 
> {{ozone.om.address=::1}}, which parses today.
> h3. Testing
> Add component tests for the agreed set of properties to verify:
> * *Accepted:* DNS names, IPv4 literals, global IPv6 literals.
> * *Rejected:* Wildcard, link-local, and scoped addresses.
> * *Rejected:* Unbracketed IPv6 authorities such as {{2001:db8::1:9862}}.
> h3. Related
> The SPNEGO principal for a wildcard bind host is a different problem and is 
> tracked separately. With a {{::}} bind host, {{HttpServer2.Builder.build()}} 
> falls back to the first endpoint's host, so {{_HOST}} expands to a bracketed 
> wildcard and no keytab matches. That fix has to decide what {{_HOST}} should 
> resolve to, rather than reject a configured value.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to