[netconf] Re: UDP-noitf ports and other considerations
Thomas.Graf@swisscom.com Sun, 22 September 2024 14:17 UTC
Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C670C14F616 for <netconf@ietfa.amsl.com>; Sun, 22 Sep 2024 07:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swisscom.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8oK8vXdfQJc for <netconf@ietfa.amsl.com>; Sun, 22 Sep 2024 07:16:57 -0700 (PDT)
Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8273C14F6E4 for <netconf@ietf.org>; Sun, 22 Sep 2024 07:16:56 -0700 (PDT)
Received: by mail.swisscom.com; Sun, 22 Sep 2024 16:16:53 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1727014613; bh=tA/pkSu3ogko5/LrcwlvILZxhvD5jSPh0H2HtS0XbzI=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=ZskOM2xL6dqCoNN/YWZzJ5MiqMTVue5ncj1daE8DEJaMGr/5uUUDy+yKq9FxXYboo 8NWBkmkct9WpxAD14CXJTuPYXhQYnKmz02XSJa5/IethApCVXCWd3eIKBhRP7ts68a Z3RrC8M2cVgCeBn9gPMEvKK10eFidWFA2l2AkTryKNRpNozsGxYVHD9MWj0fwoaD+1 TgQPMM4erBj6VAZ0vt90yd7XJ6BoUGArmlPL5ofe8KEXXXpYZM7AfLgs1DhWK7H41I nz9YtBGsBl7HrAoju2PI+6CtlU5tJ1rx/HzmD18eVTxJsSXB+dhhT0dRO8mYJEAJw7 Sfh5ONPK8ekjA==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_1742703_1345969004.1727014613071"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: kent+ietf@watsen.net, netconf@ietf.org, paolo@pmacct.net
Thread-Topic: [netconf] UDP-noitf ports and other considerations
Thread-Index: AQHbCvRLiPYQ/UXsVkCs7UY4IcEf2LJj0Luw
Date: Sun, 22 Sep 2024 14:16:50 +0000
Message-ID: <0c79d2bec7064ddbbd9c0e59d4743678@swisscom.com>
References: <377E3D18-6F72-4CE5-BBDA-DCA9CB9A6599@insa-lyon.fr> <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@email.amazonses.com>
In-Reply-To: <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@email.amazonses.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=02336a58-495c-42e0-bc00-adeb8ed7300f;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2024-09-22T13:28:33Z;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1;
x-originating-ip: [138.188.161.184]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Message-ID-Hash: 2FPV6K2PNTTOZHMHIP6EPYCRPS2GDMT5
X-Message-ID-Hash: 2FPV6K2PNTTOZHMHIP6EPYCRPS2GDMT5
X-MailFrom: Thomas.Graf@swisscom.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] Re: UDP-noitf ports and other considerations
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/9x_w3aI70Cw1oNJP4JH8h181cbI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>
Dear Paolo, As one of the authors of BMP, can you confirm/describe why for BMP there was no port in the user port range being assigned?. See below for possible explanation. Dear Kent, KW> - should there be one port for unencrypted and another for encrypted, or can encryption be negotiated? [note: syslog has separate ports] The assignment of a port in the user port range (https://www.rfc-editor.org/rfc/rfc6335.html#section-8.1.2) and the assignment of a service name has already been discussed on the mailing list: https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/ As Med noted, https://www.rfc-editor.org/rfc/rfc6335.html#section-7.2 and https://www.rfc-editor.org/rfc/rfc7605.html#section-7 defines the IESG and IANA guidelines. I agree with assessment that due to the following sentence https://www.rfc-editor.org/rfc/rfc7605.html#section-7.1 o Can this service use a Dynamic port number that is coordinated out-of-band? For example: o By explicit configuration of both endpoints. The argument for having a service/port assignment is weak. Looking at other Network Telemetry (RFC 9232) protocols, I see that IPFIX, netconf and SNMP has assignments, for encrypted and unencrypted application protocols. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=ipfix https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=netconf https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=snmp However, I don't see an assignment for BMP (RFC 7854). I quickly browsed the GROW mailing list and the BMP documents but did not find evidence on a discussion. Since RFC 7854 came after RFC 7605, I suspect for above described reason a user port and service name has not been requested. I am unaware of any guidelines that for network management protocols are more specific guidelines. I like to remark that draft-ietf-netconf-udp-notif had already an early transport directorate review https://datatracker.ietf.org/doc/review-ietf-netconf-udp-notif-11-tsvart-early-tuexen-2023-11-15/. If assignment of a user port range, service name, would be a requirement, it should have been raised there. From a network operators perspective, I see the assignment of a user port range as minimally beneficial. Minimizes the effort in configuration and selecting the dissector in decoding. I agree with rfc7605.html#section-7.1, due to the constraint resources, due to the minimal benefit, the argument is weak. I suggest not to request. KW> are both unencrypted and encrypted UDP-notif mandatory-to-implement by receivers? If not, how does a receiver indicate what it supports? Encryption is optional. feature dtls13 has been defined and used in module ietf-udp-notif-transport. https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-6 specifies when encryption must be used. KW> why is the protocol limited to RFC 8639 configured subscriptions? Correct, it applies to https://datatracker.ietf.org/doc/html/rfc8639#section-2.5. KW> the document defines 3 media-types, are any of them mandatory to implement? How does the client know which a server supports? [note: the https-notif draft includes a discovery mechanism for this] Valid point. As previously discussed at IETF 120. There are two potential mechanisms. Example: https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-06#section-2.1.2 and https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-06#section-2.2.2. Best wishes Thomas From: Kent Watsen <kent+ietf@watsen.net> Sent: Friday, September 20, 2024 2:28 AM To: netconf@ietf.org Subject: [netconf] UDP-noitf ports and other considerations Be aware: This is an external email. The discussion about registering a port for UDP-notif questions why a registration is needed/required, when the client is always configured, and hence no assignment is needed. I decided to look into what it takes to register a port. Here [1] is where the application for a port is, and [2] provides guidance on when it is appropriate the register a port. I think everyone interested in this topic should read [2]. My reading of [2] is that a port-assignment is justified, to simplify the configuration of services such as firewall, NAT, and QoS. Separately, while reading these RFCs, I started asking myself questions: - should there be one port for unencrypted and another for encrypted, or can encryption be negotiated? [note: syslog has separate ports] - are both unencrypted and encrypted UDP-notif mandatory-to-implement by receivers? If not, how does a receiver indicate what it supports? - should other transports be considered, e.g. tcp, sctp, dccp? [syslog can be layered on top of any transport, e.g., udp/514, tcp/6514, udp/6514, and dccp/6514]. - when encrypted, and assuming a distinct port is needed, would it make sense to use QUIC instead of DTLS? - since HTTPS-notif can already be layered on top on QUIC, when would a deployment choose to use UDP-notif over DTLS or QUIC vs HTTPS-notif over QUIC? - would the service name be “udp-notif”? Or would something like “yanglog” and “yanglog-tls” would be better? (modeled after syslog and syslog-tls) “yanglog" sounds dorky ;) - the document defines 3 media-types, are any of them mandatory to implement? How does the client know which a server supports? [note: the https-notif draft includes a discovery mechanism for this] - why is the protocol limited to RFC 8639 configured subscriptions? Ultimately the protocol is a sequence notification messages, with or without the 8639-specific notification messages? [HTTPS-notif does not care in which context it is used] [1] https://www.iana.org/form/ports-services [2] https://www.rfc-editor.org/rfc/rfc7605.html Kent / contributor Begin forwarded message: From: Alex Huang Feng <alex.huang-feng@insa-lyon.fr<mailto:alex.huang-feng@insa-lyon.fr>> Subject: [netconf] Re: Default statements on udp-client-server groupings Date: September 17, 2024 at 5:19:56 AM EDT To: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>> Cc: "netconf@ietf.org<mailto:netconf@ietf.org>" <netconf@ietf.org<mailto:netconf@ietf.org>>, draft-ietf-netconf-udp-client-server.authors@ietf.org<mailto:draft-ietf-netconf-udp-client-server.authors@ietf.org> - Personally I am not against having a default IANA port for UDP-Notif. I actually asked for it on the -13 iteration. But from the feedback received on the ML [1] and the last IETF meeting [2], the conclusion was that a port is not needed because an operator already needs to configure the IP address where the collector is located. I also see the same use case on the NC/RC Call home RFC. Even though a default port is defined, the operator still needs to configure the IP address of the NC client on the network management system... [1] https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/ [2] https://datatracker.ietf.org/doc/minutes-120-netconf-202407251630/ It’s true that it’s not a “first contact” situation, but many times Operators want a port for firewalls, wireshark, etc. And if we’re lucky, udp-notif will be very popular, easily justifying its allocation. Looking at the numbers, I see a 50/50 split in proponents of the two choices. This is far from WG consensus (not to mention weak participation). The minutes [2] show Rob suggesting asking a designated expert. This is what we should do. As I said, I am happy to add it back if it is needed. I’ll leave this thread to udp-client-server groupings and follow up on udp-notif in another thread. Regards, Alex
- [netconf] Default statements on udp-client-server… Alex Huang Feng
- [netconf] Re: Default statements on udp-client-se… Thomas.Graf
- [netconf] Re: Default statements on udp-client-se… mohamed.boucadair
- [netconf] Re: Default statements on udp-client-se… Benoit Claise
- [netconf] Re: Default statements on udp-client-se… Qin Wu
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Alex Huang Feng
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Alex Huang Feng
- [netconf] UDP-noitf ports and other considerations Kent Watsen
- [netconf] Re: Default statements on udp-client-se… Andy Bierman
- [netconf] Re: Default statements on udp-client-se… Thomas.Graf
- [netconf] Re: [netmod] Re: Default statements on … Per Andersson
- [netconf] Re: UDP-noitf ports and other considera… Thomas.Graf
- [netconf] Re: [netmod] Re: Default statements on … Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: UDP-noitf ports and other considera… Paolo Lucente
- [netconf] Re: Default statements on udp-client-se… Kent Watsen
- [netconf] Re: [netmod] Re: Default statements on … Andy Bierman
- [netconf] Re: [netmod] Re: Default statements on … Thomas.Graf
- [netconf] Re: [netmod] Re: Re: Default statements… Alex Huang Feng
- [netconf] Re: [netmod] Re: Default statements on … tom petch