[netconf] Re: UDP-noitf ports and other considerations

[Paolo Lucente <[e-mail]>]

Hi Thomas,

Yes, i'd say that BMP totally falls into the "By explicit configuration 
of both endpoints" case of 
https://www.rfc-editor.org/rfc/rfc7605.html#section-7.1 .

I would not like to make much speculation on which case falls where. But 
IMO it makes sense that the collector of telemetry data being a service 
specialized instance / not contended resource, any listening port (ie. 
not a specific pre-assigned port) would do it.

Another thought is some potential clustering scenarios, for example when 
one wants to map a set of speakers to different receivers all running on 
the same system and listening on different (consecutive) ports.

All in all, and on the extra escort of rcf7605, not having a pre-defined 
port here seems a sensible choice.

Paolo


On 22/9/24 16:16, [e-mail] wrote:
> 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 
> <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/ <https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/>
> 
> As Med noted, https://www.rfc-editor.org/rfc/rfc6335.html#section-7.2 
> <https://www.rfc-editor.org/rfc/rfc6335.html#section-7.2> and 
> https://www.rfc-editor.org/rfc/rfc7605.html#section-7 
> <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 
> <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=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=netconf>
> 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=snmp <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/ <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 <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 
> <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 <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 <https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-06#section-2.2.2>.
> 
> Best wishes
> 
> Thomas
> 
> *From:*Kent Watsen <[e-mail]>
> *Sent:* Friday, September 20, 2024 2:28 AM
> *To:* [e-mail]
> *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 
> <https://www.iana.org/form/ports-services>
> 
> [2] https://www.rfc-editor.org/rfc/rfc7605.html 
> <https://www.rfc-editor.org/rfc/rfc7605.html>
> 
> Kent / contributor
> 
> 
> 
>     Begin forwarded message:
> 
>     *From: *Alex Huang Feng <[e-mail]
>     <mailto:[e-mail]>>
> 
>     *Subject: [netconf] Re: Default statements on udp-client-server
>     groupings*
> 
>     *Date: *September 17, 2024 at 5:19:56 AM EDT
> 
>     *To: *Kent Watsen <[e-mail] <mailto:[e-mail]>>
> 
>     *Cc: *"[e-mail] <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>,
>     [e-mail]
>     <mailto:[e-mail]>
> 
>             - 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/ <https://mailarchive.ietf.org/arch/msg/netconf/gP5AApWL0Ha8uey9yIQvBlqOJ7A/>
> 
>             [2]
>             https://datatracker.ietf.org/doc/minutes-120-netconf-202407251630/ <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 mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]