Summary

  • Report acceptance at the level actually demonstrated: configuration accepted, proxy negotiation completed, forwarding authorized, transport established, peer authenticated or application operation completed. A successful earlier stage cannot substitute for a missing later result. The management operation and the proxy exchange have separate outcomes, as defined in RFC 6241 and RFC 1928.
  • TCP keepalive replies do not establish application availability. In a conventional SOCKS relay, client-side transport checks concern the connection to the proxy, while the required service response lies beyond it. Monitoring should preserve that distinction rather than collapse transport responsiveness and service completion into one health indicator. RFC 9293.

Where acceptance stops

The mistake begins when a management system accepts a TCP client configuration containing a proxy and the operator marks the remote service reachable. The accepted object may accurately describe the intended path. It does not, by that fact alone, report a completed exchange over that path.

NETCONF makes the distinction concrete. A successful <edit-config> response concerns the requested configuration operation against a specified datastore. An accepted candidate edit is not itself a commitment to running configuration. Even a successful edit of running configuration does not supply a response from the remote application subsequently contacted by the configured client. RFC 6241.

RFC 9643 defines ietf-tcp-common, ietf-tcp-client and ietf-tcp-server, with corresponding tcp-common-grouping, tcp-client-grouping and tcp-server-grouping definitions for keepalives, outbound connections and listening endpoints. They provide no standalone protocol-accessible nodes or connection-result telemetry.

Consequently, an operator is dealing with those definitions as incorporated into a consuming model, not a standalone service-assurance interface. YANG defines a grouping as reusable material whose nodes are incorporated through a uses statement. A grouping declaration does not itself instantiate the corresponding nodes in the schema tree. RFC 7950.

The Network Management Datastore Architecture adds another necessary distinction. Intended configuration and configuration actively in use are separate concepts. Operational state includes applied configuration and system state; missing resources can prevent intended settings from being applied. RFC 8342.

Reading an applied setting is therefore stronger evidence than retaining only the requested setting. It still does not supply an application transaction result. The operational conclusion is narrow: retain acceptance as evidence of acceptance, and promote the claim only when a separately identifiable observation supports the next stage.

Two destinations behind one client configuration

Proxy configuration is optional and feature-gated, selecting SOCKS4, SOCKS4a or SOCKS5. The outer remote-address identifies the target; each proxy subtree’s remote-address identifies the proxy. The SOCKS4 proxy address is IP-only; SOCKS4a and SOCKS5 also permit hostnames. Proxy ports default to 1080; the target port has no intrinsic default. RFC 9643.

Those two destinations should remain separate throughout an investigation. An address recorded as “remote” is ambiguous without its configuration context. An operator needs to know whether it names the relay being contacted or the service sought through that relay.

The field types do not, by themselves, establish where target-name resolution occurred. SOCKS5 requests support IPv4, domain-name and IPv6 destination forms. An evidence record should identify the form actually transmitted rather than infer it from a hostname in management configuration. RFC 1928.

For an operator, the unresolved questions are practical: which component resolved the target, which answer it used, which local socket initiated the connection and which destination the proxy contacted. Configuration review can identify what should happen. Establishing what did happen requires observations associated with the relevant connection attempt.

The detailed exchange below concerns SOCKS5. Its method-selection messages should not be assumed to describe the other modeled proxy choices.

Negotiation admits a client; authorization admits a connection

For SOCKS5, the first TCP connection is to the proxy. The client offers authentication methods, the proxy selects one, any method-specific exchange occurs, and the client sends its forwarding request. The proxy then establishes or denies the requested connection. The protocol also defines a no-authentication method; a response indicating no acceptable method requires closure. RFC 1928.

SOCKS5’s optional authentication-parameters selects GSS-API or username/password, subject to feature support. The GSS-API container itself has no credential fields; augmentation can supply them. RFC 9643.

A selected configuration option therefore needs to be reconciled with an observed negotiation. The useful record identifies what the client offered, what the proxy selected and whether that selection satisfied the operator’s policy. An authentication setting should not be credited with success merely because it survived a configuration edit.

Username/password introduces a consequential boundary. RFC 1929 defines an authentication response whose zero status means success, with failure requiring closure. Its username and password fields each accommodate 1–255 octets, and the password is transmitted in cleartext. RFC 1929.

The operator therefore needs evidence that the runtime obtained a usable credential and that the proxy accepted it. The existence of a value in configuration answers neither question.

Credential storage and credential transmission are different controls. RFC 9640’s password grouping permits cleartext or encrypted representations for authenticating to a remote system. Protecting the configured value does not alter the subsequent authentication protocol’s wire format. RFC 9640.

The operational implication is that protection of the client-to-proxy exchange requires an independent decision. TLS subsequently established with the destination cannot retroactively protect a password already transmitted during proxy authentication. That follows from the ordering of the exchanges, not from an allegation about a particular deployment.

GSS-API requires different evidence. RFC 1961 describes credential preparation, establishment of a client–proxy security context and negotiation of message protection. The protection choices cover integrity, integrity with confidentiality, or selective protection. If the server’s selection is unacceptable, the client must close the connection. RFC 1961.

Recording only “GSS-API enabled” loses the identity and protection decisions that make the selection meaningful. The assurance question is whether the intended security context was established and the accepted protection was actually applied.

Neither successful credential validation nor successful security-context establishment grants unrestricted forwarding. Authentication concerns the client’s relationship with the proxy; authorization concerns the requested connection. An operating record should preserve both outcomes rather than treating the former as permission for every destination.

What a successful proxy reply actually establishes

A successful SOCKS5 CONNECT reply reports establishment of the requested connection. Its BND.ADDR and BND.PORT describe the proxy’s binding for the onward leg, not the destination server’s address or authenticated identity. RFC 1928.

This matters when evidence is assembled from different systems. A client log showing a successful reply and a bound address cannot simply be relabeled as proof that a particular backend answered. Where the actual onward destination matters, proxy-side connection records provide a different observation from the client’s requested destination.

TCP itself supplies a reliable, ordered byte stream. Its connection-establishment procedure concerns transport endpoints, not successful execution of an application operation. RFC 9293.

Even proxy-side records have limits. They describe what the observing proxy reports. They do not replace authentication of the remote service, and they do not demonstrate that the service processed a request. The strength of the conclusion depends on the observation’s source, the integrity of that source and the correlation between records.

For assurance purposes, distinguish the proxy’s connection result from the independently checked service result. Protecting a proxy exchange can strengthen confidence in the proxy’s report without making the proxy the authority for the destination’s application identity.

The remote service must answer under the right identity

When SSH is carried over the established path, the client needs a separate server-authentication decision. RFC 9644 models client identity and server authentication independently; its host-key option authenticates a presented server key through an exact match with a configured key. That check concerns the SSH endpoint, not the SOCKS account. RFC 9644.

The underlying SSH transport specification distinguishes verifying the expected host key from accepting a key without verification. It warns that the latter leaves the protocol insecure against active attacks. Key exchange also involves verification of the server’s signature, not simply observation of a public key. RFC 4253.

An evidence requirement should consequently identify the expected key or applicable trust decision, the verification result and the connection to which that result belongs. “Encryption enabled” is not an adequate replacement.

TLS introduces its own authentication choices. RFC 9645 includes certificate, raw-public-key and pre-shared-key mechanisms. The evidence requirement should follow the selected mechanism rather than assume that every connection produces a certificate chain. RFC 9645.

For certificate-authenticated TLS 1.3, successful verification of CertificateVerify demonstrates possession of the corresponding private key. Verification of Finished authenticates the handshake and computed keys. A configured certificate or a recorded certificate download cannot substitute for those live protocol results. RFC 8446.

Certificate possession is also distinct from service identification. RFC 9525 requires the client to construct acceptable reference identifiers independently of the identifiers the server presents and then seek an appropriate match. It explicitly does not replace certification-path validation. RFC 9525.

The intended service identity must therefore survive proxy traversal. Substituting the proxy hostname, or automatically accepting whatever identity arrives, answers the wrong question. An operator should be able to say which service was expected, which identity was authenticated and why that match was acceptable.

There is still an application boundary. For a NETCONF service, a selected <get> request offers a concrete test: correlate its <rpc-reply> using message-id, inspect the returned data and distinguish an <rpc-error> from the required result. RFC 6241.

That test should be defined around the operator’s actual need. A response containing unexpected data may demonstrate responsiveness without satisfying the operation’s acceptance condition. A refusal may establish that an authenticated application was reached while also establishing that the requested operation was not authorized.

A successful read would support a claim about that read, under that client identity, at that observation time. It would not establish permission to write, availability to every client or continuing success after a policy change.

Keepalives answer a narrower question

When enabled, keepalives default to idle-time 7,200 seconds, max-probes nine and probe-interval 75 seconds. The model estimates failure detection at idle-time + max-probes × probe-interval. It advises against idle intervals below 15 seconds and prohibits probe intervals below one second. RFC 9643.

TCP requires supported keepalives to be controllable per connection and disabled by default. It also prohibits interpreting the absence of a response to one particular probe as proof of a dead connection. RFC 9293.

For a conventional client-to-proxy TCP leg, the peer answering those probes is the proxy’s TCP endpoint. The resulting observation cannot establish that the destination application is processing requests. Shortening the interval changes the transport check’s timing; it does not move the check to the application.

The appropriate inference is not that keepalives are useless. They address a bounded liveness and resource-management problem. They should be evaluated alongside an application-level acceptance criterion rather than used to manufacture one.

A defensible claim names its limits

The strongest practical acceptance statement identifies the configuration in use, the observed proxy negotiation, the authorization outcome, the remote identity and the application result for a particular attempt. It also states which parts were not observable.

A client-only test might demonstrate a successful authenticated application exchange without exposing every intermediate address. A proxy-only test might demonstrate authorized forwarding without proving application identity. Neither should be represented as possessing the other’s visibility.

This is the control boundary operators must manage. Common configuration reduces ambiguity about instructions. Operational assurance requires a separate agreement about who supplies evidence for each result, who evaluates it and what claim is permitted when an observation is missing.

A successful configuration edit begins that work. It does not conclude it.