<div dir="ltr"><div dir="ltr">Hi all,<div class="gmail_extra"><br><div class="gmail_quote">On 20 September 2018 at 22:00, Lucimara Desiderá <span dir="ltr"><<a href="mailto:lucimara@cert.br" target="_blank">lucimara@cert.br</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello<br>
<br>
As I told in a previous message, there are a few crucial points we need<br>
to decide in order to go for the final version of the BCOP on "Minimum<br>
security requirements for CPEs acquisition".<br>
<br>
During the meeting at the LACNIC29 we had some discussion on those<br>
topics, but during the last period of comments, other people questioned<br>
those points. So I think the best is bringing the discussion to the list<br>
and try to reach consensus.<br>
<br></blockquote><div><br></div><div>Thanks,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The two main issues are whether choosing MUST or SHOULD on requirements<br>
regarding:<br>
<br>
<br>
1) encryption for management interface from the WAN (MR-03 and FR-02)<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br></blockquote><div><br></div><div><br></div><div><b>1) encryption for management interface from the WAN (MR-03 and FR-02)</b></div><div><br></div><div><b>I consider that this requirement should be SHOULD</b>, because most of</div><div>Current protocols that I know do not support an encryption level as proposed.</div><div>Also considering that sniffing WAN traffic in real life is not so easy,</div><div>intercept WAN interface (Coaxial, Fiber, etc.) and the type of modulation</div><div>is not something so simple to do, and if someone does it, then it's because</div><div>already has privileges within the CPE, where can surely find the</div><div>credentials to access the management platform in WAN.</div><div><br></div><div>According to this, I do not consider it to be an important requirement for a MUST.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Requiring MUST means:<br>
<br>
- in case of remote shell connection, no Telnet, only SSH<br>
- in case of other tools for remote management, it will have to<br>
support an be configured for encrypted channel (e.g. TR-069 must use<br>
TLS/HTTPS)<br>
<br>
* Leaving as SHOULD<br>
<br>
- will keep the door open to sniff the credentials and any other<br>
management traffic. That will probably result on the compromise of<br>
the management password and consequently all the devices that uses<br>
the same password.<br>
<br>
<br>
So:<br>
<br>
- Does anybody DISAGREE on MUST?<br>
<br>
- Does anybody AGREE on MUST?<br>
<br>
==============================<wbr>==============================<wbr>===============<br>
<br>
2) Anti-spoofing filtering (FR-15 and IF-08)<br>
------------------------------<wbr>----------------<br></blockquote><div><br></div><div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br class="gmail-Apple-interchange-newline"><b>2) Anti-spoofing filtering (FR-15 and IF-08)</b></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">IMHO, it would be ideal if you could have an effective way to apply BCP-38</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">closer to the source (in the CPE), however, in a practical way, sometimes we need</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">allow to spoof the traffic in an internal segment without the filtering causing problems</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">In some occasions (testing, probes), it is necessary to spoof the IP addresses, also</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">some applications need it for its correct operation, however, if we had filters in the CPE, we could not do tests in a LAN---CPE---LAN scheme.</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><b>I believe that this requirement should be MUST</b>, with the posibility to deactivate this option for testing purposes.</div><div><br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- RFC 6092 (REC-5) states MUST for anti spoofing filtering<br>
- the "IPv4 and IPv6 eRouter Specification" from CableLabs<br>
recommends that implementation as "critical".<br>
<br>
- But RFC 7084 made a downgrade of that requirement<br>
S-2: The IPv6 CE router SHOULD support ingress filtering<br>
accordance with BCP 38 [RFC2827]. Note that this requirement<br>
was downgraded from a MUST from RFC 6204 due to the difficulty<br>
of implementation in the CE router and the feature's redundancy<br>
with upstream router ingress filtering.<br>
<br>
* Requiring MUST<br>
- unfortunately many (if not most) upstream does not run ingress<br>
filtering<br>
- the closest to the origin the better to kill spoofed traffic<br>
- possibly is less complex implementing the filters in single homed<br>
devices<br>
- less spoofed traffic means less DDoS attacks, and so less headache<br>
<br>
* Leaving as SHOULD<br>
- will keep the door open to abuse for DDoS attacks<br>
- possibly the device will be cheaper upfront but probably will cost<br>
more latter with secondary costs (unwanted DDoS traffic)<br>
<br>
<br>
So:<br>
<br>
- Does anybody DISAGREE on MUST?<br>
<br>
- Does anybody AGREE on MUST?<br>
<br>
<br>
<br>
Best regards,<br>
Lucimara<br></blockquote><div><br></div><div>Cheers,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
______________________________<wbr>_________________<br>
BCOP mailing list<br>
<a href="mailto:BCOP@lacnog.org">BCOP@lacnog.org</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/bcop" rel="noreferrer" target="_blank">https://mail.lacnic.net/<wbr>mailman/listinfo/bcop</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:13.3333px">-- </span><br style="font-size:13.3333px"><div dir="ltr" style="font-size:13.3333px"><div><div style="font-size:13.3333px"><div style="font-size:13.3333px"><div style="font-size:13.3333px"><b>Fernando A. Quintero Londoño</b></div><div style="font-size:13.3333px">Director de Operaciones</div><div style="font-size:13.3333px">CEL : (+57) 300 579 23 80</div><div style="font-size:13.3333px"><b>CORPORACIÓN CSIETE</b></div><div style="font-size:13.3333px">RUTAN - Calle 67 # 52-22</div><div style="font-size:13.3333px">PBX (57+4) 516 77 70 Ext. 1161</div><div style="font-size:13.3333px">Medellín, Colombia</div><div style="font-size:13.3333px">Web: <a href="http://www.csiete.org" target="_blank">www.csiete.org</a></div></div></div></div><div><font color="#000000" face="Arial, Helvetica, sans-serif"><span style="line-height:16.64px"><br></span></font></div><div><font color="#000000" face="Arial, Helvetica, sans-serif"><span style="line-height:16.64px">Advertencia legal: </span></font></div><div><font color="#000000" face="Arial, Helvetica, sans-serif"><span style="line-height:16.64px">Este mensaje y, en su caso, los ficheros anexos son confidenciales, especialmente en lo que respecta a los datos personales, y se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Las opiniones contenidas en este mensaje y en los archivos adjuntos, pertenecen exclusivamente a su remitente y no representan la opinión de la empresa salvo que se diga expresamente y el remitente esté autorizado para ello. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros.</span></font></div><div><br></div><div><font color="#000000" face="Arial, Helvetica, sans-serif"><span style="line-height:16.64px">Disclaimer:</span></font></div><div><font color="#000000" face="Arial, Helvetica, sans-serif"><span style="line-height:16.64px">This message and any attached files transmitted with it, is confidential, especially as regards personal data. It is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient and have received this information in error or have accessed it for any reason, please notify us of this fact by email reply and then destroy or delete the message, refraining from any reproduction, use, alteration, filing or communication to third parties of this message and attached files on penalty of incurring legal responsibilities. The opinions contained in this message and the attached archives, belong exclusively to their sender and they do not represent the opinion of the company unless it is said specifically and the sender is authorized for it. The sender does not guarantee the integrity, the accuracy, the swift delivery or the security of this email transmission, and assumes no responsibility for any possible damage incurred through data capture, virus incorporation or any manipulation carried out by third parties.</span></font></div></div></div></div></div></div></div>
</div></div></div>