Subject: [Pals] Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 13 Sep 2016 16:52:34 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-pals-mc-pon-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pals-mc-pon/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Is this extension to ICCP really compatible with section
10 of RFC7275?  RFC7275 says "It ought not be deployed on
or over the public Internet.  ICCP is not intended to be
applicable when the Redundancy Group spans PEs in
different administrative domains" whereas this draft only
refers to the "well-managed" stuff and says nothing about
multiple domains, and this draft also refers to public
contexts such as telephone poles. Can you justify for me
how using ICCP here is safe? (It may well be, but I'm
entirely unsure, probably mostly due to my ignorance of
PON deployments.)

The same point was made in the secdir review [1] which
did get a response. Sadly, I didn't get how the response
answered the question. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06762.html

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 14 Sep 2016 02:39:39 +0000

Hi Stephen,

To be clear, it is proposed to add "in a single administrative domain" to the end of "this ICCP application SHOULD only be used in
   well-managed and highly monitored service provider PON access networks..." 
Thus we have the following texts "this ICCP application SHOULD only be used in
   well-managed and highly monitored service provider PON access networks in a single administrative domain".

Typically, the PON network and the MPLS network interconnection as described in the document (for scenarios including FTTx, MSO and mobile backhaul) are under the control of a single service provider. So the proposed change does not inflict any real constraint.

ICCP is a sub-type of LDP protocol (RFC5036), the same security measures of LDP are applicable too, that is, ICCP peer PEs (LDP peers) are in the same MPLS administration domain, access list and authentication mechanisms can be used between the PEs (e.g., all LDP packets are denied by the OLT if they are received from the interfaces connecting the ONUs). As this document is based on ICCP (i.e., LDP), we can use all these mechanisms described in RFC5036 and RFC7275.

Are you satisfied with this resolution? Do you have any suggestions?

Thanks,
Yuanlong

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2016 7:53 AM
To: The IESG
Cc: [email-masked]; Andrew G. Malis; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Is this extension to ICCP really compatible with section
10 of RFC7275?  RFC7275 says "It ought not be deployed on or over the public Internet.  ICCP is not intended to be applicable when the Redundancy Group spans PEs in different administrative domains" whereas this draft only refers to the "well-managed" stuff and says nothing about multiple domains, and this draft also refers to public contexts such as telephone poles. Can you justify for me how using ICCP here is safe? (It may well be, but I'm entirely unsure, probably mostly due to my ignorance of PON deployments.)

The same point was made in the secdir review [1] which did get a response. Sadly, I didn't get how the response answered the question.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Sep 2016 12:39:34 +0100

On 14/09/16 03:39, Jiangyuanlong wrote:
> Hi Stephen,
> 
> To be clear, it is proposed to add "in a single administrative
> domain" to the end of "this ICCP application SHOULD only be used in 
> well-managed and highly monitored service provider PON access
> networks..." Thus we have the following texts "this ICCP application
> SHOULD only be used in well-managed and highly monitored service
> provider PON access networks in a single administrative domain".

That's more consistent yes.

> 
> Typically, the PON network and the MPLS network interconnection as
> described in the document (for scenarios including FTTx, MSO and
> mobile backhaul) are under the control of a single service provider.
> So the proposed change does not inflict any real constraint.

Sorry but I'm still not seeing how "under the control of" and
"telephone poles" make for it being reasonable to depend on the
fairly modest security mechanisms that are available, and IIUC,
that are not often used (in less threatened environments). Can
you clarify that for me?

Thanks,
S.

> 
> ICCP is a sub-type of LDP protocol (RFC5036), the same security
> measures of LDP are applicable too, that is, ICCP peer PEs (LDP
> peers) are in the same MPLS administration domain, access list and
> authentication mechanisms can be used between the PEs (e.g., all LDP
> packets are denied by the OLT if they are received from the
> interfaces connecting the ONUs). As this document is based on ICCP
> (i.e., LDP), we can use all these mechanisms described in RFC5036 and
> RFC7275.
> 
> Thanks, Yuanlong
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Wednesday, September 14,
> 2016 7:53 AM To: The IESG Cc: [email-masked]; Andrew
> G. Malis; [email-masked]; [email-masked]; [email-masked] 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
> information about IESG DISCUSS and COMMENT positions.
> 
> 
DISCUSS:
> Is this extension to ICCP really compatible with section 10 of
> RFC7275?  RFC7275 says "It ought not be deployed on or over the
> public Internet.  ICCP is not intended to be applicable when the
> Redundancy Group spans PEs in different administrative domains"
> whereas this draft only refers to the "well-managed" stuff and says
> nothing about multiple domains, and this draft also refers to public
> contexts such as telephone poles. Can you justify for me how using
> ICCP here is safe? (It may well be, but I'm entirely unsure, probably
> mostly due to my ignorance of PON deployments.)
> 
> The same point was made in the secdir review [1] which did get a
> response. Sadly, I didn't get how the response answered the question.
> 
> 
> [1]
> https://www.ietf.org/mail-archive/web/secdir/current/msg06762.html
> 
> 
> 
>

---

From: Edwin Mallette <[email-masked]>
Date: Thu, 15 Sep 2016 09:04:56 -0600

Hi Stephen,

I suppose what might not be clear, at least in the security section, is
that ICCP for MC-PON does not operate between the OLT and ONU/ONT.
Without going into too much detail in terms of how security mechanisms
work on PON access networks, I¹ve attempted to propose some additional
text in the second paragraph of the security section to attempt to clarify
that the risk isn¹t to ICCP via a direct ICCP protocol interaction.  There
is some risk to ICCP that can be caused by mucking around with the ONU or
the physical fiber path between the OLT and ONU.  Does this help address
your concern ?

Original Text:

Again, similar to ICCP, activity on the attachment circuits may cause
security threats or be exploited to create denial-of-service attacks. In
many passive optical networks the optical paths between OLT and ONTs
traverse publicly accessible facilities including public attachments (e.g.
telephone poles), which opens up the risk of excessive link bouncing by
optical layer impairment. Other risks include a malicious ONT, which can
lead to excessive ICCP exchanges similar to the malicious CE case
described in [RFC7275]. Operators of such networks should take additional
care to restrict unauthorized ONTs and to limit the impact of link
bouncing, as these could result in service impairment.

Proposed Text:

Again, similar to ICCP, activity on the attachment circuits may cause
security threats or be exploited to create denial-of-service attacks. In
many passive optical networks the optical paths between OLT and ONUs
traverse publicly accessible facilities including public attachments (e.g.
telephone poles), which opens up the risk of excessive link bouncing by
optical layer impairment.  While ICCP for MC-PON does not operate between
the OLT and ONU, risks do include introduction of a malicious ONU which
could cause, for example, excessive link bouncing.  This link bouncing
could result in increased ICCP exchanges similar to the malicious CE case
described in [RFC7275 <https://tools.ietf.org/html/rfc7275>]. Operators of
such networks should take additional care to restrict unauthorized ONUs
and to limit the impact of link bouncing at the OLT, as these could result
in service impairment.

Cheers!

Ed

---

From: Jiangyuanlong <[email-masked]>
Date: Sun, 18 Sep 2016 08:28:17 +0000

Hi Ed and Stephen,

A further improvement over the Proposed Text:

Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. In many passive optical networks the optical paths between OLT and ONUs traverse publicly accessible facilities including public attachments (e.g. telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment.  While ICCP for MC-PON interconnects in the MPLS domain and does not traverse the PON network, risks do include introduction of a malicious ONU which could cause, for example, excessive link bouncing.  This link bouncing could result in increased ICCP exchanges similar to the malicious CE case described in [RFC7275 <https://tools.ietf.org/html/rfc7275>]. Operators of such networks should take additional care to restrict unauthorized ONUs and to limit the impact of link bouncing at the OLT, as these could result in service impairment.

Are you OK with this proposal?

Thanks,

Yuanlong

-----Original Message-----
From: Edwin Mallette [mailto:[email-masked]]
Sent: Thursday, September 15, 2016 11:05 PM
To: Stephen Farrell; Jiangyuanlong; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

On 9/15/16, 5:39 AM, "Stephen Farrell" <[email-masked]<mailto:[email-masked]>> wrote:

>"telephone poles" make for it being reasonable to depend on the fairly

>modest security mechanisms that are available, and IIUC, that are not

>often used (in less threatened environments). Can you clarify that for

>me?

Hi Stephen,

I suppose what might not be clear, at least in the security section, is that ICCP for MC-PON does not operate between the OLT and ONU/ONT.

Without going into too much detail in terms of how security mechanisms work on PON access networks, I¹ve attempted to propose some additional text in the second paragraph of the security section to attempt to clarify that the risk isn¹t to ICCP via a direct ICCP protocol interaction.  There is some risk to ICCP that can be caused by mucking around with the ONU or the physical fiber path between the OLT and ONU.  Does this help address your concern ?

Original Text:

Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. In many passive optical networks the optical paths between OLT and ONTs traverse publicly accessible facilities including public attachments (e.g.

telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment. Other risks include a malicious ONT, which can lead to excessive ICCP exchanges similar to the malicious CE case described in [RFC7275]. Operators of such networks should take additional care to restrict unauthorized ONTs and to limit the impact of link bouncing, as these could result in service impairment.

Proposed Text:

Again, similar to ICCP, activity on the attachment circuits may cause security threats or be exploited to create denial-of-service attacks. In many passive optical networks the optical paths between OLT and ONUs traverse publicly accessible facilities including public attachments (e.g.

telephone poles), which opens up the risk of excessive link bouncing by optical layer impairment.  While ICCP for MC-PON does not operate between the OLT and ONU, risks do include introduction of a malicious ONU which could cause, for example, excessive link bouncing.  This link bouncing could result in increased ICCP exchanges similar to the malicious CE case described in [RFC7275 <https://tools.ietf.org/html/rfc7275>]. Operators of such networks should take additional care to restrict unauthorized ONUs and to limit the impact of link bouncing at the OLT, as these could result in service impairment.

Cheers!

Ed

>> 2016 7:53 AM To: The IESG Cc: [email-masked]<mailto:[email-masked]>; Andrew

>> G. Malis; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

>> Subject: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04:

>> (with DISCUSS)

>> ---------------------------------------------------------------------

>> -

>> ---------------------------------------------------------------------

>> -

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Sep 2016 12:25:31 +0100

Hiya,

> Hi Ed and Stephen,

Sorry for the slow response.

> security threats or be exploited to create denial-of-service attacks.
> In many passive optical networks the optical paths between OLT and
> ONUs traverse publicly accessible facilities including public
> attachments (e.g. telephone poles), which opens up the risk of
> excessive link bouncing by optical layer impairment.  While ICCP for
> MC-PON interconnects in the MPLS domain and does not traverse the PON
> network, risks do include introduction of a malicious ONU which could
> cause, for example, excessive link bouncing.  This link bouncing
> could result in increased ICCP exchanges similar to the malicious CE
> case described in [RFC7275 <https://tools.ietf.org/html/rfc7275>].
> Operators of such networks should take additional care to restrict
> unauthorized ONUs and to limit the impact of link bouncing at the
> OLT, as these could result in service impairment.

So I guess limitation to single domains the assertion that this
ICCP is not used on the publicly accessible links (telephone poles
etc.) is good enough for me to clear. (Will do that in a bit.)

On the text above - is "link bouncing" really the worst thing
that can happen if someone introduces a malicious ONU? That
would be surprising. So I'd suggest maybe using another example
threat in this bit:

"While ICCP for
MC-PON interconnects in the MPLS domain and does not traverse the PON
network, risks do include introduction of a malicious ONU which could
cause, for example,..."

E.g. couldn't a fake ONU inject/monitor traffic?

Cheers,
S.

> -----Original Message----- From: Edwin Mallette
> [mailto:[email-masked]] Sent: Thursday, September 15, 2016
> 11:05 PM To: Stephen Farrell; Jiangyuanlong; The IESG Cc:
> [email-masked]; [email-masked];
> [email-masked]; [email-masked] Subject: Re: Stephen
> Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)
> 
> 
> 
> 
> 
> 
> 
> On 9/15/16, 5:39 AM, "Stephen Farrell"
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> 
> 
>> 
> 
>> 
> 
>> fairly
> I suppose what might not be clear, at least in the security section,
> is that ICCP for MC-PON does not operate between the OLT and
> ONU/ONT.
> 
> Without going into too much detail in terms of how security
> mechanisms work on PON access networks, I¹ve attempted to propose
> some additional text in the second paragraph of the security section
> to attempt to clarify that the risk isn¹t to ICCP via a direct ICCP
> protocol interaction.  There is some risk to ICCP that can be caused
> by mucking around with the ONU or the physical fiber path between the
> OLT and ONU.  Does this help address your concern ?
> 
> 
> 
> Original Text:
> 
> 
> 
> security threats or be exploited to create denial-of-service attacks.
> In many passive optical networks the optical paths between OLT and
> ONTs traverse publicly accessible facilities including public
> attachments (e.g.
> 
> telephone poles), which opens up the risk of excessive link bouncing
> by optical layer impairment. Other risks include a malicious ONT,
> which can lead to excessive ICCP exchanges similar to the malicious
> CE case described in [RFC7275]. Operators of such networks should
> take additional care to restrict unauthorized ONTs and to limit the
> impact of link bouncing, as these could result in service
> impairment.
> 
> 
> 
> 
> 
> Proposed Text:
> 
> 
> 
> security threats or be exploited to create denial-of-service attacks.
> In many passive optical networks the optical paths between OLT and
> ONUs traverse publicly accessible facilities including public
> attachments (e.g.
> 
> telephone poles), which opens up the risk of excessive link bouncing
> by optical layer impairment.  While ICCP for MC-PON does not operate
> between the OLT and ONU, risks do include introduction of a malicious
> ONU which could cause, for example, excessive link bouncing.  This
> link bouncing could result in increased ICCP exchanges similar to the
> malicious CE case described in [RFC7275
> <https://tools.ietf.org/html/rfc7275>]. Operators of such networks
> should take additional care to restrict unauthorized ONUs and to
> limit the impact of link bouncing at the OLT, as these could result
> in service impairment.
> 
> 
> 
> Cheers!
> 
> 
> 
> Ed
> 
> 
> 
>> 
> 
>>> 
> 
>>> 2016 7:53 AM To: The IESG Cc:
>>> [email-masked]<mailto:[email-masked]>;
>>> Andrew
> 
>>> G. Malis; [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]>;
>>> [email-masked]<mailto:[email-masked]>
>

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 28 Sep 2016 02:12:54 +0000

Stephen,

My interpretation is, the security issue of a fake ONU is already considered in RFC 6457 (Multi-Segment Pseudowires in Passive Optical Networks) and other PON standards (such as G.984.3/G.987.3). Whether ICCP (or PON protection) is used or not, fake ONUs will pose the same security challenge. Thus, there is no extra security issue introduced in this sense.

In the real deployment of FTTx (PON) networks, all the ONUs are typically resold by the service providers; they are also configured and controlled by the service providers. Thus, PON access network can be as safe as a well-secured MPLS network.

Thanks,
Yuanlong

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Tuesday, September 27, 2016 7:26 PM
To: Jiangyuanlong; Edwin Mallette; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)

Hiya,

"While ICCP for

Cheers,
S.