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

[Jiangyuanlong <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, September 27, 2016 7:26 PM
To: Jiangyuanlong; Edwin Mallette; 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)


Hiya,


On 18/09/16 09:28, Jiangyuanlong wrote:
> Hi Ed and Stephen,
> 

Sorry for the slow response.

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

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.

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