UDP-based Transport for Configured
SubscriptionsINSA-LyonLyonFrancealex.huang-feng@insa-lyon.frINSA-LyonLyonFrancepierre.francois@insa-lyon.frHuawei156 Beiqing Rd., Haidian DistrictBeijingChinazhoutianran@huawei.comSwisscomBinzring 17Zuerich 8045Switzerlandthomas.graf@swisscom.comNTTSiriusdreef 70-72Hoofddorp, WT 2132NLpaolo@ntt.netNETCONFThis document describes a UDP-based transport for YANG notifications
to collect data from network nodes. A shim header is defined to
facilitate the data streaming directly from a publishing process on a network
device to telemetry receivers. Such a design enables higher frequency
updates and less performance overhead on publisher and receiver processes compared to
already established notification mechanisms. A YANG data model is also defined
for management of the described UDP-based transport.The mechanism to support a subscription of a continuous and
customized stream of updates from a YANG datastore is defined in Subscribed Notifications
and YANG-Push .
Subscribed Notifications separate the management and control
of subscriptions from the transport used to deliver the data. Three transport mechanisms,
namely NETCONF transport, RESTCONF transport, and HTTPS transport were
defined for such notification messages.While powerful in their features, and general in their architecture,
the currently available transport mechanisms need to be complemented to
support data publications at high frequency with low overhead. This is
important for network nodes that feature a distributed architecture with sparse
resources on components specialized for packet forwarding. The currently
available transports are TCP-based requiring the maintenance of connections,
states and retransmissions, which is not necessary for high-frequency continuous
notification content, typically published directly from network processors on line cards.This document specifies a transport option for Configured Subscriptions as defined in
that leverages UDP. Specifically, it facilitates the
distributed data collection mechanism described in . In the case of publishing
from multiple network processors on multiple line cards, centralized
designs require data to be internally forwarded from those network
processors to the push server, presumably on a route processor, which
then combines the individual data items into a single consolidated
stream. The centralized data collection mechanism can result in a
performance bottleneck, especially when large amounts of data are
involved.What is needed is a mechanism that allows for directly publishing
from multiple network processors on line cards, without passing them
through an additional processing stage for internal consolidation. The
UDP-based transport allows for such a distributed data
publishing approach:Firstly, a UDP approach reduces the burden of maintaining a large
pool of active TCP connections at the receiver, notably in cases
where it collects data from network processors on line cards from a
large number of network nodes.Secondly, as no connection state needs to be maintained, UDP
encapsulation could be implemented by the hardware of the
publisher, which further improves performance.Ultimately, such advantages allow for a larger data analysis
feature set, as more voluminous, finer grained data sets can be
streamed to the receiver.The transport described in this document can be used for transmitting
notification messages over both IPv4 and IPv6. It is designed to be used
in cases where packet loss is not a concern, such as the collection of statistical
metrics that are exported periodically. This transport can be configured
via NETCONF or RESTCONF .This document describes the notification mechanism. It is intended to
be used in conjunction with , extended by . Additionally,
this document defines a YANG data model for management of the UDP-based transport.
The YANG module specified in this document is compliant with Network Management
Datastore Architecture (NMDA) . details the
notification mechanism and message format.
describes the use of options in the notification message header. covers the applicability of the
mechanism. describes a mechanism to
secure the protocol in open networks. Finally,
defines a YANG data model for management of the mechanism described in this document.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
when, and only when,
they appear in all capitals, as shown here.The following terms are used as defined in Subscribed Notifications :
Notification message
Subscription
Configured Subscription
Subscriber
Publisher
Receiver
The following term is used as defined in :
Message Publisher ID
This document defines the following term:
Message ID: identifier of a message transported by the UDP-Notif protocol.
More details are presented in .
This section specifies the UDP-Notif transport behavior. describes the general design of the solution.
specifies the UDP-Notif message format
and describes the encoding of the message
payload.As specified in Subscribed Notifications,
the content of a YANG notification is encapsulated in a notification message, which is then
encapsulated and carried using a transport protocol. illustrates the structure of a UDP-Notif
message:The Message Header contains information that facilitates the
message transmission before deserializing the notification
message.The Notification Message is the encoded content that is transported
by the publication stream. The common encoding methods are listed
in . The structure of the
notification message is defined in Section 2.6 of Subscribed Notifications.
When a publisher starts streaming UDP-Notif messages, the first message
generated by the publisher MUST be a separate "subscription-started" notification
to indicate to the receiver that the stream has started
flowing. Then, the notifications can be sent immediately without delay.
Subscription state notifications, defined in Section 2.7 of
, MUST be encapsulated in separate notification
messages.Note that receivers collecting UDP-Notif messages may not be already up and running when the
configuration of the subscription takes effect on a monitored network
node.
The UDP-Notif message header contains information that facilitates
the message transmission between the publisher and the receiver before
deserializing the notification message. The data format is shown in .The Message Header contains the following field:Ver indicates the UDP-Notif protocol header version. The values
are allocated by the IANA registry "UDP-Notif
header version". The current header version number is 1.S-flag represents the space of media type specified in the MT field.
When S-flag is not set, MT represents the standard media types as defined
in the IANA registry "UDP-Notif media
types". When S-flag is set, MT represents a private space to
be freely used for non-standard encodings.
MT is a 4-bit identifier that indicates the media type used for
the notification message. When the S bit is not set, the following values apply:0: Reserved, MUST NOT be used.1: application/yang-data+json 2: application/yang-data+xml 3: application/yang-data+cbor Header Len (8-bit) records the length of the message header in octets,
including both the fixed header and the options.Message Length (16-bit) records the total length of the UDP-Notif message
within one UDP datagram, measured in octets, including the message
header. When the notification message is segmented using the
Segmentation Options defined in ,
the Message Length is the total length of the current
UDP-Notif segment, not the length of the entire notification
message.Message Publisher ID is a 32-bit identifier defined in . This identifier is
locally unique to the publisher node. It identifies the software process
generating the stream of UDP-Notif messages and allow the disambiguation
of an information source. Message unicity is obtained from the conjunction of the Message
Publisher ID and the Message ID field. If Message
Publisher ID unicity is not preserved through the collection
domain, the source IP address of the UDP datagram MUST be used
in addition to the Message Publisher ID to identify the
information source. If a transport layer relay is used, Message
Publisher ID unicity must be preserved through the collection
domain.The Message ID is increased monotonically by the publisher of
UDP-Notif messages and MUST start at 1 with
the first message. A publisher MUST use different Message IDs
for different messages generated with the same Message
Publisher ID. Note that the main purpose of the Message ID is to
reconstruct messages which are segmented using the segmentation
option described in .
The Message ID values SHOULD be incremented by one for
successive messages originated with the same Message Publisher ID,
so that message loss can be detected at data collection. When the last value (2^32-1)
of Message ID has been reached, the Message ID wraps around and
restarts at 0.
Options are a variable-length field in the TLV format. When the
Header Length is larger than 12 octets, which is the length of the
fixed header, Options TLVs follow directly after the fixed message
header. Options are described in .All the binary fields MUST be encoded in network byte order (big
endian).UDP-Notif message data can be encoded in XML, JSON or CBOR format.
Additional encodings may be supported in the
future. This can be accomplished by augmenting the subscription data
model with additional identity statements used to refer to requested
encodings. The new encoding can be registered in the IANA registry
"UDP-Notif media types" following the procedure defined in
.Subscribed Notifications states that a transport MUST identify
a default encoding. However, as per , Subscribed Notifications does not
require to define a default encoding.
Private encodings can be used by enabling the S-flag of the header. When the S-flag
is set, the value of the MT field is left to be defined and agreed
upon by the users of the private encoding. The MT field allows for 16
private encodings when S-flag is set.
The encoding of a message data is configured on a subscription basis and each
subscription reference a receiver instance. Publishers
MUST NOT be configured to send notification messages with more than one
encoding to the same receivers.All the options are defined with the format shown in
.Type: 1-octet describing the option type. The values of the Type field
are allocated by the IANA registry "UDP-Notif options
types".Length: 1-octet representing the total number of octets in the
TLV, including the Type and Length fields.Variable-length data: 0 or more octets of data.When more than one option are used in a UDP-Notif header, the segmentation option
defined in MUST be placed first, if present.
Placing the segmentation option first can simplify some implementations for both
the publisher and the receiver, notably those assuming a fixed location for the
segmentation option. Segmented messages where the segmentation option is not
the first option MAY be discarded by the receiver.The UDP payload length is limited to 65527 bytes (65535 - 8 bytes).
Application-level headers will make the actual payload shorter. Even
though binary encodings such as CBOR may not require more space than what
is left, more voluminous encodings such as JSON and XML may suffer from
this size limitation. Although IPv4 and IPv6 publishers can fragment
outgoing packets exceeding their Maximum Transmission Unit (MTU),
fragmented IP packets may not be desired for operational and
performance reasons .Implementations MUST provide a configurable parameter to control the maximum size of a
UDP-Notif segment. This parameter is defined as "max-segment-size" in the YANG module specified
in .The Segmentation Option is included when the message content
is segmented into multiple segments. Different segments of one message
share the same Message ID. The fields of this option are as follows:Type: indicates a Segmentation Option. The value is 1 for this option.Length: indicates the length of this option, in octets. It MUST be set
to 4 octets.Segment Number: 15-bit value indicating the sequence number of
the current segment. The first segment of a segmented message has
a segment number value of 0. The segment number cannot wrap around.L: indicates whether the current segment is the
last one of the message. When 0 is set, the current segment is not
the last one. When 1 is set, the current segment is the last one,
meaning that the total number of segments used to transport this
message is the value of the current Segment Number + 1.Implementations MUST NOT rely on IP
fragmentation to carry large messages. Implementations
MUST either restrict the size of individual
messages to a value that will not lead to IP fragmentation as per ,
or support the segmentation option. In the latter case, the parameter "max-segment-size" MUST be set
so that the size of a UDP-Notif segment and the size of the IP layer
together do not exceed the MTU of the egress interface.When a message has multiple options and is segmented, all the options
MUST be present on the first segment. The rest of segmented messages MAY
include all the options. The segmentation option MUST be placed first
in all segments.The receiver SHOULD support the reception of unordered segments.
The implementation of the receiver SHOULD provide an option to discard
the received segments if, after some time, one of the segments is still
missing and the reassembly of the message is not possible. No retransmission
of lost segments are expected from the publisher. If the receiver
collects a segment more than once, the implementation SHOULD drop the
duplicate segment.To reassemble segmented UDP-Notif messages, the receiver should first identify
UDP-Notif segments belonging to the same message by using the combination of the Message
Publisher ID and Message ID. The receiver SHOULD wait for all the segments before starting
the reassembly process. Once all the segments are collected, the receiver should create a new
UDP-Notif header with the same Ver, S-flag, MT, Message Publisher ID and Message ID values.
When UDP-Notif options other than the segmentation option are present in the first segment,
these options need to be appended to the newly created UDP-Notif header.
To reconstruct the original notification message, the receiver must concatenate the
notification message of each UDP-Notif segments in an ascending order based
on the Segment Number. The new concatenated notification message becomes the notification message
of the newly created UDP-Notif message. The Header Length and Message Length are then updated
accordingly.This section provides an applicability for the
UDP-Notif mechanism, following the recommendations of .The mechanism falls in the category of UDP applications
"designed for use within the network of a single network operator or on
networks of an adjacent set of cooperating network operators, to be
deployed in controlled environments", as defined in . Implementations SHOULD
thus follow the recommendations in place for such specific applications.
We discuss recommendations on congestion control in ,
message size guidelines in and
reliability considerations in .The main use case of the UDP-Notif mechanism is the collection of
statistical metrics for accounting purposes, where potential loss is not
a concern, but should however be reported (such as IPFIX Flow Records
exported with UDP ). Such metrics are typically
exported in a periodical subscription as described in Section 3.1 of
.The above application falls into the category of applications
performing transfer of large amounts of data. It is expected that the
operator using the solution configures dedicated class of services on its related flows. As
per , such applications may choose not to
implement any form of congestion control, but follow the following
principles.It is NOT RECOMMENDED to use the UDP-Notif mechanism over
congestion-sensitive network paths. The only environments where
UDP-Notif is expected to be used are managed networks. The deployments
require that the network path has been explicitly provisioned to
handle the traffic through traffic engineering mechanisms, such as
rate limiting or capacity reservations.Implementation SHOULD NOT push unbounded volumes of
traffic by default, and SHOULD require the users to explicitly
configure such a mode of operation.Burst mitigation through packet pacing is RECOMMENDED. Disabling
burst mitigation SHOULD require the users to explicitly configure such
a mode of operation.Applications SHOULD monitor packet losses and provide means to the
user for retrieving information on such losses. The UDP-Notif Message
ID can be used to deduce congestion based on packet loss detection.
Hence the receiver can notify the publisher to use a lower streaming
rate. The interaction to control the streaming rate on the publisher
is out of the scope of this document. recommends not to rely on IP fragmentation
for messages whose size result in IP packets exceeding the MTU along
the path. The segmentation option of the current specification permits
segmentation of the UDP-Notif message content without relying on IP
fragmentation.
It is RECOMMENDED that the size of a Notification Message is
small and segmentation does not result in segmenting the message into too
many segments to avoid dropping the entire message when there is a lost
segment.
A receiver collecting segmented UDP-Notif
messages SHOULD have a configurable parameter to discard segments when they exceed a
certain amount of segments. The generation of too many segments by a publisher can be used as an
abuse to require computation resources for reassembling large messages at the receiver.A receiver implementation SHOULD discard packets that were received
but cannot be re-assembled as a
complete message within a given amount of time. This time SHOULD be
configurable.
In unsecured networks, which are not authenticated and encrypted on
layers below transport, UDP-Notif messages MUST be
encrypted. This section presents a mechanism using DTLS
to secure
UDP-Notif protocol. In addition to providing encryption, DTLS also
ensures authentication and integrity protection, preventing attacks
such as the injection of malicious packets.Implementations using DTLS to secure UDP-Notif messages MUST support DTLS
1.2 or later, and SHOULD support DTLS 1.3 .
No DTLS extensions are defined in this document.When this security layer is used, the publisher MUST always be a DTLS
client, and the Receiver MUST always be a DTLS server. The Receivers
MUST support accepting UDP-Notif Messages on the configured UDP port, but
MAY be configurable to listen on a different port. The publisher MUST
support sending UDP-Notif messages to the specified UDP port number, but MAY be
configurable to send messages to a different port. The publisher MAY use
any source UDP port for transmitting messages.This section describes the lifecycle of UDP-Notif messages when
they are encrypted using DTLS.The publisher initiates a DTLS connection by sending a DTLS
ClientHello to the Receiver. Implementations MAY disable the denial
of service countermeasures defined by DTLS 1.2 and DTLS 1.3 if a given deployment
can ensure that DoS attacks are not a concern.In DTLS 1.3 when the denial of service countermeasures are implemented, the
Receiver responds with a DTLS HelloRetryRequest containing a stateless cookie.
The publisher sends then a second DTLS ClientHello message containing the received cookie.
Details can be found in Section 5.1 of .When DTLS is implemented, the publisher MUST NOT send any
UDP-Notif messages before the DTLS handshake has successfully
completed. Implementations MUST NOT use the early data mechanism
(also known as 0-RTT data) defined in DTLS 1.3 .Implementations MUST follow recommendations defined
by . If other cipher suites than the ones recommended by
are used, then implementations MUST NOT negotiate a
cipher suite that employs NULL integrity or authentication algorithms.Where confidentiality protection with DTLS is required,
implementations must negotiate a cipher suite that employs a
non-NULL encryption algorithm.When DTLS is used, all UDP-Notif messages MUST be published as
DTLS "application_data". It is possible that multiple UDP-Notif
messages are contained in one DTLS record, or that a publication
message is transferred in multiple DTLS records. The application
data is defined with the following ABNF
expression:APPLICATION-DATA = 1*UDP-NOTIF-FRAMEUDP-NOTIF-FRAME = MSG-LEN SP UDP-NOTIF-MSGMSG-LEN = NONZERO-DIGIT *DIGITSP = %d32NONZERO-DIGIT = %d49-57DIGIT = %d48 / NONZERO-DIGITUDP-NOTIF-MSG is defined in .The publisher SHOULD attempt to avoid IP fragmentation by using
the Segmentation Option in the UDP-Notif message.A publisher MUST close the associated DTLS connection if the
connection is not expected to deliver any UDP-Notif Messages later.
It MUST send a DTLS close_notify alert before closing the
connection. A publisher (DTLS client) MAY choose to not wait for the
Receiver's close_notify alert and simply close the DTLS connection.
Once the Receiver gets a close_notify from the publisher, it MUST
reply with a close_notify.When no data is received from a DTLS connection for a long time,
the Receiver MAY close the connection. Implementations SHOULD set
the timeout value to 10 minutes but application specific profiles
MAY recommend shorter or longer values. The Receiver (DTLS server)
MUST attempt to initiate an exchange of close_notify alerts with the
publisher before closing the connection. Receivers that are
unprepared to receive any more data MAY close the connection after
sending the close_notify alert.Although closure alerts are a component of TLS and so of DTLS,
they, like all alerts, are not retransmitted by DTLS and so may be
lost over an unreliable network.DTLS 1.2 and DTLS 1.3 states
that DTLS message may be fragmented into
multiple DTLS records. A DTLS message carrying a UDP-Notif message SHOULD fit within a
single datagram to avoid DTLS fragmentation. Implementations SHOULD
account for DTLS overhead when determining the maximum UDP-Notif
notification message size.
The YANG model described in defines
a new receiver instance for UDP-Notif transport. When this transport
is used, four new leaves and a dtls container allow configuring
UDP-Notif receiver parameters.The source address of the UDP-Notif message can be configured using the
"source-address" leaf at the subscription level as defined in
or by setting
the leaf "local-address" using the "ietf-udp-notif-transport" YANG module.
When both are configured, the UDP-Notif message MUST use the address configured
in the "local-address" leaf defined in the "ietf-udp-notif-transport" YANG module.
The model defines the following YANG tree :This YANG module is used to configure, on a publisher, a receiver
willing to consume notification messages. This module augments the
"ietf-subscribed-notif-receivers" module to define a UDP-Notif
transport receiver. The grouping "udp-notif-receiver" defines
the necessary parameters to configure the transport defined in this
document using the generic "udp-client" grouping from the
"ietf-udp-client" module
and the "tls-client-grouping" defined in the "ietf-tls-client" module
. It uses data types defined in .
WG List:
Authors: Guangying Zheng
Tianran Zhou
Thomas Graf
Pierre Francois
Alex Huang Feng
Paolo Lucente
";
description
"Defines a model for configuring UDP-Notif as a transport
for configured subscriptions [RFC8639].
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2025-06-04 {
description
"Initial revision";
reference
"RFC XXXX: UDP-based Transport for Configured Subscriptions";
}
/*
* FEATURES
*/
feature encode-cbor {
description
"Indicates that CBOR encoding of notification
messages is supported.";
reference
"RFC 9254: CBOR Encoding of Data Modeled with YANG";
}
feature dtls {
description
"Indicates that DTLS encryption of UDP
packets is supported. UDP-Notif mandates that, in
unsecured networks, DTLS 1.2 or later MUST be supported,
and DTLS 1.3 SHOULD be supported.";
reference
"RFC6347: Datagram Transport Layer Security Version 1.2,
RFC 9147: The Datagram Transport Layer Security (DTLS)
Protocol Version 1.3";
}
/*
* IDENTITIES
*/
identity udp-notif {
base sn:transport;
base sn:configurable-encoding;
description
"UDP-Notif is used as transport for notification messages
and state change notifications.";
}
identity encode-cbor {
base sn:encoding;
description
"Encode data using CBOR.";
reference
"RFC 9254: CBOR Encoding of Data Modeled with YANG";
}
identity unsupported-max-segment-size {
base sn:establish-subscription-error;
base sn:modify-subscription-error;
description
"Error triggered when the specified value 'max-segment-size'
is not supported by the publisher. An implementation may
only support a subset of the uint16.";
reference
"RFC XXXX: UDP-based Transport for Configured Subscriptions";
}
grouping udp-notif-receiver {
description
"Provides a reusable identification of a UDP-Notif target
receiver.";
uses udpc:udp-client {
refine "remote-port" {
mandatory true;
}
}
container dtls {
if-feature "dtls";
presence "dtls";
uses tlsc:tls-client-grouping {
// Remove keep-alives for DTLS
refine "keepalives" {
if-feature "not tlsc:tls-client-keepalives";
}
}
description
"Container for configuring DTLS parameters.";
}
leaf enable-segmentation {
type boolean;
default "true";
description
"When disabled, the publisher will not segment UDP-Notif
messages. This may cause IP-layer fragmentation when
messages are larger than the MTU. IP fragmentation is
discouraged (RFC 8085, RFC 8900) and generally unsafe.
Disabling is not recommended.";
}
leaf max-segment-size {
type uint16;
description
"UDP-Notif provides a configurable max-segment-size to
control the size of each segment (UDP-Notif header, with
options, included).
The publisher may trigger an 'unsupported-max-segment-size'
error if the publisher does not support the configured
value.";
}
}
augment "/sn:subscriptions/snr:receiver-instances/"
+ "snr:receiver-instance/snr:transport-type" {
case udp-notif {
container udp-notif-receiver {
description
"The UDP-Notif receiver to send notifications to.";
uses udp-notif-receiver;
}
}
description
"Augments the transport-type choice to include the 'udp-notif'
transport.";
}
}
]]>This document describes several new registries, the URIs from IETF
XML Registry and the registration of a new YANG module name.This document requests IANA to create a new registry group called
"UDP-Notif protocol".Under this registry group, the following three registries are to be created:Registry Name: UDP-Notif Media TypesDescription: This registry defines media types that can be used for encoding notification payloads transported using the UDP-Notif protocol.Registration Procedure: Standards Action (see ).
Registration Template:
Value: Integer (0-15)Description: Short text description of the media typeReference: Document reference (e.g., RFC number)
Initial Registrations:
ValueDescriptionReference0ReservedRFC-to-be1media type application/yang-data+jsonRFC80402media type application/yang-data+xmlRFC80403media type application/yang-data+cborRFC9254
Registry Name: UDP-Notif Option Types
Description: This registry defines option types used to extend message capabilities within the UDP-Notif protocol, such as segmentation.
Registration Procedure: Standards Action (see Section 4.9 of ).
Registration Template:
Value: Integer (0-255)Description: Short text description of the optionReference: Document reference (e.g., RFC number)
Initial contents of the "UDP-Notif Option Types" registry are shown in Table 2.
ValueDescriptionReference0ReservedRFC-to-be1Segmentation OptionRFC-to-be
Registry Name: UDP-Notif Header Version
Description: This registry defines the header version numbers used in the UDP-Notif protocol to distinguish between different versions of the transport protocol.
Registration Procedure: Standards Action (see Section 4.9 of ).
Registration Template:
Value: Integer (0-7)Description: Short text description of the header versionReference: Document reference (e.g., RFC number)
Initial contents of the "UDP-Notif Header Version" registry are shown in Table 3.
ValueDescriptionReference0UDP based Publication Channel for Streaming Telemetrydraft-ietf-netconf-udp-pub-channel-051UDP-based Transport for Configured SubscriptionsRFC-to-be
Note: There is an older specification of this transport protocol defined in
that was deployed in some networks.
To enable differentiating both protocols, different version numbers are used.
The current specification replaces and uses 1 as its version,
while the header defined in uses 0.
IANA is also requested to assign a new URI from the IETF XML Registry. The following URI is
suggested:This document also requests a new YANG module name in the
YANG Module Names registry with the
following suggestions:Note to the RFC-Editor: Please remove this section before
publishing.INSA Lyon implemented this document for a YANG Push publisher in an
example implementation.The open source code can be obtained here: .INSA Lyon implemented this document for a YANG Push receiver as a
library.The open source code can be obtained here: .The open source YANG push receiver library has been integrated into
the Pmacct open source Network Telemetry data collection .Huawei implemented this document for a YANG Push publisher in their
VRP platform.6WIND implemented this document for a YANG Push publisher in their
VSR platform.Cisco implemented this document for a YANG Push publisher in their
IOS XR platform. states that "UDP applications that need to
protect their communications against eavesdropping, tampering, or
message forgery SHOULD employ end-to-end security services provided by
other IETF protocols". As mentioned above, the proposed mechanism is
designed to be used in controlled environments, as defined in also known as "limited domains", as defined in . Thus, a security layer is not necessary required.
Nevertheless, for networks that are not secured, a secure transport
providing confidentiality, integrity protection, authentication,
and replay protection MUST be implemented.
A specification of UDP-Notif using DTLS 1.3 as its encryption layer
is presented in .The following text uses the template described in Section 3.7 of
.The "ietf-udp-notif-transport" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as
NETCONF and RESTCONF . These protocols have to
use a secure transport layer (e.g., SSH , TLS , and
QUIC ) and have to use mutual authentication.
The Network Configuration Access Control Model (NACM)
provides the means to restrict access for particular NETCONF or RESTCONF users to
a preconfigured subset of all available NETCONF or RESTCONF protocol operations
and content.There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., config true, which is the default). These data
nodes may be considered sensitive or vulnerable in some network environments. Write
operations (e.g., edit-config) to these data nodes without proper protection can have
a negative effect on network operations. These are the subtrees and data nodes and
their sensitivity/vulnerability:
The data nodes "remote-address", "remote-port", "local-address",
and "local-port" in the "ietf-udp-notif-transport" module specify transport parameters
for the recipient of UDP-Notif messages. Unauthorized modification of these transport
parameters could redirect notifications to unintended recipients.
This YANG module uses groupings from other YANG modules that
define nodes that may be considered sensitive or vulnerable
in network environments. Refer to the Security Considerations of
and for
information as to which nodes may be considered sensitive or vulnerable in
network environments.
Guangying Zheng
Huawei
101 Yu-Hua-Tai Software Road
Nanjing
Jiangsu,
China
Email: zhengguangying@huawei.com
Yunan Gu
Huawei
Beijing
China
Email: guyunan@huawei.com
The authors of this documents would like to thank Lucas Aubard, Alexander
Clemm, Benoit Claise, Ebben Aries, Eric Voit, Huiyang Yang, Kent Watsen, Mahesh
Jethanandani, Marco Tollini, Hannes Tschofenig, Michael Tuxen, Rob Wilton, Sean
Turner, Stephane Frenot, Timothy Carey, Tim Jenkins, Tom Petch,
Joseph Touch, Andy Bierman, Carsten Bormann, Mohamed Boucadair, Weiqiang Cheng,
Giuseppe Fioccola, Camilo Cardona, Qiufang Ma and James Cumming for their constructive
suggestions for improving this document.INSA Lyon, YANG Push publisher example implementationINSA Lyon, YANG Push receiver library implementationPaolo Lucente, Pmacct open source Network Telemetry Data
CollectionErrata 6211This non-normative section shows two examples of how the the
"ietf-udp-notif-transport" YANG module can be used to configure a based publisher to send notifications to a receiver
and an example of a YANG Push notification message using UDP-Notif
transport protocol.This example shows how UDP-Notif can be configured without DTLS
encryption. It illustrates the definition of two receivers, one uses an
IPv4 as its destination address and another uses IPv6. The IPv4 receiver
is bound to the subscription.6666ds:oper\
ational/if:int\
erfaces/interfaceunt:udp-notifencode-jsonsubscription-specific-receiveripv4-udp-notif-receiver
active6000ipv4-udp-notif-receiver192.0.2.112345true9000ipv6-udp-notif-receiver2001:db8:abcd:12::112345true9000
]]>This example shows how UDP-Notif can be configured with DTLS
encryption.6666ds:oper\
ational/if:int\
erfaces/interfaceunt:udp-notifencode-jsonsubscription-specific-receiver-defudp-notif-receiver-dtls
active6000udp-notif-receiver-dtls2001:db8:abcd:12::112345ct:octet-string-key-formatBASE64VALUE=
example_external_id
sha-256example_context_string844312345Server Cert Issuer #1BASE64VALUE=Server Cert Issuer #2BASE64VALUE=My Application #1BASE64VALUE=My Application #2BASE64VALUE=corp-fw1ct:subject-public-key-info-format
BASE64VALUE=corp-fw2ct:subject-public-key-info-format
BASE64VALUE=true9000
]]>This example shows how UDP-Notif is used as a transport protocol to
send a "push-update" notification encoded in
JSON .Assuming the publisher needs to send the JSON payload showed in
, the UDP-Notif transport is
encoded following the . The UDP-Notif
message is then encapsulated in a UDP datagram.