Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

zhang.fei3@zte.com.cn Thu, 08 September 2011 01:47 UTC

Return-Path: <zhang.fei3@zte.com.cn>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1989621F8C36; Wed, 7 Sep 2011 18:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.977
X-Spam-Level:
X-Spam-Status: No, score=-95.977 tagged_above=-999 required=5 tests=[AWL=-1.542, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWc-UNNoG3H2; Wed, 7 Sep 2011 18:47:21 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2821F8C2F; Wed, 7 Sep 2011 18:47:19 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 482473491178658; Thu, 8 Sep 2011 09:44:20 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 74991.4404404214; Thu, 8 Sep 2011 09:49:03 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p881mthQ053885; Thu, 8 Sep 2011 09:48:55 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <27A28CFD-BB21-455F-B7A6-60C82B0D60E4@lucidvision.com>
To: Thomas Nadeau <tnadeau@lucidvision.com>
MIME-Version: 1.0
X-KeepSent: C9103DCC:7EB00D66-48257905:00064F9C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFC9103DCC.7EB00D66-ON48257905.00064F9C-48257905.0009F74F@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Thu, 08 Sep 2011 09:48:50 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-08 09:48:56, Serialize complete at 2011-09-08 09:48:56
Content-Type: multipart/alternative; boundary="=_alternative 0009F74C48257905_="
X-MAIL: mse02.zte.com.cn p881mthQ053885
Cc: pwe3-bounces@ietf.org, pwe3@ietf.org
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2011 01:47:22 -0000

Tom

Thanks for your response

See in line with <Fei>, hope you like my interpretation.

B.R.

Fei



Thomas Nadeau <tnadeau@lucidvision.com> 
2011-09-07 19:45

收件人
zhang.fei3@zte.com.cn
抄送
pwe3@ietf.org, pwe3-bounces@ietf.org
主题
Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06







On Sep 7, 2011, at 4:30 AM, zhang.fei3@zte.com.cn wrote:


Hi Tom 

According to my understanding, I think you are concerning about two points 


(1) Synchronization between different configuration points,as you said 
"Both accessors in the example I gave have permission to change the 
configuration (authenticated). The issue is again, that you can overwrite 
the other one's configuration without their knowing." 

Just my two cents, This would not happen for MS-PW because that the 
setting up and OAM configuration of PWs are intialized by only one T-PE 
node, the other nodes just receive the control plane signaling and react 
to the events. As to SS-PW, this is a issue, but the different 
configuration parameters can be negotiated by the subsequent signaling 
messages, as described in the section 6.2 

I've already given several very plausible examples of how this could 
happen, but let me do so again for the sake of explaining my point. For 
example, if an operator in your example, has an OSS that provisions 
services in its network, it will have "write" configuration access to the 
T-PE node you give above.  Lets say that the OSS has provisioned a TP 
tunnel X on that box and provisioned 2 MEPs and 1 MIP along its path. If 
some time later I then SSH to that same T-PE box in question and access 
the CLI from there, and decide I don't like only 1 MIP and add one, I have 
changed the network's configuration state and just suddenly made it out of 
sync with the OSS/provisioning system. 

<Fei> This document is aimed to configure proactive OAM functions, which 
are end-to-end. As the example you provided, the adding or deleting MIP 
functions on the midpoints are related to the configuration of on-demand 
OAM functions, which are expected by NMS and are not inlcluded in the 
draft. 

(2)The security of the mechanisms, as you said "Consider the case of a 
cable MSO with different operational domains, where one operator isn't 
authorized to make configuration changes in the other domain" 

I think every accessors have been authorized, otherwise the control plane 
signaling will not be sent. Furthermore, there is one WG draft in MPLS 
about the security, see 
http://tools.ietf.org/html/draft-ietf-mpls-tp-security-framework-01, and 
attacks on the control plane is discussed on the secion 4.1. 

That is my point. This mechanism only assumes that 
authentication/authorization has been granted at the node in question not 
anywhere else along the TP path. Thus, I could be granted access at the 
head of the TP path which might be in another domain, yet make substantive 
configuration changes further along the path.  Worse, I could modify the 
running configuration of nodes downstream without their OSS knowing of 
these changes - or allowing me to make those changes. This is very much 
against the requirement originally put forth for MPLS-TP to operate 
without a control plane for security reasons.  If we allowed this, we 
violate that tenant and might as well just go back to plain old MPLS PWs 
over TE tunnels, right?

<Fei> Firstly, the MPLS-TP's requirements do not preclude the usage of 
control plane, and the OAM configurations MUST be supported by control 
plane are listed in section 2.4 in RFC5654, which are described in detail 
in section 2.3 of the draft aft-ietf-ccamp-mpls-tp-cp-framework-06.txt. 
Secondly, I just follow your argument to prove that every accessors have 
been authorized, actually every nodes along the path can be granted to be 
authorized based on the
security mechanims of signaling protocol.


--Tom




Best regards 

Fei 


Thomas Nadeau <tnadeau@lucidvision.com> 
发件人:  pwe3-bounces@ietf.org
2011-09-07 00:17 


收件人
"Andrew G. Malis" <agmalis@gmail.com> 
抄送
pwe3@ietf.org 
主题
Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06









                As I mentioned during the meeting, I think this it is a 
bad idea to allow configuration via the OAM control channel, so I do not 
want this adopted as a WG draft.

                --Tom

On Sep 6, 2011, at 10:58 AM, Andrew G. Malis wrote:

> This email begins a two-week poll on the PWE3 working group adoption
> of draft-zhang-mpls-tp-pw-oam-config-06, to end on Sept. 20.
> 
> You can read the draft at
> https://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-06 .
> 
> The MPLS working group was bcc:ed for their information.
> 
> Please respond with any comments to pwe3@ietf.org ONLY.
> 
> Thanks,
> Andy
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3