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

[Jiangyuanlong <[e-mail]>]

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:[e-mail]]
Sent: Thursday, September 15, 2016 11:05 PM
To: Stephen Farrell; Jiangyuanlong; The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)







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



>

>

>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.

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



>

>>

>> 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:[e-mail]] Sent: Wednesday, September 14,

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

>> G. Malis; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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

>> (with DISCUSS)

>>

>> 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

>>

>>

>>

>>

>