Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0312D924; Thu, 1 Sep 2016 04:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.468 X-Spam-Level: X-Spam-Status: No, score=-7.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrofdj92XbrU; Thu, 1 Sep 2016 04:57:09 -0700 (PDT) Received: from smtp2.infineon.com (smtp2.infineon.com [217.10.52.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F69812D911; Thu, 1 Sep 2016 04:57:07 -0700 (PDT) X-SBRS: None Received: from unknown (HELO mucxv003.muc.infineon.com) ([172.23.11.20]) by smtp2.infineon.com with ESMTP/TLS/AES256-SHA; 01 Sep 2016 13:57:05 +0200 Received: from MUCSE607.infineon.com (unknown [172.23.7.108]) by mucxv003.muc.infineon.com (Postfix) with ESMTPS; Thu, 1 Sep 2016 13:57:05 +0200 (CEST) Received: from MUCSE613.infineon.com (172.23.7.84) by MUCSE607.infineon.com (172.23.7.108) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 13:57:05 +0200 Received: from MUCSE609.infineon.com (172.23.7.110) by MUCSE613.infineon.com (172.23.7.84) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Sep 2016 13:57:04 +0200 Received: from MUCSE609.infineon.com ([172.23.103.71]) by MUCSE609.infineon.com ([172.23.103.71]) with mapi id 15.00.1178.000; Thu, 1 Sep 2016 13:57:04 +0200 From: To: , , Thread-Topic: secdir review of draft-ietf-pals-mc-pon-04 Thread-Index: AdIERGNJ4u3omnmWQ2+8lMLF4/56GQ== Date: Thu, 1 Sep 2016 11:57:04 +0000 Message-ID: <9ca53ebc0523442d9be8ab8a1bc3b45e@MUCSE609.infineon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.23.8.247] Content-Type: multipart/alternative; boundary="_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-ietf-pals-mc-pon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 11:57:11 -0000 --_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Summary: Ready with issues The security considerations section of this document seems reasonable and c= orrect. However, I'm concerned that bringing ICCP into the PON has some sec= urity risks that have not been properly called out and mitigated. As the Se= curity 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 w= orking 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." Si= nce the working PW has failed, the working OLT will presumably send this IC= CP message to the protection PW over the PON. That means that any other aut= horized 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 RF= C 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 a= uthentication susceptible to easy forgery. Using MD5 (as permitted by RFC 7= 275) 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 for= ce failure. Of course, an attacker on the PON could also just jam the PON b= y 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 --_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  These comments were written primarily for the benefi= t 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 docum= ent seems reasonable and correct. However, I’m concerned that bringin= g ICCP into the PON has some security risks that have not been properly cal= led out and mitigated. As the Security Considerations section says:

 

   In many passive optical networks the= optical paths between

   OLT and ONTs traverse publicly acces= sible facilities including

   public attachments (e.g. telephone p= oles)

 

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

 

My concern is that section 4.2 says that “W= hen a fault is detected on its working PW (e.g., by VCCV BFD), a working OL= T SHOULD turn off its associated PON interface and then send an ICCP messag= e with PON State TLV with local PON Port State being set to notify the protection OLT of the PON fault.” Sinc= e 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 autho= rized 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 mess= ages 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 easil= y forge ICCP messages on the PON is not clear to me but it seems that the a= ttacker could at least prevent proper failover and maybe force failover or even force failure. Of course, an att= acker 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” s= hould be “ONU”. At least, I assume so. If not, ONT should be de= fined.

 

Thanks for your consideration,

 

Steve

 

--_000_9ca53ebc0523442d9be8ab8a1bc3b45eMUCSE609infineoncom_--