Last Call Review of draft-ietf-pals-mc-pon-04
review-ietf-pals-mc-pon-04-secdir-lc-hanna-2016-09-08-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



Summary: Ready with issues



The security considerations section of this document seems reasonable and
correct. However, I’m concerned that bringing ICCP into the PON has some
security risks that have not been properly called out and mitigated. As the
Security Considerations
 section says:



   In many passive optical networks the optical paths between

   OLT and ONTs traverse publicly accessible facilities including

   public attachments (e.g. telephone poles)



Note that I’m pretty sure that ONT should be ONU here and in several other
places in the Security Considerations.



My concern is that section 4.2 says that “When a fault is detected on its
working PW (e.g., by VCCV BFD), a working OLT SHOULD turn off its associated
PON interface and then send an ICCP message with PON State TLV with local PON
Port
 State being set to notify the protection OLT of the PON fault.” Since the
 working PW has failed, the working OLT will presumably send this ICCP message
 to the protection PW over the PON. That means that any other authorized or
 unauthorized party on the PON could also send such a message. I’m not very
 familiar with ICCP but the Security Considerations section of RFC 7275 seems
 to say that ICCP messages are frequently authenticated only by looking at the
 source IP address, which is an exceedingly weak method of authentication
 susceptible to easy forgery. Using MD5 (as permitted by RFC 7275) isn’t much
 better. The impact of permitting attackers to easily forge ICCP messages on
 the PON is not clear to me but it seems that the attacker could at least
 prevent proper failover and maybe force failover or even force failure. Of
 course, an attacker on the PON could also just jam the PON by setting their
 laser always on but ICCP attacks would be much trickier to detect. I would
 suggest that TCP-AO be required at least for ICCP messages sent or received on
 the PON.



Two minor typos:



1)



In section 3, “protect OLTs” should be “protection OLTs”.



2)



In the Security Considerations, “ONT” should be “ONU”. At least, I assume so.
If not, ONT should be defined.



Thanks for your consideration,



Steve