[OPSAWG]Paul Wouters' Discuss on draft-ietf-opsawg-ipfix-tcpo-v6eh-17: (with DISCUSS)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-ipfix-tcpo-v6eh-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/ -- DISCUSS: -- This specification deprecates the ipv6ExtensionHeaders IPFIX IE in favor of the new IEs defined in this document. I don't see which RFC those were in, because this document does not Update: or Obsolete: the RFC that defined the ipv6ExtensionHeaders IPFIX IE This specification deprecates the tcpOptions IE Same here. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Paul Wouters' No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-14: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ -- COMMENT: -- Thanks for the update/rewrite of the document. It reads much better now. I've updated my ballot to No Objection. ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG] Paul Wouters' Abstain on draft-ietf-opsawg-mud-acceptable-urls-11: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-acceptable-urls-11: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-acceptable-urls/ -- COMMENT: -- I agree with many things from the SecDir review from Christian Huitema: https://datatracker.ietf.org/doc/review-ietf-opsawg-mud-acceptable-urls-11-secdir-telechat-huitema-2024-04-02/ I think the concept of small vs big changes is problematic. There is also the issue of any lower version being seen as a roll back attack. If successfull, it would prevent an administrator to downgrade the MUD file after finding that it is preventing proper functioning. A device has a firmware version and a MUD file that belongs to that version. It seems this draft says that the MUD file can be upgraded to firmware versions it was not intended for. It seems the simple fix is to not do that. Updating a MUD file to plug a security hole seems the wrong mechanism. Instead of updating the MUD file, the firmware should be updated (and that firmware should come with a new MUD file covering that firmware version) So I am confused about the mechanim of the firmware handing a URL to the MUD manager, who then picks up the MUD file from the manufacturor. In a way, one could see this as a firmware that has a bit of external firmware hosted elsewhere. And these two can get out of sync. To me that just seems like broken firmware and building a protocol mechanism to resolve this seems the wrong way to fix this. Similarly, changing a MUD file location seems to be something that should be addressed in a firmware update - including updating the location of future firmware updates. I don't see a way for this document to resolve my issues, so instead of balloting DISCUSS, I am ABSTAINing. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-mud-iot-dns-considerations-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-iot-dns-considerations/ -- DISCUSS: -- I unfortunately find this document very hard to understand. Overall, I think it would do better to split out the use cases. It seems to conflate or mix three distinct use cases: 1) A CPE with firewall+MUD-controller and an IoT MUD client, 2) A CPE with firewall with separate MUD controller and IoT MUD client, 3) An IoT device and a centralized enterprise MUD controller and centralized enterprise firewalling. This then gets more complicated due to different assumptions of where the DNS resolver lives: On the CPE, on the LAN, in the Enterprise, on the public Internet, and what DNS protocols to use: port 53 or DoH/DoT/DoQ. After reading the document I do not find clear guidance on the MUD+DNS issue. On the contrary, I feel like this is impossible to deploy. If the MUD controller and DNS resolver are not within the same CPE, it is unclear how communication should work to synchronize the required DNS lookups, results and firewall synchronisation between MUD controller, IoT device and firewall/router device. It seems a protocol needs to be specified but hasn't. Lots of talk about synchronizing the DNS servers to use and do independent DNS lookups seems very problematic. I feel that MUD still needs to evolve first to be further specified as a technology, before a document about (remainig) DNS considerations can be published. I've put my specific item feedback in the comments section below. -- COMMENT: -- In the Introduction the numbered sections are wrong (eg "second section", "third section") An issue is raised about delays as a result of a cold cache. I'm not sure why that matters. It is a few seconds delay that should only happen once every couple of weeks ? Section 3.1.1 does not take prefetching into account ? By doing the DNS lookups when the traffic occurs, then a passive attacker can see when the device is active Isn't this always the case? No application splits the DNS lookup from using the obtained IP by a large amount of time to counter traffic analyses ? Although the app might cache the result and re-use long past the TTL time, which is a problem if the MUD controller and firewall base any ACL addition and removal on DNS TTLs. This does not require access to all on-path data, just to the DNS requests to the bottom level of the DNS tree. I don't fully understand this? If query-minimalization is used, does this still apply? I don't think so and if you care about DNS privacy, then surely you use query-minimalization and perhaps a DoT/DoH to an external party on top? Aside from the list of records being incomplete, the list may have changed between the time that the MUD controller did the lookup and the time that the IoT device did the lookup Isn't the IoT device forced to use the firewall/MUD DNS Server? If not, there is already a DNS extraction channel and MUD has lost already. In order to compensate for this, the MUD controller SHOULD regularly perform DNS lookups in order to never have stale data. This will cause a lot of unused lookups to be forever refreshed. This seems bad and with ephemeral redirections (eg 32217321835.pool.hue.philips.com) seem to use up a lot of memory on the router for DNS and firewall rules. it may be necessary to avoid local recursive resolvers. Why? Shouldn't the IoT device be FORCED to use the local firewall/MUD associated DNS server? (see earlier point) The MUD controller SHOULD incorporate its own recursive caching DNS server. What if the network firewalls all DNS except the allowed one? After all, we want to protect the network by doing DNS filtering? If you think you need the MUD controller to limit DNS queries it sends to the DNS recursive, then perhaps the MUD application should honour TTL and not do repeated lookups? If they would be outside of the TTL, then you have to do a real lookup against the real DNS server anyway? But even so, a DNS caching server should be able to easilly serve many queries that are coming from DNS cache. These lookups must be rate limited
[OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-9092-update-11: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-9092-update-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ -- COMMENT: -- Thanks for the discussion on the items raised. I've updated my ballot to No Objection (I did not ballot 'Yes' because I did not find all my raised points addressed, but these issues did not raise to the level requiring further discussion) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-9092-update-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ -- DISCUSS: -- "Handling Ballot Positions" - see https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ I have a number of DISCUSSes, none of which should be hard to address or talk out :) #1 document track The document is Standards Track, and so are the docs is Obsoletes/Updates ([RFC2725] and [RFC4012]), but the document also claims "change control effectively lies in the operator community". Normally, that would mean the IETF publishes this as Informational. But of course that would raise the issue that an Informational would Obsolete a Standards Track document. Some discussion on this would be good. #2 Transport Security There are quite a few sentences scattered through the document about transport security that are not aligned, see: The URL uses HTTPS, so the WebPKI provides authentication So is HTTPS mandatory? I guess not since (see below) FTP is allowed as URL too. the RIR's FTP [RFC0959] services SHOULD be used To speak in the words of the great Monty Python, "An active or passive swallow?" More seriously, can we avoid SHOULDing the FTP protocol? Are these resources not made available over HTTP? If they are, can we SHOULD that instead? Note the paragraph above it says: "Historically, [...] often without consistent authentication". I wouldn't call that "Historically" if you are are promoting FTP and allow "unsigned" files. The geofeed files MUST be published via and fetched using HTTPS [RFC9110]. Uhm. So what about FTP now? The Security Considerations could bundle all the talk about HTTPS and FTP and put in one clear clause here, mentioning that due to lack of universal signing, it is sadly super important to have transport security protection (eg HTTPS, not FTP) #3 Signature and white space requirements are a bit troubling Trailing blank lines MUST NOT appear at the end of the file. That's rather strong. Should the file be rejected if a blanc line appears at the end? If not, I wonder why to even mention this, especially with 2119 force. Based on: If the authenticator is not in the canonical form described above, then, the authenticator is invalid. That is a "yes the file should be rejected if it has a trailing blanc line". I think that is unwise, I would like to hear the reasoning behind this. When present, such end-of-file markers MUST NOT be covered by the digital signature. This is going to cause problems if people make detached signatures of the file. What is the reason for this requirement? The CMS signature does not cover the signature lines. This gets really complicated now, when we read the above item on blanc lines. Does this mean the blanc line MUST NOT appear before these # comments? Or not after these comments? Or both? Can there be a blanc line between geofeed content and signature? How about two blanc lines? #4 Misc. Security comments The address range of the signing certificate MUST cover all prefixes in the signed geofeed file. I vaguely remember huge problems with such similar requirement. The document is not clear what to do when this is not the case? Reject everything? Or only accept those entries that ARE covered? More guidance is needed here. The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]. What must one do if this does include it? As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined in Section 2.2.3.5 of [RFC3779]. What must one do if this does include it? The Certificate Authority (CA) SHOULD sign only one geofeed file with each generated private key and SHOULD generate a new key pair for each new version of a perticular geofeed file. The CA MUST generate a new End Entity (EE) certificate for each signing of a particular geofeed file. When can these SHOULDs be ignored? Eg it _is_ possible to use the same key but a different EE cert? Also, what is the reason for needing to generate a new EE cert per geofeed version file? What issue is solved by not allowing a long lived EE cert to do this job?
[OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-rfc7125-update-06: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-rfc7125-update-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc7125-update/ -- COMMENT: -- Maybe add reference for "reduced-size encoding" which is not defined in this document and no pointer is given to elsewhere on what this means. NITS: [IPFIX] reference is broken. It contains: https://datatracker.ietf.org/doc/html/%3Chttps://www.iana.org/assignments/ipfix/ipfix.xhtml ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' Yes on draft-ietf-opsawg-add-encrypted-dns-11: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-add-encrypted-dns-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/ -- COMMENT: -- This document targets deployments where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614]. I don't understand what this sentence is trying to say. Does table 7 really clarify the sentences used earlier that say exactly the same thing but more compact? Why "Expert Review" and not "Specification Required" or "RFC Required" ? Registration requests are to be sent to radius-dhcp-rev...@ietf.org I thought we didn't put these emails in the documents anymore? But I guess IANA will get back to you on that. NITS: As a reminder, I would remove this part of the text. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' Yes on draft-ietf-opsawg-tlstm-update-13: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-tlstm-update-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/ -- COMMENT: -- Thanks for addressing my concerns ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-tlstm-update-12: (with DISCUSS and COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-tlstm-update-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/ -- DISCUSS: -- Thanks for this document update. I have a minor DISCUSS that should be easy to resolve, and some comments. Should Section 2.3 or the Security Considerations not reference RFC 9325 "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" ? For one thing, it documents that if one needs to still use TLS 1.2, what options should be used or avoided. -- COMMENT: -- REVISION"20220909Z" DESCRIPTION "This version of this MIB module is part of RFC ; see the RFC itself for full legal notices. This version: It will be easy to miss this "RFC " for the RFC Editor, can be make a clearer note for the RFC editor to update that? The REVISION is a date. Should that be updated to the publication date, or is it used as a sort of early code point ? Historically, the 1-octet hashing algorithm identifier was based on the IANA TLS HashAlgorithm Registry (RFC 5246); however, this registry is only applicable to (D)TLS protocol versions prior to 1.3, which are now designated as obsolete and are not expected to ever support additional values. I'm not sure "obsolete" is the right word? Also, looking at: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18 snmpTlstmCertCommonName OBJECT-IDENTITY I don't see a note the registry is closed. Perhaps weaken the claim to just "however, this registry is no longer in use for TLS 1.3 and above and are not expected to have any new registrations added to it." The policy for updates is Expert Review. Why not specification required or RFC required? (Or split the range, as Roman alluded to as well) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Paul Wouters' No Objection on draft-ietf-opsawg-service-assurance-yang-10: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-opsawg-service-assurance-yang-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ -- COMMENT: -- I have not much to add to my esteemed collegue's Éric::Vyncke/128 review, two nits: | +--rw under-maintenance! | | +--rw contactstring This could use a freeform field or duration field to hold information about expected maintenance time, as that would be the main question anyone could have for the contact person :) description "This module extends the ietf-service-assurance-device module to add specific support for devices of ACME Corporation. "; I would somehow put in the Example word in there to avoid anyone thinking that this is a real definition. I know it is stated before, but implementers just scanning code might miss it :) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
