[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What about X.805? (was RE: Control Plane Security of ISP Network)
For definitions, why not use X.805? What are people's thoughts on X.805?
http://www.ietf.org/IESG/LIAISON/itut-sg17-ls-x805-end2end-communication
s.pdf
Is a good place to start.
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On
> Behalf Of Smith, Donald
> Sent: Monday, June 06, 2005 7:40 AM
> To: pmrn; Miao Fuyou
> Cc: Merike Kaeo; opsec@ops.ietf.org; eludom@gmail.com
> Subject: RE: Control Plane Security of ISP Network
>
> While OOB for management is a good idea many ISPs do
> management in band.
> By splitting the traffic into "planes" it allows us to
> discuss the functions and security of those functions.
> So in my opinion control plane (dynamic routing updates,
> semiautomic communications), management (user initiated,
> interactive, possibly scripted or automated management), and
> data or user plane ( the actual application data, session
> setup etc...) are good abstracts.
> Miao, if you get a draft control plane security document
> written I would be happy to review it and provide comments.
>
> Clearly my definitions of data, mgmt, and ctrl planes are not
> complete;) A good definition of the ctrl plane will probably
> be a good place to start.
> Do we include icmp port/host/net unreachable and other icmp
> error messages in the control plane?
>
>
>
>
> donald.smith@qwest.com giac
>
> -----Original Message-----
> From: owner-opsec@psg.com [mailto:owner-opsec@psg.com]
> On Behalf Of pmrn
> Sent: Monday, June 06, 2005 4:15 AM
> To: Miao Fuyou
> Cc: 'Merike Kaeo'; opsec@ops.ietf.org; eludom@gmail.com
> Subject: Re: Control Plane Security of ISP Network
>
>
> Feels like going back to the old days of SS7,
> ISDN........ It possible to separate the management network
> and adequately secure it. As person who has implemented very
> large scale service provider networks, I understand the
> importance and concern about security but, going back to
> yesterady may not be ideal solution.
>
> The plane separation you are describing is generally
> known as out-of-band management and generally implemented in
> large carrier scale networks for security reasons and to
> alleviate many traffic engineering issues.
>
>
>
> Pall Ramanathan
>
>
>
>
>
>
>
>
>
>
>
>
> Learn like you will live for ever and Live like you
> will die tomorrow-Gandhi
>
>
> On Jun 6, 2005, at 5:42 AM, Miao Fuyou wrote:
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>