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

[Edwin Mallette <[e-mail]>]

On 9/15/16, 5:39 AM, "Stephen Farrell" <[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]; Andrew
>> G. Malis; [e-mail]; [e-mail]; [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
>> 
>> 
>> 
>> 
>