[netconf] UDP-noitf ports and other considerations

Kent Watsen <kent+ietf@watsen.net> Fri, 20 September 2024 00:28 UTC

Return-Path: <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@amazonses.watsen.net>
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 0E44BC16942C for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2024 17:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=amazonses.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 R-BXm22fejsg for <netconf@ietfa.amsl.com>; Thu, 19 Sep 2024 17:28:06 -0700 (PDT)
Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB35C1D6FBD for <netconf@ietf.org>; Thu, 19 Sep 2024 17:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1726792085; h=From:Content-Type:Mime-Version:Subject:Message-Id:References:To:Date:Feedback-ID; bh=YlDg+bS7QmX8ytt29lkHQvjNLPW/VOAxHJguwqBGCaU=; b=Iil5WCJVqHSViHk5TDblatP2uv3aBpigJyyXrIcFPoqyZ6u0FnwM9QXPf6Cz8tJ7 4tx0H5jZa4nRPGHWHym6E97/ZAjl1LMuUgjg/Pte2D+PXBea1nD7qU3Y+UVf1Uu4dr8 O8OeFw9eRptVJ81R0y6bOIKACu6AnuCqDXxyfItY=
From: Kent Watsen <kent+ietf@watsen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CC824CBC-4611-4C3D-AFE9-9D73B2810D5A"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Message-ID: <010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@email.amazonses.com>
References: <377E3D18-6F72-4CE5-BBDA-DCA9CB9A6599@insa-lyon.fr>
To: "netconf@ietf.org" <netconf@ietf.org>
Date: Fri, 20 Sep 2024 00:28:05 +0000
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.09.20-54.240.8.88
Message-ID-Hash: R463NTK2ZLSFAZO7IS5LFKJB2SMHAZHH
X-Message-ID-Hash: R463NTK2ZLSFAZO7IS5LFKJB2SMHAZHH
X-MailFrom: 010001920cd42fa0-d8483923-7446-457e-ab26-59bcaba47d7e-000000@amazonses.watsen.net
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] UDP-noitf ports and other considerations
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/TZ2nVoTFspiYU1xX9iu3ha0UxG0>
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>

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>
> 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>
> Cc: "netconf@ietf.org" <netconf@ietf.org>, 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
>