Dear All,
I have several comments related to the security aspects of this specification:
- although this draft does not define network-specific encapsulation of IAOM data, it would the right place to introduce a generic method of IAOM data integrity protection. As noted in the Security Considerations section, IOAM trace options and collected information may become the target of a malicious attack. Protecting the integrity of data with HMAC seems like the right option. It seems reasonable that the text used to calculate HMAC includes in addition to the IOAM trace option header and an IOAM node data field that uniquely identify the source of the packet that includes IOAM trace. For example, in an IP network, the IP source address can be concatenated with the IAOM trace option header. The integrity of each IAOM node data record can also be protected by HMAC. The data record can be concatenated with, for example, the IOAM option header to form the text used in the calculation of the HMAC. While the detailed construction of the text used in HMAC calculation could be provided in network-specific documents, it seems appropriate to require the optional use of HMAC for the integrity protection of the IOAM option header and IOAM data record in this document.
- I have some concern over using the Checksum Complement in the IPv6 network. RFC 6936 provided us with the most detailed analysis for using zero UDP checksum in the IPv6 network. As I understand the purpose of the Checksum Complement, its security impact is similar to the one of using zero UDP checksum. I think that the use of Checksum Complement in the IPv6 network should be explicitly discussed in the document. I'd recommend adding the reference to RFC 6936 and provide arguments supporting the use of the Checksum Complement in the IPv6 network.
Regards,
Greg
On Tue, Nov 24, 2020 at 10:25 AM The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'Data Fields for In-situ OAM'
<draft-ietf-ippm-ioam-data-11.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2020-12-08. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
In-situ Operations, Administration, and Maintenance (IOAM) records
operational and telemetry information in the packet while the packet
traverses a path between two points in the network. This document
discusses the data fields and associated data types for in-situ OAM.
In-situ OAM data fields can be encapsulated into a variety of
protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
header), or IPv4. In-situ OAM can be used to complement OAM
mechanisms based on e.g. ICMP or other types of probe packets.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/3526/
_______________________________________________
ippm mailing list
ippm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ippm
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
