Re: [OPSAWG]  WG Adoption Call for draft-tuexen-opsawg-pcapng-05 and draft-richardson-opsawg-pcaplinktype-01

[Eelco Chaudron]

On 8 Dec 2022, at 21:34, Henk Birkholz wrote:

> Dear OPSAWG members,
>
> this starts a Working Group Adoption call for a bundle of two documents:
>
>> https://www.ietf.org/archive/id/draft-tuexen-opsawg-pcapng-05.html
>> https://www.ietf.org/archive/id/draft-richardson-opsawg-pcaplinktype-01.html
>
> ending on Monday, December 30th.
>
> As a recap: we already went through a first WGLC for 
> draft-tuexen-opsawg-pcapng-03 and this is the second WGLC. The last WGLC did 
> not yield a critical mass of active support.
>
> Since the last WGLC, two relevant decisions were made:
>
> 1.) The Intended Status of the main document draft-tuexen-opsawg-pcapng is 
> now Informational.
>
> 2.) The draft-richardson-opsawg-pcaplinktype document was split from the main 
> documents, focuses solely on the PCAP LINK Type registry content, and retains 
> the Intended Status Standards Track (as informational documents cannot 
> request a registry).
>
> As a generic reminder, these internet drafts describe the PCAPng format and 
> its corresponding registry - retaining the established design patterns of 
> PCAP and adding new capabilities as well as a an extensibility feature. 
> Please note that the corresponding document 
> https://www.ietf.org/archive/id/draft-ietf-opsawg-pcap-01.html was adopted in 
> October 2021 and its Intended Status is Historical.
>
> Please reply with your active support (+1 required) or objections and 
> especially any substantive comments you may have.

Sorry for the (to)late response, but I was on PTO for a while…

+1 for these documents!

Cheers,

Eelco


> For the OPSAWG co-chairs,
>
> Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [ippm] 回复: FW: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Thomas.Graf]

Dear Zhenqiang,

Thanks a lot for the feedback. Much appreciated.

I do not disagree that YANG push isn't capable of exporting control and 
forwarding plane metrics. However it is not the best choice in terms of scale. 
Table 1 of RFC 9232 gives a good summary. It even makes the distinction between 
network processor and route processor export. What it doesn't show however is 
that gRPC isn't suitable for network processors. To date, no vendor 
implementations are present. From my research with network and ASIC vendors as 
being the co-author of draft-ietf-netconf-distributed 
(https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif) I 
understood that gRPC won't be implementable in its current form. One of the 
main reason is the lack of backpressure support on network processors.

I fully agree that export for probing metrics such a TWAMP, TWAMP light or 
STAMP makes perfectly sense. With draft-ietf-ippm-stamp-yang and RFC 8913 we 
have well defined YANG modules. Speaking as network operator with approx. 7000 
YANG publishers I can confirm that this works well. Either when both probing 
and export runs on the route processor or both on the network processor 
directly.


  *   In my understanding, the aggregation benifit of IPFIX is not applicable 
for iOAM metrics, such as delay and packet loss, because iOAM metrics are 
different for different flows.

This I don't understand fully. Could you describe more detailed please.

To my understanding and maybe this helps to establish a clearer picture. IOAM 
is applied to existing or replicated packets and is classified as One-Way Delay 
Hybrid Type I according to Section 1 of draft-ietf-ippm-ioam-deployment 
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment#section-1).
 There are two modes. Active and Passive. In passive, where 
draft-tgraf-opsawg-ipfix-on-path-telemetry focuses on, existing packets are 
being used. Where in active mode, existing packets are replicated. IPFIX takes 
the packets and accounts them into flows. In flows we account bytes and packets 
over a given time period. With draft-tgraf-opsawg-ipfix-on-path-telemetry we 
also account for delay.


  *   Neither sampling, how can you insure that the flow you want its iOAM 
metrics will be sampled?

Packets have to be selected in the IOAM encapsulation node as described in 
Section 7.4 of draft-ietf-ippm-ioam-deployment 
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-deployment#section-7.4.
 IOAM doesn't specify how the packets are being selected. To my opinion it 
would make sense to refer in Section 7.4 of draft-ietf-ippm-ioam-deployment to 
RFC 5474 and RFC 5475 which are describing packet selection and sampling 
techniques, both widely used with IPFIX.

The benefit of sampling at the IOAM encapsulation node and flag with IOAM-DEX 
versus sampling on all nodes is that the amount of flows being exported is the 
same, but in case of IOAM-DEX we know the forwarding path in addition without 
additional overhead in the data export.


  *   The iOAM metrics, especially the delay and packet loss, should be 
exported in time, for example in one second. I don't think IPFIX is the right 
protocol.

For packet loss, you are correct, IPFIX is not the right protocol since packet 
loss is observed at the edges of the observation domain (black box monitoring). 
Packet loss is observed with probing where YANG push is the best choice for 
data export. IPFIX is being used to visualize where the packets are being 
dropped for which flow with IE89 ForwardingStatus.

IPFIX can export metrics without aggregation where flows are immediately being 
exported at ingress or egress. It is correct that aggregation introduces delay. 
Therefore it should only be applied to use cases which make sense 
https://www.rfc-editor.org/rfc/rfc7015#section-3. What I like to highlight is 
that in IPFIX supports an inactice timeout window. This allows the data export 
to be exported as quickly as possibly without waiting to finish the active 
timeout window.

Therefore using aggregation depends on the use case, the objective. Speaking 
for a network operator with a large scale Network Telemetry pipeline one of the 
key objectives is to have a wide view across the network while minimizing the 
amount of data as much and as early in the pipeline as possible. For automated 
traffic verification of several thousands of L3 VPN's a highly aggregated data 
set makes more sense then when troubleshooting of a particular customer flow 
across the network is needed. Here cardinality counts. Therefore we use with 
RFC7015 a two step data aggregation concept. One where the aggregation is 
performed on the network node without loosing cardinality. Where at 
data-collection through replication a second aggregation is performed where 
cardinality is reduced to a minimum. Allowing latency queries on the data set.

Looking forward to your comments.

Best wishes
Thomas

From: li_zhenqi...@hotmail.com 

Re: [OPSAWG] [secdir] Secdir last call review of draft-ietf-opsawg-mud-tls-10

[Ben Schwartz]

Since this happened to cross my inbox, I want to reiterate that, in my
view, this document has not been properly reviewed by the TLS WG.  As the
shepherd's writeup notes, previous reviews in the TLS group raised some
significant concerns about whether this draft's approach is advisable.

I would encourage the responsible AD(s) to make sure that this document has
strong consensus support from the TLS WG before proceeding.

On Fri, Nov 18, 2022 at 12:29 PM Linda Dunbar via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Linda Dunbar
> Review result: Has Nits
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.
> Document editors and WG chairs should treat these comments just like any
> other
> last-call comments.
>
> This document extends the Manufacturer Usage Description specification to
> incorporate the (D)TLS profile parameters for a network security service to
> identify unexpected (D)TLS usage. The document has very good description of
> common malware behavior that is informative.
>
> Questions
> - Are the profile on the remote IoT device or on the network device? If the
> profile is on remote IoT devices, are those attributes in the profiles
> attached
> as metadata when requesting TLS connections? Are those attributes
> encrypted? -
> If the Malware on IoT doesn't participate in TLS, can those MUD be used to
> detect the Malware on the remote IoT devices?
>
> - Page 6, first paragraph says:
>  "malware developers will have to develop malicious agents per IoT device
> type,
>  manufacturer and model, infect the device with the tailored malware agent
> and
>  will have keep up with updates to the device's (D)TLS profile parameters
> over
>  time."
>
> Does it mean that if all the IoT devices deployed in the network register
> their
> DeviceType/ManufacturerName/Model with the network services, then the
> network
> services can validate the TLS requests from the IoT?
>
> -  Section 3 last paragraph says that "compromised IoT devices are
> typically
> used for launching DDoS attacks". Can today's TLS re-negotiation validate
> the
> TLS requests by evaluating if the server certificates are signed by the
> same
> certifying authorities trusted by the IoT device"?
>
> Thank you very much,
>
> Linda Dunbar
>
>
> ___
> secdir mailing list
> sec...@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Publication has been requested for draft-ietf-opsawg-ipfix-srv6-srh-06

[Joe Clarke via Datatracker]

Joe Clarke has requested publication of draft-ietf-opsawg-ipfix-srv6-srh-06 as 
Proposed Standard on behalf of the OPSAWG working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12

[Eliot Lear]

Hi Rob,

On 19.12.22 17:25, Rob Wilton (rwilton) wrote:

Hi Eliot, Scott,

Thanks for this document.  Here is my AD review for 
draft-ietf-opsawg-sbom-access-12.


Moderate level comments:

(1) p 3, sec 1.  Introduction

To enable application-layer discovery, this memo defines a well-known
URI [RFC8615].  Management or orchestration tools can query this
well-known URI to retrieve a system's SBOM or vulnerability
information.  Further queries may be necessary based on the content
and structure of the response.

It looks like the .wellknown URI can only be used to retrieve SBOM information 
and not vulnerability information (unless I am missing something).


Sorry- that's an artifact of an earlier rev.  Corrected.





(2) p 15, sec 6.  Security Considerations

The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].

This text looks to be inconsistent with earlier parts of the document, 
specifically, I didn't think that the intent was to fetch this information 
using NETCONF or RESTCONF, but the early part of this document states that it 
contains groupings, which presumably could be used in any YANG model, and hence 
security considerations would apply.

I would suggest that you split the security considerations into two separate 
sub-sections:

i. The security considerations as this document applies to documenting SBOMs as 
part of the MUD file.  Which I think is most of the text that you have below.  
As per above I think that it is this section that should be updated to comment 
on the use of the insecure version of http and coap.

ii. A separate sub-section that only applies if the groupings are being used in 
regular YANG modules accessed via NETCONF/RESTCONF and that follows the 
standard YANG security template.


I think this needs more work.  To begin with, on the whole, people will 
probably NOT use NETCONF or RESTCONF for this information.  It's 
possible, but not likely.  So the beginning text is really not 
appropriate.  What I propose to to replace the NETCONF/RESCONF gunk with 
the following:



This document describes a schema for discovering the location of
information relating to software transparency, and does not specify
the access model for the information itself.  We describe below
protections relating to    both discovery and some    advice on protecting
the underlying SBOM/vulnerability information.





Minor level comments:

(3) p 0, sec

Discovering and Retrieving Software Transparency and Vulnerability
   Information
 draft-ietf-opsawg-sbom-access-12

It wasn't obvious to me why this is called "transparency", is this is a 
standard term of art for SBOMs?


It is.  This refers to software transparency of components; thus what 
the inventory is and what associated vulnerabilities are.






(4) p 4, sec 1.1.  How This Information Is Retrieved

Note that vulnerability and SBOM information is likely to change at
different rates.  MUD's cache-validity node provides a way for
manufacturers to control how often tooling should check for those
changes through the cache-validity node.

Just for my understanding: Is there any mechanism for clients to register for 
notification of changes rather than polling?


Not in this work.





(5) p 4, sec 2.  The well-known transparency endpoint set

Two well known endpoint is defined:

"Two" => "a", and well known => well-known?


yes





(6) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

  identity http {
base mudtx:local-type;
description
  "Use http (insecure) to retrieve SBOM information.  This
method is NOT RECOMMENDED, but may be unavoidable for
certain classes of deployment, where TLS has not or
cannot be implemented";
  }

I'm okay with this and coap (from a pragmatism POV).  But I think that the 
security section should talk about this: I.e., emphasize that secure versions 
MUST be used in preference, if available, and highlight the risks if insecure 
protocols are used.


Ok, how about this:


The model specifies both encrypted and unencrypted means to retrieve
information.  This is a matter of pragmatism.  Unencrypted
communications allow for manipulation of information being retrieved.
Therefore, it is RECOMMENDED that implementations offer    a means    to
configure endpoints so that they may make use of TLS or  DTLS.





(7) p 7, sec 4.  The mud-sbom augmentation to the MUD YANG model

  identity coaps {
base mudtx:local-type;
description
  

Re: [OPSAWG] [ippm] 回复: FW: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[li_zhenqi...@hotmail.com]

Hello Thomas,

As summarized in table 1 in RFC9232, gRPC is an application protocol, which can 
be used to export all the telemetry metrics for Management Plane, Control 
Plane, Forwarding Plane and External Data. By using GPB encoding, gRPC is 
widely used to export  real time performace metrics, such as link delay, 
jitter, packet loss measured by TWAMP or STAMP. Almost all our vendors support 
this way to export passport iOAM metrics and the test results in our lab are 
good. We have plan to deploy it in our field network soon.

In my understanding, the aggregation benifit of IPFIX is not applicable for 
iOAM metrics, such as delay and packet loss, because iOAM metrics are different 
for different flows. Neither sampling, how can you insure that the flow you 
want its iOAM metrics will be sampled? The iOAM metrics, especially the delay 
and packet loss, should be exported in time, for example in one second. I don't 
think IPFIX is the right protocol.

I do not object this doc to move forward if we can reach this consensus.



Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com
 
发件人： thomas.g...@swisscom.com
发送时间： 2023-01-04 00:20
收件人： li_zhenqi...@hotmail.com; zhoutianran=40huawei@dmarc.ietf.org; 
i...@ietf.org
抄送： opsawg@ietf.org
主题： RE: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Dear Zhenqiang,
 
Thanks a lot for your feedback.
 
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641, 
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is 
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in 
2018 but not standardized within IETF as a transport protocol for YANG push. It 
did not find enough traction. A good overview about the state of the union 
about YANG push in the industry is a presentation I gave at the IEPG, slide 
3-6, 
http://www.iepg.org/2022-11-06-ietf115/slides-115-iepg-sessa-network-operator-challenges-in-network-telemetry-data-mesh-integration-thomas-graf-00.pdf.
 
RFC 9232 gives a good overview about Network Telemetry. In section 3.1.3 
(https://datatracker.ietf.org/doc/html/rfc9232#section-3.1.3) is a summary of 
the protocols for forwarding plane data collection. As you pointed out, it 
makes sense to use one common Network Telemetry protocol. However today we have 
3, IPFIX for data plane, BMP for BGP routing control-plane and YANG push for 
management-plane. These 3 protocols have different unique mandatory 
characteristics. IPFIX allows data reduction with sampling (RFC5476) an 
aggregation (RFC7015). While BMP allows to mirror BGP PDU's (lightweight) and 
add device dimensions such as peering, RIB and route-policy (context). And YANG 
push allows through its sophisticated data modelling to have configurational 
and operational metrics within a single data model.
 
In OPSAWG presentation of IETF 115 
(https://datatracker.ietf.org/meeting/115/materials/slides-115-opsawg-export-of-on-path-delay-in-ipfix-00.pdf)
 I described in slide 2 and 3 the benefit of adding the delay measurements to 
IPFIX. Having one single protocol for data-plane data collection. The ability 
to perform data correlation and aggregation with an existing proven IPFIX 
protocol. Does that resonate with you? 
 
The use cases are described in section 5 of the draft 
(https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-on-path-telemetry-01#section-5).
 Able to see for a given egress interface, BGP next-hop or SRv6 traffic 
engineered path or active segment how much delay at which node we accumulate. 
With YANG push this would be rather difficult and expensive to achieve. This 
was also confirmed by large network operators in their first on-path delay 
measurement deployments.
 
Best wishes
Thomas
 
From: ippm  On Behalf Of li_zhenqi...@hotmail.com
Sent: Tuesday, January 3, 2023 4:51 PM
To: Tianran Zhou ; ippm 
Cc: opsawg@ietf.org
Subject: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
 
Hi Tianran and all,
 
Why not use one protocol, such as grpc, to export all the iOAM metrics? It is 
ok to export one way delay in IPFIX. If other metrics, such as queue depth, 
buffer occupancy, etc,  have to be exported in grpc, it is not necessory to 
export one way delay in IPFIX.
 


Best Regards,
Zhenqiang Li
 
li_zhenqi...@hotmail.com
 
发件人： Tianran Zhou
发送时间： 2022-12-22 10:40
收件人： 'IETF IPPM WG'
抄送： opsawg@ietf.org
主题： [ippm] FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Hi IPPM,
 
The OPSAWG just started a WG adoption call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
 
There are performance metrics registrations within this draft.
We would really appreciate your comments from IPPM.
 
Thanks,
Tianran
 
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年12月22日 10:26
收件人: opsawg@ietf.org
抄送: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Jean Quilbeuf]

Hi Thomas and Benoit,
The changes are perfectly addressing my comments, thanks.

Best,
Jean

From: Benoit Claise
Sent: Thursday 5 January 2023 13:19
To: thomas.g...@swisscom.com; Jean Quilbeuf ; 
zhoutianran=40huawei@dmarc.ietf.org; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: Re: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear all,
On 1/5/2023 9:48 AM, thomas.g...@swisscom.com 
wrote:
Dear Jean,

Thanks a lot for the comprehensive review and comments. They all make perfectly 
sense.

I merged them into the -02 version 
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

And here the diff: 
https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/blob/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt

Correct URL is actually (raw instead of blog):

https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-tgraf-opsawg-ipfix-on-path-telemetry-01.txt=https://github.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/raw/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt



Regards, Benoit

Please let me know if I addressed all your points. I will submit -02 once the 
ongoing adoption call is finished and the document name changed.

Best wishes
Thomas

From: Jean Quilbeuf 
Sent: Wednesday, January 4, 2023 6:11 PM
To: Tianran Zhou 
;
 opsawg@ietf.org
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: RE: WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear All,
I support the adoption of this draft.

I have a few very minor comments below.

Best,
Jean


Section 1, paragraph 4:

OLD
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered as registered performance metrics [RFC8911] in the "IANA ..."

NEW
   "Since these IPFIX IEs are performance metrics [RFC8911], they must be
registered in the "IANA ..."

Section 3.4.2

OLD
  "For each , Singleton one of the following [..] applies "

NEW
  "For each  Singleton, one of the following [..] applies "

Section 3.4.2.3. (Max)

I would add the scope of n from RFC6049 after the formula
  "where all packets n = 1 through N have finite singleton delays."


Section 6.2.X

  "OctedDelta" is not defined, do you mean deltaCounter as in 
https://www.rfc-editor.org/rfc/rfc7012#section-3.2.3

Section 7.2
   Computing the average from PathDelaySumDeltaMicroseconds seems unecessary as 
PathDelayMeanDeltaMicroseconds already exports it. Maybe state that the 
advantage of pushing that computation to the collector is to avoid doing too 
much computation in the router?

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
Sent: Thursday 22 December 2022 02:26
To: opsawg@ietf.org
Cc: 
draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: [OPSAWG] WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Hi WG,

This mail starts a WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/


Please reply your supports or objections.

We would really appreciate your comments.


Since there are holidays, this call will last for 3 weeks, and end on Thursday, 
Jan 12, 2023.

Cheers,
Tianran (as co-chairs)

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg