xds: listener type validation #11933

shivaspeaks · 2025-03-03T07:24:13Z

Fixes #11737

xds/src/test/java/io/grpc/xds/XdsServerTestHelper.java

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

ejona86

Sorry, I didn't mean to approve

ejona86 · 2025-03-06T21:11:53Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+      InetAddress listenerIp = InetAddresses.forString(listenerAddressHnP.getHost());
+      InetAddress ldsIp = InetAddresses.forString(ldsAddressHnP.getHost());
+
+      if (listenerIp.isAnyLocalAddress()) {


As I said before, remove the wildcard handling. IPv4 and IPv6 wildcards behave differently, and you aren't checking the port here. And if we need to be comparing wildcards, we would really need to spell out how that is done in the gRFC to be consistent cross-language.

danielzhaotongliu · 2025-03-06T23:54:47Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+        return;
+      }
+
+      String ldsAddress = update.listener().address();


For my education: what would be the "best/most appropriate" behaviour if the String ldsAddress is the empty string or null?

Currently, if ldsAddress is null, we skip ipAddressesMatch entirely and proceed with the remaining logic. Would this still be fine?

Likewise, if ldsAddress is the empty string, we check ipAddressesMatch, AFAIK, this would throw an exception and would this be fine? HostAndPort.fromString would return a HostAndPort(host="", port=-1, hasBracketlessColons=false) then InetAddresses.forString would throw an IllegalArgumentException

Hmmm. Good point. I couldn't find any mention about this case in gRFC A36.

ldsAddress == null means (based on XdsListenerResource) that the address type was not a SocketAddress, which is covered in the gRFC.

In most NR/LB logic, exceptions cause the channel to go into panic mode. NR/LB should only throw in case of a bug.

Empty address is disallowed in the proto, but is not in our validation so we should add validation. The ip matching logic here should also be checking that it is a TCP listener, which is not being communicated through EnvoyServerData.Address.

And the validation should probably be NACKing (throw ResourceInvalidException) NAMED_PORT as gRPC does not support resolver_name, which is mentioned as being required to use it in its documentation.

How do we check if it is a TCP listener?

if ("raw_buffer".equals(update.listener().filterChains().get(0).filterChainMatch().transportProtocol())) this could tell us but I'm not very sure about this. I could have pasted the above condition with default filter chain but that is a Nullable field.

This gRPC code is always TCP. So we need to not match when xDS tells us to use UDP.

The transport protocol doesn't seem to be about TCP vs UDP. That's raw_buffer or tls: the higher-level protocol. And that is part of filter chain matches; used to select which filter chain to use. You should never loop through all the matchers and then copy details about it to other matchers.

We were talking about the address, and SocketAddress has a TCP vs UDP protocol.

Got it.

You said we need not match addresses when it's UDP, so I assume we don't call handleConfigNotFoundOrMismatch when it's UDP and continue?

I don't understand. If you don't call handleConfigNotFoundOrMismatch, that's the same as matching... If !ipAddressesMatch() you call handleConfigNotFoundOrMismatch. Why would you not call it?

Yep. I was thinking right at first before editing the comment and then I messed up with thoughts.

danielzhaotongliu · 2025-03-07T00:09:22Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

    @Override
    public void onResourceDoesNotExist(final String resourceName) {
      if (stopped) {
        return;
      }
      StatusException statusException = Status.UNAVAILABLE.withDescription(
-          String.format("Listener %s unavailable, xDS node ID: %s", resourceName,
+          String.format("%s listener unavailable, xDS node ID: %s", resourceName,


nit: what would be the reason to switch the order of the error format here? I think Listener %s is slightly more common in the code base. Consistent formatting helps with searching when debugging issues.

ejona86

I found these comments laying around. I don't know why I didn't send it out earlier.

ejona86 · 2025-03-12T14:46:28Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+
+      InetAddress listenerIp = InetAddresses.forString(listenerAddressHnP.getHost());
+      InetAddress ldsIp = InetAddresses.forString(ldsAddressHnP.getHost());
+      if (ldsAddressHnP.hasPort() && listenerAddressHnP.hasPort()


If the address doesn't have a port, fail the match.

ejona86 · 2025-03-12T16:32:21Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+        return;
+      }
+
+      String ldsAddress = update.listener().address();


This gRPC code is always TCP. So we need to not match when xDS tells us to use UDP.

ejona86 · 2025-03-18T20:28:37Z

xds/src/main/java/io/grpc/xds/XdsListenerResource.java

@@ -165,6 +165,12 @@ static EnvoyServerProtoData.Listener parseServerSideListener(
    if (proto.getAddress().hasSocketAddress()) {
      SocketAddress socketAddress = proto.getAddress().getSocketAddress();
      address = socketAddress.getAddress();
+      if (address.trim().isEmpty()) {


Remove the trim().

ejona86 · 2025-03-18T20:29:51Z

xds/src/main/java/io/grpc/xds/XdsListenerResource.java

+        throw new ResourceInvalidException("Invalid address: Empty address is not allowed.");
+      }
+      if (socketAddress.hasNamedPort()) {
+        throw new ResourceInvalidException("NAMED_PORT is not supported in gRPC.");


Move this to the switch? Or delete the NAMED_PORT case in the switch; it is dead code and misleading.

ejona86 · 2025-03-18T20:39:11Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+        return;
+      }
+
+      String ldsAddress = update.listener().address();


The transport protocol doesn't seem to be about TCP vs UDP. That's raw_buffer or tls: the higher-level protocol. And that is part of filter chain matches; used to select which filter chain to use. You should never loop through all the matchers and then copy details about it to other matchers.

We were talking about the address, and SocketAddress has a TCP vs UDP protocol.

shivaspeaks · 2025-03-19T16:38:50Z

cronet/build.gradle

@@ -57,7 +57,7 @@ dependencies {

 task javadocs(type: Javadoc) {
    source = android.sourceSets.main.java.srcDirs
-    classpath += files(android.getBootClasspath())
+    // classpath += files(android.getBootClasspath())


I'll uncomment this in the next commit.

ejona86 · 2025-03-19T17:11:52Z

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java

+      }
+
+      String ldsAddress = update.listener().address();
+      if (ldsAddress != null && update.listener().protocol() == Protocol.TCP


From gRFC A36:

To be useful, the xDS-returned Listener must have an address that matches the listening address provided. The Listener's address would be a TCP SocketAddress with matching address and port_value. The XdsServer must be "not serving" if the address does not match.

If ldsAddress == null, then there was not a (supported) address and it should not be serving. If the protocol is not TCP then it should not be serving.

This means that every place in our tests that calls Listener.newBuilder() needs to set the address.

larry-safran · 2025-03-20T09:23:21Z

While it is in the gRFC, why is it really important to enforce a returned address being non-null? This doesn't seem to really provide value as the address was already known for communicating to the xds server in the first place.

shivaspeaks added 4 commits February 17, 2025 16:48

XdsNameResolver and XdsServerWrapper checks listener type

4eb625a

XdsNameResolver and XdsServerWrapper check listener type

ad90963

xds listener type validation

01927a6

xds listener type validation

8780c52

shivaspeaks changed the title ~~Listener type validation~~ xds: listener type validation Mar 3, 2025

shivaspeaks requested a review from ejona86 March 3, 2025 15:25

ejona86 approved these changes Mar 5, 2025

View reviewed changes

xds/src/test/java/io/grpc/xds/XdsServerTestHelper.java Outdated Show resolved Hide resolved

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java Show resolved Hide resolved

xds/src/main/java/io/grpc/xds/XdsServerWrapper.java Outdated Show resolved Hide resolved

ejona86 self-requested a review March 5, 2025 21:20

ejona86 reviewed Mar 5, 2025

View reviewed changes

Address comments

76270a4

shivaspeaks added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Mar 6, 2025

shivaspeaks and others added 2 commits March 6, 2025 20:44

Address comments

da0d5ab

Merge branch 'master' into listener-type-validation

ba8af22

grpc-kokoro removed the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Mar 6, 2025

shivaspeaks requested a review from ejona86 March 6, 2025 20:52

ejona86 reviewed Mar 6, 2025

View reviewed changes

Pull from master

694c2f1

danielzhaotongliu reviewed Mar 7, 2025

View reviewed changes

shivaspeaks added 3 commits March 7, 2025 14:42

remove wildcard handling

506bbe4

rebase

87aad6f

typo

239f167

shivaspeaks requested review from ejona86 and danielzhaotongliu March 7, 2025 18:34

shivaspeaks requested review from larry-safran and kannanjgithub March 17, 2025 08:41

ejona86 reviewed Mar 17, 2025

View reviewed changes

address comments

ca5bb14

shivaspeaks requested a review from ejona86 March 18, 2025 17:03

ejona86 reviewed Mar 18, 2025

View reviewed changes

communicate protocol through EnvoyServerData.Address

cb41652

shivaspeaks and others added 3 commits March 19, 2025 20:11

Merge branch 'master' into listener-type-validation

e07158f

resolve conflicts

9f79e8c

resolve conflicts

d8fb13a

shivaspeaks requested a review from ejona86 March 19, 2025 15:58

shivaspeaks commented Mar 19, 2025

View reviewed changes

ejona86 reviewed Mar 19, 2025

View reviewed changes

Final code

6873d59

shivaspeaks requested a review from ejona86 March 19, 2025 18:07

remove unwanted line

b3908f1

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

xds: listener type validation #11933

xds: listener type validation #11933

shivaspeaks commented Mar 3, 2025

ejona86 left a comment

ejona86 Mar 6, 2025

danielzhaotongliu Mar 6, 2025

shivaspeaks Mar 7, 2025

ejona86 Mar 12, 2025

ejona86 Mar 12, 2025

shivaspeaks Mar 12, 2025

ejona86 Mar 12, 2025

ejona86 Mar 18, 2025

shivaspeaks Mar 19, 2025 •

edited

Loading

ejona86 Mar 19, 2025

shivaspeaks Mar 19, 2025

danielzhaotongliu Mar 7, 2025

ejona86 left a comment

ejona86 Mar 12, 2025

ejona86 Mar 12, 2025

ejona86 Mar 18, 2025

ejona86 Mar 18, 2025

ejona86 Mar 18, 2025

shivaspeaks Mar 19, 2025

ejona86 Mar 19, 2025

larry-safran Mar 20, 2025

larry-safran commented Mar 20, 2025

xds: listener type validation #11933

Are you sure you want to change the base?

xds: listener type validation #11933

Conversation

shivaspeaks commented Mar 3, 2025

ejona86 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shivaspeaks Mar 19, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ejona86 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

larry-safran commented Mar 20, 2025

shivaspeaks Mar 19, 2025 •

edited

Loading