[OPSAWG] Secdir last call review of draft-ietf-opsawg-sbom-access-14
Reviewer: Christian Huitema Review result: Ready I have reviewed the changes between draft-09, which I reviewed in September 2022, and draft-14, the most recent version. The main concern expressed in my review was that "defense at scale" might also enable "attack at scale". The authors were not entirely convinced that this applies to their draft, because they "are discussing a discovery mechanism, and that the mechanism itself does not provide access to the underlying data." The authors reinforced this point by stating in the introduction that "the model is a discovery mechanism, and on its own provides no access to the underlying data." The other counter argument was that there is a lot do be gained by disclosing vulnerabilities, and that for most devices vulnerabilities can be deduced from very simple and well known properties, such as the version of OpenWRT that is run by a Wi-Fi router. That is true, but my main concern was that having information available on the device itself was tantamount to flashing a "hack me now" sign. And I was specially concerned by having that information published by default by otherwise unconfigured devices. This, the author did fix. The paragraph in the security section now says: SBOMs provide an inventory of software. If software is available to an attacker, the attacker may well already be able to derive this very same software inventory. When this information resides on the endpoint itself, the endpoint SHOULD NOT provide unrestricted access by default. Other servers that offer the data MAY restrict access to SBOM information using appropriate authorization semantics within HTTP. (Followed by description of access control methods.) The "SHOULD NOT" does address my recommendation, and also mitigates somewhat the risk of having a server running on an open port on the device. I am also happy that the ambiguous text about "some of the readable data nodes ... considered sensitive or vulnerable in some network environments" has been removed. I am still concerned that the paragraph starting "SBOMs provide an inventory of software", as written, only hints at the potential attack, without describing it. But life is full of such little dissatisfaction... ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Call for presentation//FW: [116all] IETF 116 Preliminary Agenda
Topic: draft-eckert-ietf-and-energy-overview speaker: Toerless Eckert time slot: 5 minutes Warren proposed at IETF115 that i first should check with OPSAWG whether there is interest to adopt this work as WG item before deciding to go to individual submission track. So hereby wanted to bring this option up and quickly start the discussion / raise interest to review / comment more by the WG. (will post update before deadline). Cheers Toerless On Mon, Feb 27, 2023 at 08:05:41AM +, Tianran Zhou wrote: > Hi WG, > > The IETF116 preliminary agenda is posted. > The OPSAWG meeting is scheduled at 09:30 - 11:30 Tuesday Session I. > We open the call for presentation on the meeting. > Please send over your request with the topic, speaker, time slot to the > chairs. > > Look forward to seeing you in Yokohama. > > Cheers, > Tianran > > -Original Message- > From: 116all [mailto:116all-boun...@ietf.org] On Behalf Of IETF Agenda > Sent: Saturday, February 25, 2023 6:50 AM > To: IETF Announcement List > Cc: i...@ietf.org; 116...@ietf.org > Subject: [116all] IETF 116 Preliminary Agenda > > IETF 116 > Yokohama, Japan > March 25-31, 2023 > Hosted By: WIDE > > > The IETF 116 Preliminary Agenda has been posted. The final agenda will be > published on Friday, March 3, 2023. > > https://datatracker.ietf.org/meeting/116/agenda.html > https://datatracker.ietf.org/meeting/116/agenda.txt > > The preliminary agenda includes all planned WG, RG, and BoF sessions. > Information about side meetings will be available when the final agenda is > posted. > > IETF 116 Information: https://www.ietf.org/how/meetings/116/ > Register online at: https://registration.ietf.org/116/ > > Don’t forget to register for these exciting IETF 116 events! > > > Social Event > > The Osanbashi Pier's multipurpose hall will be transformed into a wonderful > social event location for IETF 116 attendees in Yokohama. > > Attendees will be delighted by the music of internationally renowned artist > Kaoru Watanabe, delicious food and a Japanese sake corner introducing > attendees to sake from all thirteen sake breweries in Kanagawa Prefecture. > > - Date: Thursday, March 30 > > - Start/End Times: 19:00 – 21:30 > > - Cost per ticket: $25 per ticket > > - Limit of tickets per attendee: Two per attendee. > > More information: > https://www.ietf.org/how/meetings/116/social/ > https://ietf116.jp/social-event/ > > > Hackathon > > Onsite signup: https://registration.ietf.org/116/new/hackathon_onsite/ > Remote signup: https://registration.ietf.org/116/new/hackathon_remote/ > More information: > https://www.ietf.org/how/runningcode/hackathons/116-hackathon/ > Keep up to date by subscribing to: > https://www.ietf.org/mailman/listinfo/hackathon > > > Code Sprint > > More information and signups: https://notes.ietf.org/notes-ietf-116-tools# > > -- > 116all mailing list > 116...@ietf.org > https://www.ietf.org/mailman/listinfo/116all -- --- t...@cs.fau.de ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)
Hi, we just posted an updated revision of "Green Networking Metrics" (https://datatracker.ietf.org/doc/draft-cx-green-metrics/), including various editorial improvements and incorporating highly useful feedback and suggestions from a number of people including Eve Schooler, Alexandru Petrescu, and Michael Welzl. The draft defines a set of "green" networking metrics that will be useful as basis for management and control applications that aim to reduce carbon footprint and hence require visibility into such metrics. We believe that in terms of scope, this draft falls into the intersection of opsawg and nmrg interest and we hope to have the opportunity to present at IETF 116 in Yokohama, hence we are crossposting to both groups. Personally I believe that opsawg may be the most suitable landing spot as the draft can be easily operationalized and is not as much concerned with open-ended research questions, but that is of course where we would appreciate feedback from the groups. Once a decision is made for the proper landing spot, hopefully immediately following IETF 116, we will post a new revision under the respective working group. FYI, here is the abstract of the draft: This document explains the need for network instrumentation that allows to assess the power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's energy efficiency and "greenness". On behalf of the coauthors --- Alex ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [recipe] And another new draft revision: Green Networking Metrics
Hello Eve,
thank you for your great feedback! And apologies for the long delay in
responding. Please find my responses inline, below. We will also be
posting an update to the draft momentarily with your feedback
incorporated (hence crossposting to opsawg)
Best
--- Alex
On 11/29/2022 11:53 PM, Schooler, Eve M wrote:
Hi Alex and co-authors,
Thanks for a very interesting read
(https://datatracker.ietf.org/doc/draft-cx-green-metrics/)!
Here is some informal feedback on the latest version of the draft document.
Best regards,
Eve
Eve M. Schooler, PhD
Principal Engineer & Director
Intel | CSO & NEX | Emerging IoT Networks
2200 Mission College Blvd., Santa Clara, CA, USA 95054
+1 650.868.7369
-
Abstract:
In the abstract there is reference to "power consumption, energy efficiency and carbon
footprint", for both network equipment and services provided over it - would be great to
describe the relationship between these three attributes somewhere. In the Intro, language is also
used re "environmental sustainability of networks", which may go beyond energy-related
metrics.
Section 1. Intro
- Why cite the Telefonica Consolidated annual report vs Sustainability report?
The consolidated report includes an extensive section on
sustainability along with the data. I am not aware of a separate
sustainability report (although I am sure it must exist).
Section 2. Definitions and Acronyms
- Include kWh
We have added it (and a few more)
Section 3. Energy Metrics
- For each bullet, give examples of existing metrics.
- 3rd bullet references energy intensity. Is this a term commonly used? Does it
need specific definition
- Either way, contrast this with carbon intensity.
The term "energy intensity" has been removed. We have also added
further explanation on the relationship between carbon footprint, energy
consumption, etc
3.1.1 Energy consumption Metrics
- Any thoughts/precedent on how to separate the carbon footprint of a device
from the networking aspects of the device?
I am not sure what you mean here exactly. Do you mean devices
performing both compute and networking? I think in general those would
be difficult to separate. I think if we can do a breakdown of the
device to the component level (cards and ports), that may already be
plenty.
- Are we only gaging router power consumption, or other network HW elements?
What about SW? Different parts of the stack?
The focus is on network HW elements (section 3.1 "Metrics related
to [networking] equipment"). It is probably difficult to attribute to
software in itself, although section 3.1.3 talks about the attribution
to functions realized as software ("Virtualization Considerations"). We
also added discussion in section 3.1.2 regarding additional factors such
as ""taxation" for unattributed energy use, for taking into account
sustainability of energy sources (energy-aware vs pollution-aware), for
potentially transposing those into CO2 emission factors, etc.
- Love the reference to ATIS, which makes me wonder about certification of the
numbers associated with the various device elements and the devices overall?
I totally agree that certification is super important and we
expanded on that aspect.
- Re "The second set of metrics reflects the actual power being drawn during
operation." What about embodied carbon, which for smaller devices such as phones is
a dominating factor?
This is an important point and discussion of this added in the
section on "Holistic Perspective". However, due to the myriads of
factors at play here, we did not add specific metrics, just mention that
corresponding metrics and discount factors (or pollution factors,
depending on perspective) could be defined.
- Odd to see the terms "kilooctet" and "gigaoctet"; why not simply kB or gB?
Yes to pico Joules.
Fixed it.
3.1.2 Other Metrics
- A common sustainability rating of the power source is carbon intensity. A
good publication to read, where carbon intensity is considered, but so is a
waste metric to capture environmental impact beyond energy and carbon:
+ Hossain, Md. Mohaimenul, Georges, Jean-Phillippe, Rondeau, Eric, Divoux,
Thierry. Energy, carbon and renewable energy: Candidate metrics for green-aware
routing? Sensors, 19(13), Feb 2019.
- "It may be possible to obtain such a rating from the energy operation"
+ I really like that the document includes such a statement. It would be
helpful for each of the metrics discussions to include: from whom the
measurements for the metric might originate
- If deployment of the device is outside a Data Center (DC) and actually is in
the wild, e.g., an RSU (road side unit), should the device be charged an energy
tax for releasing its heat into the atmosphere?
Thank you for the reference, indeed a great one! We added some
related discussion in Section 3.1.2 ("Green Metrics Beyond Energy
Consumption"). However, we decided to not add the discussion about
where m
[OPSAWG] Update on T+/TLS
Hello, authors. I’m not sure if you’re planning to request a speaking slot for IETF 116, but we would like to get an update of the current state of this work (and author’s thoughts on next steps). After publishing -01, there was a discussion on whether or not the obfuscation should be allowed within the TLS encap. I don’t think that was concluded, though it seems like there is more support for NO. Speaking as chair, I’d like to see this move forward, and perhaps it’s in or close to a state where we can do a WG LC? Thanks. Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
