[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-isis-area-proxy-12: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-12: 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-lsr-isis-area-proxy/ -- COMMENT: -- Thanks for addressing and/or explaining my concerns. I've updated my ballot to No Objection. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' Discuss on draft-ietf-lsr-isis-area-proxy-10: (with DISCUSS)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-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-lsr-isis-area-proxy/ -- DISCUSS: -- I have a few minor discusses, which could be just because I'm not an ISIS expert. Please bear with me :) Multiple proxy system identifiers in a single area is a misconfiguration and each unique occurrence SHOULD be logged. This does not really answer what systems should do in this case? Use none of them? What would the implication be? Use the one advertised by most nodes? What would the risk be with that? The answers would be great additions to the Security Considerations :) The Area Leader and other candidates for Area Leader MAY withdraw the Area Proxy System Identifier when one or more Inside Routers are not advertising the Area Proxy Router Capability. This will disable Area Proxy functionality. Wouldn't this allow a malicious Inside Router to completely disable the Area Proxy functionality? Could this be part of an attack? Can this be mitigated somehow? Is there something to say about this for the Security Considerations? 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length|Proxy System ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proxy System Identifier continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This diagram seems incorrect. It shows 4 fields instead of 3. I suggest using: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-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-lsr-ospfv3-srv6-extensions/ -- COMMENT: -- Thanks to Ketan for the constructive discussion and changes. I've updated my ballot to No Objection. I do hope the WG will consider properly replacing or updating RFC5340, but that is not this document's problem. NIT: IPSec -> IPsec (no need for new draft, it can be fixed during the RFC editing cycle) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-ip-flexalgo-13: 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-lsr-ip-flexalgo/ -- COMMENT: -- NITS: A node MUST participate in a Flex-Algorithm to be: - Able to compute path for such Flex-Algorithm - Part of the topology for such Flex-Algorithm This is an odd use of MUST. Section 5.2 states the length of the Algorithm field, but not of the Type: or Length: fields. (either do it for all or for none?) Similar in Section 6.2 and 6.3.1 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' Discuss on draft-ietf-lsr-ospfv3-srv6-extensions-12: (with DISCUSS)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-ospfv3-srv6-extensions-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-lsr-ospfv3-srv6-extensions/ -- DISCUSS: -- I have a DISCUSS similar to Roman: Existing security extensions as described in [RFC5340] and [RFC8362] apply to these SRv6 extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. RFC5340 does say to use IPsec, but because of the "group" setting, IKE could not be used (I guess it pre-dates or didn't want to use Group DOI (GDOI) RFC3547 and Group Secure Association Key Management Protocol (GSAKMP) RFC4535). But RFC 4552 is recommending IPsec with manual keying, which is no longer really possible with AEAD ciphers (eg AES-GCM, which you would want to use for performance). It does state: Future specifications can explore the usage of protocols like Kerberized Internet Negotiation of Keys/Group Secure Association Key Management Protocol (KINK/GSAKMP) when they are widely available. But I don't think KINK/GSAKMP became widely available. GDOI has seen some but not much implementation. Furthermore, RFC4535 is also a (not widely implemented) IKEv1 extension. This cannot be recommended anymore because IKEv1 itself is obsolete (see RFC9395) Updated advise would be to use draft-ietf-ipsecme-g-ikev2 "Group Key Management using IKEv2, but again we don't know yet if this will be widely available. That puts us back at "use manual keying or this soon to hopefully be available IKEv2 RFC", except that with AEADs, we also cannot recommend manual keying anymore. I am not sure what to recommend as text here. Removing all IKEv1 references and putting draft-ietf-ipsecme-g-ikev2 there and saying manual keying MUST NOT be used is not a good security recommendation either. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-ospf-terminology-08: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-ospf-terminology-08: 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-lsr-ospf-terminology/ -- COMMENT: -- I am a little puzzled by a standalone document that changes these words. Implementers are still forced to read the original RFCs this document updates and the original words are all over the place in those documents. It would have made more sense to me to incorporate these new words in bis documents. I agree with Eric that IANA should keep the old name in a note for clarification. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-pce-discovery-security-support-12: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-12: 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-lsr-pce-discovery-security-support/ -- COMMENT: -- A receiving entity MUST NOT interpret invalid UTF-8 sequences. What must it do then, when encountering invalid UTF-8 ? In any case, an implementation SHOULD [...] So not in ANY case then? :-) nits: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |KeyID | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 6 Length: 4 Why does it not say "Length = 4" like it says "Type = 6" ? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Paul Wouters' No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
Paul Wouters has entered the following ballot position for draft-ietf-lsr-isis-rfc5316bis-04: 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-lsr-isis-rfc5316bis/ -- COMMENT: -- I support Alvaro Retana's DISCUSS position. Could the example HMAC use in the Security Considerations section be updated from HMAC-MD5 to something more modern (eg HMAC-SHA2) or is there a valid operational reason to stick with HMAC-MD5 ? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
