Andy, Adding the available IPv6 statistics will indeed clear my DISCUSS and allow me to ballot a supportive YES __ Regards -éric On 16/01/2023, 18:35, "Andrew S2" <andrew.s2@xxxxxxxxxxx <mailto:andrew.s2@xxxxxxxxxxx>> wrote: Thanks to Éric and Dave for your reviews, and thanks to all of the other reviewers too. I appreciate your helping to improve this document. We'll take some time to look through all the comments and address them in a new version of the draft (or clarify with their authors), hopefully before too long. Briefly, we'd be very happy to add IPv6 statistics to the next version of the document, so I hope that will address your DISCUSS, Éric. Many thanks, Andy -----Original Message----- From: Eric Vyncke (evyncke) <evyncke@xxxxxxxxx <mailto:evyncke@xxxxxxxxx>> Sent: 16 January 2023 16:10 To: Dave Thaler <dthaler@xxxxxxxxxxxxx <mailto:dthaler@xxxxxxxxxxxxx>>; int-dir@xxxxxxxx <mailto:int-dir@xxxxxxxx> Cc: draft-ietf-opsec-indicators-of-compromise.all@xxxxxxxx <mailto:draft-ietf-opsec-indicators-of-compromise.all@xxxxxxxx>; last-call@xxxxxxxx <mailto:last-call@xxxxxxxx> Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-opsec-indicators-of-compromise-03 [You don't often get email from evyncke@xxxxxxxxx <mailto:evyncke@xxxxxxxxx>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ] Thank you, Dave, for your review. As you may have read, I have used your review in my ballot. I balloted DISCUSS though mainly because one statistic misses IPv6 data (even if they are available) => easy to fix by the authors but your points should also be addressed. Regards -éric On 13/01/2023, 23:55, "Int-dir on behalf of Dave Thaler via Datatracker" <int-dir-bounces@xxxxxxxx <mailto:int-dir-bounces@xxxxxxxx> <mailto:int-dir-bounces@xxxxxxxx <mailto:int-dir-bounces@xxxxxxxx>> on behalf of noreply@xxxxxxxx <mailto:noreply@xxxxxxxx> <mailto:noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>>> wrote: Reviewer: Dave Thaler Review result: Ready with Issues In my view the following issues should be addressed before publication. Section 3.1, page 7: > Domain names are more specific than IP addresses (as multiple domain > names may be associated with a single IP address) But the converse is also true... multiple IP addresses may be associated with a single domain name, so the conclusion that domain names are more specific than IP addresses is not true in general. Indeed, the pyramid (figure 1) shows IP addresses as more precise than domain names, which to me is synonymous with more specific, just as hashes are more specific than IP addresses. This seems a contradiction in the text quoted above. Section 3.2: > To be of use to defenders, IoCs must first be discovered, assessed, > shared, and deployed. I don't understand what it means for IoCs to be "deployed". Section 3.1 gave examples of IoCs such as "IPv4 and IPv6 addresses in network traffic", but I don't know what it means to say "IPv4 and IPv6 addresses in network traffic must be deployed". I suspect this is using some other definition of IoC than what the text prior to here presented. You deploy some detector or some other type of defense. The draft does not define IoC as a detector or any other type of defense, it's defined as the thing you look at. So you have to _deploy_ something that looks at an IoC, not an IoC itself. Either fix the text here or redefine IoC earlier in the document. Section 4.1.4 > There is significant benefit to be had from the sharing of IoCs and > they can be easily shared for two main reasons: firstly, indicators > are easy to distribute Should "indicators" instead be "IoCs"? (But see previous comment which applies here too.) > indicators are easy to distribute as they are textual This statement seems imprecise. For example, an IP address is not textual. It has a textual representation, but an IPv4 address itself is a 32-bit binary value and an IPv6 address is a 128-bit binary value. Section 5.1.1: > IPv4 addresses are > becoming increasingly fragile due to addresses growing scarce Explain. The fact that they're growing scarce means they should be more painful for an attacker to change, which means they should be increasingly LESS fragile per the arguments earlier in the document. Separately, you can also argue that IPv4 address are becoming increasingly less _precise_ due to introduction of carrier grade NATs. _______________________________________________ Int-dir mailing list Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx> <mailto:Int-dir@xxxxxxxx <mailto:Int-dir@xxxxxxxx>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-dir&data=05%7C01%7Candrew.s2%40ncsc.gov.uk%7C249b36ef763a454ebe3708daf7dc270f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638094822177775582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FikAFtEFOd74Cpc3S%2BQ1VsOg9nDJjUHPPXhK18I%2FH3U%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-dir&data=05%7C01%7Candrew.s2%40ncsc.gov.uk%7C249b36ef763a454ebe3708daf7dc270f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638094822177775582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FikAFtEFOd74Cpc3S%2BQ1VsOg9nDJjUHPPXhK18I%2FH3U%3D&reserved=0> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-dir&data=05%7C01%7Candrew.s2%40ncsc.gov.uk%7C249b36ef763a454ebe3708daf7dc270f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638094822177775582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FikAFtEFOd74Cpc3S%2BQ1VsOg9nDJjUHPPXhK18I%2FH3U%3D&reserved=0> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fint-dir&data=05%7C01%7Candrew.s2%40ncsc.gov.uk%7C249b36ef763a454ebe3708daf7dc270f%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638094822177775582%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FikAFtEFOd74Cpc3S%2BQ1VsOg9nDJjUHPPXhK18I%2FH3U%3D&reserved=0>> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
