Re: [secdir] secdir review of draft-ietf-pals-mc-pon-04

Jiangyuanlong <jiangyuanlong@huawei.com> Mon, 05 September 2016 07:04 UTC

Return-Path: <jiangyuanlong@huawei.com>
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 71A2112B09E; Mon, 5 Sep 2016 00:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level:
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 MwVWQyKvIF3f; Mon, 5 Sep 2016 00:04:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99943128E18; Mon, 5 Sep 2016 00:04:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQT11143; Mon, 05 Sep 2016 07:04:29 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Sep 2016 08:03:52 +0100
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.50]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Mon, 5 Sep 2016 15:03:42 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: "Steve.Hanna@infineon.com" <Steve.Hanna@infineon.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-pals-mc-pon@ietf.org" <draft-ietf-pals-mc-pon@ietf.org>
Thread-Topic: secdir review of draft-ietf-pals-mc-pon-04
Thread-Index: AdIERGNJ4u3omnmWQ2+8lMLF4/56GQAE89FQALQA5lA=
Date: Mon, 05 Sep 2016 07:03:41 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86@szxema506-mbs.china.huawei.com>
References: <71cbf9b3372247f297987d0bb1acdd67@MUCSE609.infineon.com>
In-Reply-To: <71cbf9b3372247f297987d0bb1acdd67@MUCSE609.infineon.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.203.119]
Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B91732D86szxema506mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57CD18FE.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.50, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 181776cf2ccb1e8546a00f9b9a6fc472
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/iZYDb0KaJx2BxsL0iwBJAG3yRuk>
Subject: Re: [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 <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Sep 2016 07:04:37 -0000

Hi Steve,

Thank a lot for your review.
Please see my replies with [JY].

Kind regards,
Yuanlong


From: Steve.Hanna@infineon.com [mailto:Steve.Hanna@infineon.com]
Sent: Thursday, September 01, 2016 9:55 PM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-pals-mc-pon@ietf.org
Subject: RE: secdir review of draft-ietf-pals-mc-pon-04

Resending with correct draft alias.

Steve

From: Hanna Steve (IFAM CCS SMD AMR)
Sent: Thursday, September 01, 2016 7:57 AM
To: 'iesg@ietf.org'; 'secdir@ietf.org'; 'draft-ietf-pals-mc-pon-04.all@ietf.org'
Subject: secdir review of draft-ietf-pals-mc-pon-04


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.

[JY] ONT (Optical Network Terminal) is a similar term of ONU (Optical Network Unit), both of them are used widely and almost interchangeably in the PON network.

But I agree with you that we don’t need to introduce a new term in the “Security considerations” and we will use ONU consistently in the next revision.



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.

[JY] The assumption that “the working OLT will presumably send this ICCP message to the protection PW over the PON” does not parse, do you mean “the working OLT will presumably send this ICCP message to the protection OLT over the PON”? But this case will never happen if the protection mechanism works as described in this document, since the Protection trunk link will not be activated until the PON switching protection is finished (that is, after the Working trunk link is off and an ICCP message is received).  Maybe the confusion is caused by a lack of interconnection between the OLTs in Figure 1. But this document assumes that there is an ICCP interconnect between the OLTs. Please also be aware that Section 3.2 “ICCP Interconnect Scenarios” of RFC 7275 discusses the details of how to interconnect the PEs (i.e., the OLTs) in a redundancy group, thus all these ICCP interconnect scenarios are applicable to draft-ietf-pals-mc-pon-04 too.

Furthermore, the ONUs are out of the MPLS network domain where OLTs reside, LDP protocol (ICCP is one sub-type) session will not be established between any ONU and any OLT, therefore, ICCP attack from the PON side is not regarded as an issue.


Two minor typos:


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



[JY] Good catch. We will update it.


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

[JY] Agreed.


Thanks for your consideration,

Steve