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

On Sep 7, 2011, at 9:48 PM, zhang.fei3@zte.com.cn wrote:

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

	This is a slippery slope you have us going down. As I mentioned, if the mechanism you have defined here is not deployed in concert with the operator's provisioning system, you effectively have TWO configuration mechanisms, and TWO different ways to change the state of the devices along the TP tunnel path.  Besides being a configuration management nightmare in the making, you have also neglected the security aspects of this approach.  

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

	You have just explained my point: this document is used for managing a subset of the device's configuration.

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

	They do not preclude the usage of control plane operations for sure, but should operate in the absence of any control plane too.  I am asserting that what you are doing here is effectively circumventing a control plane when one is in use, with a "mini" control plane. The other problem with this approach is that you are mixing configuration with proactive OAM operations/control/activation.   Simply put, this is a bad idea.

	--Tom


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