<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="font-size: 14px; font-family: Calibri, sans-serif; color: rgb(0, 0, 0); "><br></div><span id="OLK_SRC_BODY_SECTION" style="font-size: 14px; font-family: Calibri, sans-serif; color: rgb(0, 0, 0); "><div dir="ltr">"NBNco have not started the whole cut copper and migrate over, just new installs. So Simon's idea would cost shift money from NBNCo to the RSP, but make actually migrating people far more complex, time consuming and difficult for the 8million or so PSTN services still out there (plus/minus a few million, but still significant). I'd suggest it's a great idea for post-implementation, but for the upcoming phase, I actually think it's something that'll make the RSP/NBNCo effort much harder, more costly and more fraught with failure.<div><br></div><div>MMC (watching from afar)."</div></div></span><div style="font-size: 14px; font-family: Calibri, sans-serif; color: rgb(0, 0, 0); "><br></div><div style="font-size: 14px; font-family: Calibri, sans-serif; ">Taking MMC's points a little further, if you are rolling out an FttP network select GPON, then I can understand some of the technical (and security) reasons of why NBN may wish to "own" the ONU. The risk of having potentially rogue devices on a GPON network could be problematic.</div><div style="font-size: 14px; font-family: Calibri, sans-serif; "><br></div><div style="font-size: 14px; font-family: Calibri, sans-serif; ">NBN Co. owning the ONU should help reduce the risk of unintended denial of service incidents due to faulty or incorrectly installed ONU (not necessarily help intentional denial of service attacks), eavesdropping, Man in the Middle (MITM) Attacks through forged OLT and ONU spoofing. An excellent presentation summary highlighting the issues by Stanford University researchers can be found here: <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.5969&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.5969&rep=rep1&type=pdf</a></div><div style="font-size: 14px; font-family: Calibri, sans-serif; "><br></div><div style="font-size: 14px; font-family: Calibri, sans-serif; ">In fact this matter and the Stanford University Research was highlighted in DBCDE's Implementation Study (page 206) <a href="http://data.dbcde.gov.au/nbn/NBN-Implementation-Study-complete-report.pdf">http://data.dbcde.gov.au/nbn/NBN-Implementation-Study-complete-report.pdf</a></div><div><br></div><div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><i>"A 2007 Stanford University study outlines three potential security concerns: denial of service attacks; <span class="highlight selected">eavesdr</span>opping; and masquerading of an ONU (e.g. continuously transmitting upstream to block transmission of information from other ONTs). <b>However, GPON vendors down play the significance of these risks</b>. </i><i>As GPON deployments become more widespread, standards and technology to ensure the security of these networks are likely to emerge." </i></div></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><i><br></i></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224">GPON is not as secure as people may think through unencrypted upstreams and I think even clear passwords, so my guess is that an NBN Co. Also one faulty ONU could take down the 31 other customers on the span. ONU management is one way to try to manage this issue and without understanding their actual config, I'm guessing there is strong auth between the ONU and OLT. Also there might be some DoS protection built in these days. Again, it won't solve some of the security issues for those with intent to intercept/interfere but I'm sure it will help.</div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><br></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224">I think there is inherent risk, particularly in the early stages of deployment of trying to maintain a certain level of visibility/managability and consistency to end user deployments by letting providers connect whatever ONU they choose. If the FttP deployment was EP2P then that would be a different story! Anyway food for thought.</div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><br></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224">Cheers</div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><br></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224">[b]</div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224"><br></div><div dir="ltr" style="left: 347.6px; top: 375.36px; " data-font-name="g_font_p0_2" data-canvas-width="362.224">PS: Disclaimer that I could be a little outdated in GPON security, but this was the lay of the land as I understood it 3-4 years ago.</div></body></html>