RE: Control Plane Security of ISP Network

["Barry Greene \(bgreene\)" <bgreene@cisco.com>]

Where do you get the idea of a BGP in a VPN is "control plane
separation?" It is not separation. All it does is make it easier to
manage infrastructure ACLs to protect against a direct port attack on
BGP (which is just one of many feasible attack vectors on BGP). So this
specific technique is a long way from a "best practice" and does not
achieve "planes of separation."

Also, OOB Management is a must, but it does not "it impossible for
attack on data plane to launch an attack to management interfaces or
systems." OOB Management networks to are designed to provide management
out side of the data plane (especially when the data plane is down). It
is not designed for security and most production management (i.e. SNMP
polling, flow export, etc.) is all done via data plane (bandwidth is
cheaper). 

I'm thoroughly familiar with the operational concern with that control
plane getting whacked, but waving the "separation" banner with out
understanding the consequences is not productive. Complete control plane
separation in IP requires major enhancement to ISIS and OSPF. We
exported that during IEPG in March 2003 and had it rejected (done on
behalf of SPs - see http://www.potaroo.net/iepg/march-2003/  which was a
session to talk the audience down a path of logic that would conclude
that complete separation was the 'next step'.)

Today, our IP control plane is in-band. There are sound reasons why we -
the IETF community - built the control plane in that why - reasons which
go all the way back to Paul Buran's original work. Beware throwing
around "control plane separation" which out understanding the
consequences to of that work. 

> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On 
> Behalf Of Miao Fuyou
> Sent: Monday, June 06, 2005 2:43 AM
> To: 'Merike Kaeo'
> Cc: opsec@ops.ietf.org; eludom@gmail.com
> Subject: RE: Control Plane Security of ISP Network
> 
> 
> Hi Merike:
> 
> In the past1.5 years I was involved in development of 
> standard of router security requirement. During the 
> development there are a lot of discussions on security of 
> control plane. Quite a few professionals from SPs gave much 
> concerns and ideas on planes seperation, which is to seperate 
> control and/or manage plane from end user/data plane 
> physically or logically. Actually OOB management is one such 
> solution with physical/logical seperation mechanism to 
> seperate management traffic from end user data, which makes 
> it impossible for attack on data plane to launch an attack to 
> management interfaces or systems. As for control plane, while 
> some SPs are practicing plane seperation by VPN or other 
> technology, it is much more sophisticated than management 
> plane. I think planes seperation should be considered in 
> Practices draft, specifically section 2.5.7. 
> 
> Route authentication, which is identified in Practices draft 
> section 2.5.7, is extremely important security aspect of  
> control plane in spite of criticism for MD5 weaks and 
> cumbersome configuration. Sometimes Filtering helps control 
> plane security,  but it is not complete. So a new Capability 
> draft is required to describing security capabilty of route 
> authentication and control plane seperation. I will trying to 
> write a very initial draft before IETF 63 meeting to give 
> primary idea.
> 
> Wish the same also answers questions of Mr. George Jones in 
> another mail.
> Thanks!
> 
> Miao Fuyou
> 
> -----Original Message-----
> From: Merike Kaeo [mailto:merike@doubleshotsecurity.com]
> Sent: Friday, June 03, 2005 1:08 PM
> To: Miao Fuyou
> Cc: opsec@ops.ietf.org
> Subject: Re: Control Plane Security of ISP Network
> 
> 
> Hello Miao.
> 
> Yes,  more text needed to be added to address current control plane 
> security
> practices and in the next version of the document you will see this 
> addition.
> 
> As to having another capabilities document, that depends on how much 
> overlap
> there is with filtering.  Were you proposing to author such a 
> document?
> 
> - merike
> 
> On Jun 2, 2005, at 7:49 PM, Miao Fuyou wrote:
> 
> >
> > Hi, All:
> >
> > In the Pratices document(draft-ietf-opsec-current-practices-00.txt)
> > routing
> > control plane security is explicitly identified as an 
> important aspect 
> > of
> > network security. Sp network is comprised of the most 
> essential assets 
> > and
> > facilities to provide service for customer. IP is liable to 
> attack on
> > control plane and the consequences of such attack usually are very 
> > serious.
> > So, it is the foremost concern for ISP to protect control 
> plane from 
> > attack
> > inside or outside. In order to mitigate security risk on control 
> > plane, we
> > need a lot of work to do on standardization except 
> filtering, logging 
> > or dos
> > tracing. Actually some security mechnisms are identified in Pratices
> > document for control plane, BGP MD5 for example, but I 
> think there are 
> > still
> > other important aspect to identify. For example, quite a few SP use 
> > VPN to
> > seperate user/customer traffice from core network keep the 
> attack on 
> > SP core
> > from user/customer away from control plane.
> >
> > So I suggest following change,  (1) to add more text to Pratice
> > document to
> > reflect more security pratices on protecting control plane of SP 
> > network (2)
> > we need another Capabilty document to cover control plane 
> security of 
> > SP
> > network wihtout confliction on content with other Capabilty 
> documents, 
> > such
> > as filtering.
> >
> > Miao Fuyou
> > Data Communication, Wireline Research
> > Huawei Technologies Co., Ltd.
> > TEL: 86-10-8288 2502
> >
> > *****************************************************************
> > This e-mail and its attachments contain confidential 
> information from 
> > HUAWEI, which is intended only for the person or entity 
> whose address 
> > is listed above. Any use of the information contained herein in any 
> > way (including, but not limited to, total or partial disclosure,
> > reproduction,
> > or dissemination) by persons other than the intended recipient(s) is
> > prohibited. If you receive this e-mail in error, please notify the 
> > sender by
> > phone or email immediately and delete it
> >
> >
> >
>