Re: [netconf] Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Kent,

Thanks for your email and for your patience.

The main issue seems to be around the use of the CONNECT HTTP method (i.e., not a GET but “CONNECT www.example.com:830”) that can be used to tunnel *any* TCP protocol, including netconf, i.e., this is not an HTTP proxy where HTTP requests are proxied by an HTTP-aware proxy to an HTTP server (e.g., “GET http://www.example.com/”).

=> HTTP CONNECT can act as a plain TCP proxy, i.e., should appear at the same place as SOCKS.

I agree that MASQUE connect may be considered as slightly different (cfr Martin Duke’s ballot).

See below for EVY> for less important points.

Regards

-éric

From: Kent Watsen <[e-mail]>
Date: Wednesday, 21 February 2024 at 23:27
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Per Andersson (perander)" <[e-mail]>, Mahesh Jethanandani <[e-mail]>, "Scharf, Michael" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-netconf-tcp-client-server-21: (with DISCUSS and COMMENT)

Hi Éric,

Thank you for your comments.
Please see below for responses.

Kent



On Feb 20, 2024, at 7:55 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-netconf-tcp-client-server-21: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-netconf-tcp-client-server-21

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address as it is only to
force a reply), some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Per Andersson for the shepherd's detailed write-up including
the WG consensus (and the discussion with TCPM) and the justification of the
intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

## No MASQUE or HTTP-proxy defined ?

This is mainly to force a discussion over email. SOCKS were (and probably are
still) a common proxy mechanism, but should SSH tunnels, MASQUE connect (and
its old parent HTTP connect method) be part of this document?

This discuss seems to be about the "http-client-server” draft more so than the “tcp-client-server” draft.

For instance, this section[1] in the http-client-server draft defines a node called "proxy-connect” that enables the HTTP-client to be configured to connect via either an HTTP- or HTTPS- based proxy.  Though the “http-client-server" document doesn’t say it (which I just fixed), the “proxy-connect” node intends to support HTTP connect [2].

[1] https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#section-2.1.2.2
[2] https://datatracker.ietf.org/doc/html/rfc9110#section-9.3.6

I never heard before about MASQUE, which I see now is defined in both RFC 9298 (Proxying UDP in HTTP) and RFC 9484 (Proxying IP in HTTP).   Those RFCs being so new, the question is if MASQUE should be 1) added to the http-client-server draft now, 2) acknowledged as not being in the http-client-server draft, or 3) say nothing about MASQUE, only stating that HTTP-connect is supported and other proxy-types can be added by future work?


PS: there is a related DISCUSS going on for the http-client-server draft, regarding its current lack of support for QUIC.  The same 1/2/3-options in the previous paragraph are in play.   I had a conversion with the NETCONF-chairs (Mahesh and Per) today and we think that a small update to the http-client-server draft might be possible to support QUIC, assuming the configuration for QUIC and DTLS are the same (i.e., TLS + UDP).   [Is there a QUIC expert in the house I can ask?]


EVY> I have replied on the top of this email

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# COMMENTS (non-blocking)

## Section 2.1

While the text about keep-alives use cases sounds correct, I wonder whether
this text is relevant in an I-D about *data models*, i.e., why discussing the
semantics and use cases of TCP keep-alives?

Section 2.1.5 (Guidelines for Configuring TCP Keep-Alives) was written by my co-author, Michael Sharf (CC-ed), who is also a chair of the TCPM WG.  I had assumed that it was important...

Michael, can you respond to this comment?


EVY> thanks to Michael for his reply, I have replied to Micheal’s email

Some issue with the use of normative language for the default values of TCP
keep-alives, those values SHOULD be in NETCONF/RESTCONF protocols and not
discussed in this data model. To be honest, I hesitated to raise a discuss
level on this.

I’m assuming this comment regards Section 2.1.5 (Guidelines for Configuring TCP Keep-Alives).
I agree that text about motivation doesn’t need to be in a document regarding data-models...

Michael, can you respond to this comment also?




## Section 3.1.2.1

The reader would probably welcome an explanation of the differences between
'socks4' and 'socks4a', is it only to allow for a hostname ?

Should it be possible to configure multiple remote-addresses for the proxy ?

This took some effort.

As you’ll see when I publish an update to the suite of drafts (maybe later today),
I made the following changes:

1) added three new “feature” statements:
- socks4-supported
- socks4a-supported
- socks5-supported

2) greatly expanded Section 3.1.1 (Features) to describe each feature, with the
description for the “socks4a-supported” feature including the statement:

"The difference between Socks4 and Socks4a is that Socks4a enables
the "remote-address" to be specified using a hostname, in addition to
an IP address.

3) expanded Section 3.1.2.1, under the "proxy-server” description section, to
refer to the new “feature” statements and, in particular, the aforementioned
Section 3.1.1.


I’m hoping you will be happy with this update.



EVY> indeed I am 😊 but more important is that the model is better like it is now


## Section 3.3

About the tcp-client-grouping remote-address `the IP addresses are tried
according to local preference order`, should there be a reference to RFC 6724
(as there can be multiple source addresses) ?

I’m looking at https://datatracker.ietf.org/doc/html/rfc6724#section-6
…and feeling unsure about applicability to this section.

My hesitation regards how this same "tcp-client-grouping” specifies
the "local-address” (which I equate to “source address” as a single
value (type inet:ip-address), either specified or picked by the OS,
but it is still just one value.

Does RFC 6724 still apply?   Please advise.


EVY> it still does. Many hosts have multiple IP addresses (IPv4 global, IPv6 link-local,, IPv6 global) and sometimes multiple interfaces and restricting to a single source IP may not be the optimum.


Also in tcp-client-grouping local-address, AFAIK `INADDR6_ANY
('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
respectively ` should be amended.

Looking at:
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.2
https://datatracker.ietf.org/doc/html/rfc4291#section-2.2
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5

I see what you mean.  I made this change:

OLD: any IPv4 or IPv6 addresses, respectively.
NEW: any IPv4 or IPv6 address

EVY> could be OK indeed
.




## Section 4.3

Also in tcp-server-grouping local-address, AFAIK `INADDR6_ANY
('0:0:0:0:0:0:0:0' a.k.a. '::')` also means supporting IPv4-mapped addresses
per RFC 4291. SO, the text `the server can bind to any IPv4 or IPv6 addresses,
respectively ` should be amended.

I made the same change as described in my previous response.


EVY> same thing ;-)

Thanks again!
Kent