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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 15 September 2016 11:39 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8D212B282; Thu, 15 Sep 2016 04:39:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Level:
X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 qRV5AjWALD9r; Thu, 15 Sep 2016 04:39:37 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ADE212B28D; Thu, 15 Sep 2016 04:39:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6454CBE55; Thu, 15 Sep 2016 12:39:35 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1C5OYBXyeZ8P; Thu, 15 Sep 2016 12:39:35 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BECBEBE53; Thu, 15 Sep 2016 12:39:34 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1473939575; bh=f5+oi2xxpbiXVkeBI3HXJtD5ytWDAfja4EW26R28US8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=G+YQ3UFGSL07fEWhsLUGH17AfEhwzw5uQMdY6NlQJzYCs0lExAOPH0QubE6fPwDXH AuTHvrH7m3s1pbLqXRS9YZmFCSE7JFwhS+gwQ3gPxububfrtEH7tFtAP/Z2ZMMVYIs 5bZ9gj47W4Ny3fuDjWQSXs6pyjhrFxpjsWBt2grs=
To: Jiangyuanlong <jiangyuanlong@huawei.com>, The IESG <iesg@ietf.org>
References: <147381075416.13170.14909169380037916813.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B9175EEE0@szxema506-mbs.china.huawei.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <69703e52-57c6-26b4-7517-6a968ba14620@cs.tcd.ie>
Date: Thu, 15 Sep 2016 12:39:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B9175EEE0@szxema506-mbs.china.huawei.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040106020504030505090709"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/a2xTb0fJFumr6-7VfEu0osJ4u30>
Cc: "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "agmalis@gmail.com" <agmalis@gmail.com>, "draft-ietf-pals-mc-pon@ietf.org" <draft-ietf-pals-mc-pon@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] Stephen Farrell's Discuss on draft-ietf-pals-mc-pon-04: (with DISCUSS)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2016 11:39:40 -0000


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.
> 
> Are you satisfied with this resolution? Do you have any suggestions?
> 
> Thanks, Yuanlong
> 
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, September 14,
> 2016 7:53 AM To: The IESG Cc: draft-ietf-pals-mc-pon@ietf.org; Andrew
> G. Malis; pals-chairs@ietf.org; agmalis@gmail.com; pals@ietf.org 
> 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
> 
> 
> 
>