Re: [Last-Call] Genart last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robert,

Thanks for the review. 

The changes made to take into account your comment can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/udp-ipfix/draft-ietf-opsawg-tsvwg-udp-ipfix.txt&url_2=https://boucadair.github.io/udp-ipfix/Robert-Sparks-Review/draft-ietf-opsawg-tsvwg-udp-ipfix.txt.

Please see more context inline.

Cheers,
Med

> -----Message d'origine-----
> De : Robert Sparks via Datatracker <noreply@xxxxxxxx>
> Envoyé : vendredi 3 mai 2024 17:55
> À : gen-art@xxxxxxxx
> Cc : draft-ietf-opsawg-tsvwg-udp-ipfix.all@xxxxxxxx; last-
> call@xxxxxxxx; opsawg@xxxxxxxx
> Objet : Genart last call review of draft-ietf-opsawg-tsvwg-udp-
> ipfix-08
> 
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103625289%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=adEyrIGMb6Q9ax9ZGQ2GzW%
> 2FsWbv2g1Dx7%2F0gUP0guH0%3D&reserved=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-08
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%
> 2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh
> amed.boucadair%40orange.com%7C6d87cb3283c64ed6d19e08dc6b896870%7C
> 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503485103636074%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FDTBvCsYxqbgHiEkXmhMU
> D9uXisLHgPnje4wrHvCanA%3D&reserved=0>.
> 
> Document: draft-ietf-opsawg-tsvwg-udp-ipfix-18
> Reviewer: Robert Sparks
> Review Date: 2024-05-03
> IETF LC End Date: 2024-05-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready with nits
> 
> Consider discussing, or point to existing considerations about,
> what should happen when you are exporting very large udp options
> (perhaps constructed maliciously to be as large as possible) and
> you are carrying the exported values over UDP (Section 10.3 of
> RFC7011) and run out of room.
> 

[Med] These considerations are not specific to this document and fall under the generic considerations in base spec 7011 (Section 10.3.3). After think about this, I added a new section called (ops considerations) with the following content: 

* moved the text about reduced-size encoding to that section
* encourage the use of reduced-size encoding in the presence of EXP/UEXP (that is the *ExID IEs) takes precedence and thus their flags can be ignored
* add a pointer to transport (including MTU) IPFIX cons.

Also, we are not mentioning misbehaving nodes may generate large amount of data, etc. because that falls as well under the generic cons in RFC7011:

   Direct DoS attacks can also involve state exhaustion, whether at the
   transport layer (e.g., by creating a large number of pending
   connections) or within the IPFIX Collecting Process itself (e.g., by
   sending Flow Records pending Template or scope information, or a
   large amount of Options Template Records, etc.).

Added an explicit pointer to section 11 of 7011.

> There are several references by section number into I-D.ietf-
> tsvwg-udp-options that have become stale. For instance the
> pointer to section 22 in the security considerations should be
> pointing to section 24.
> 
> 
[Med] Good catch. Thanks.

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux