<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 25, 2022, at 10:26 AM, Thomas, Matthew via NCAP-Discuss <<a href="mailto:ncap-discuss@icann.org" class="">ncap-discuss@icann.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: CourierNewPSMT; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">A server can be configured to have various ports open but nothing would actually be listening on those ports via a set of IPTABLE rules. The connection attempts would be logged but no data would be exchanged besides what is basically in the IP headers - IP address, port, and you would probably add a timestamp. This still enables the identification of clients and understanding of what services/ports they are trying to attempt to reach.</span><br style="caret-color: rgb(0, 0, 0); font-family: CourierNewPSMT; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote></div><br class=""><div class=""><div class="">On February 9, Warren gave a presentation to the NCAP DG about CI vs. ECI that included this text:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">Proposed / comparison<br class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Returns the address of a "parking page"<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• The user is presented with a page (web) explaining the issue, and mitigations <br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Causes the user to connect to an outside system<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Collision visibility is the affected nameserves and the actual users</div></blockquote><br class=""></div><div class="">I’m concerned that some in this group have been talking for a long time about proposing ECI but have not actually described its behavior in any detail. Matt and Warren are describing two implementations with significant differences.</div><div class=""><br class=""></div><div class="">The details matter because different solutions would allow more sensitive data to be exfiltrated and would cause varying degrees of disruption to client applications. For TCP-based protocols, silently dropping the SYN vs. actively refusing the connection vs. providing a minimal protocol interaction all produce potentially very different client behavior.</div><div class=""><br class=""></div><div class="">A proposal for ECI without specifying technically how it would work cannot be properly evaluated by the Board.</div></div><div class=""><br class=""></div><div class="">Matt (L.)</div><div class=""><br class=""></div></body></html>