Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07

Leeyoung <leeyoung@huawei.com> Wed, 19 October 2011 03:16 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F8C21F8783; Tue, 18 Oct 2011 20:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.413
X-Spam-Level:
X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ZAiGSfR9QMwY; Tue, 18 Oct 2011 20:16:56 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id A368F21F877F; Tue, 18 Oct 2011 20:16:56 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTA00HQTMG7AW@usaga02-in.huawei.com>; Tue, 18 Oct 2011 22:16:55 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTA002Q9MG7MC@usaga02-in.huawei.com>; Tue, 18 Oct 2011 22:16:55 -0500 (CDT)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 20:16:51 -0700
Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 20:16:46 -0700
Date: Wed, 19 Oct 2011 03:16:46 +0000
From: Leeyoung <leeyoung@huawei.com>
In-reply-to: <CAK3OfOhvV6HwH5i14LqmZX-o4aEzCe3Wk=8iZdg9AnVCXuJcsw@mail.gmail.com>
X-Originating-IP: [10.195.40.173]
To: Nico Williams <nico@cryptonector.com>
Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718181C1B@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US
Thread-topic: Review of draft-ietf-ccamp-wson-impairments-07
Thread-index: AQHMiK1k/aUAVZm3CECvsX0ct9xRXZV4912AgAB+a4CACZDzwA==
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <CAK3OfOj5Y8waYhCpoiiYg0GrL3E5SvWAPkkxmhP+2RHhoDdzgw@mail.gmail.com> <7AEB3D6833318045B4AE71C2C87E8E171817FEAA@DFWEML501-MBX.china.huawei.com> <CAK3OfOhvV6HwH5i14LqmZX-o4aEzCe3Wk=8iZdg9AnVCXuJcsw@mail.gmail.com>
X-Mailman-Approved-At: Wed, 19 Oct 2011 12:25:17 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ccamp-wson-impairments@tools.ietf.org" <draft-ietf-ccamp-wson-impairments@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-ccamp-wson-impairments-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2011 03:16:57 -0000

Hi Nicole,

As you indicated in the latest response, this document is first of all informational and does not define any new protocols beyond the family of OSPF-TE, RSVP-TE and PCEP. There are no new requirements caused by IA-RWA other than the need for processing additional routing/signaling related data beyond the regular TE networks. 
These additional data would not add any particular security requirements in my opinion. 

Anyhow, please see the following changes if you would be satisfied with them. 
------------------------------------------------------------------------
This document discusses a number of control plane architectures that
incorporate knowledge of impairments in optical networks. If such
architecture is put into use within a network it will by its nature
contain details of the physical characteristics of an optical
network. Such information would need to be protected from intentional
or unintentional disclosure similar to other network information used
within intra-domain protocols.

This document does not require changes to the security models within
GMPLS and associated protocols.  That is, the OSPF-TE, RSVP-TE, and
PCEP security models could be operated unchanged. However, satisfying
the requirements for impairment information dissemination using the existing
protocols may significantly affect the loading of those protocols.
This may make the operation of the network more vulnerable to active attacks 
such as injections, impersonation, and MITMs. Therefore, additional care maybe
required to ensure that the protocols are secure in the impairment-aware
WSON environment.

Furthermore, the additional information distributed in order to
address impairment information represents a disclosure of network
capabilities that an operator may wish to keep private. Consideration
should be given to securing this information.  For a general discussion
on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security
framework [RFC5920].
-------------------------------------------------------------------------------

Best Regards,
Young

-----Original Message-----
From: Nico Williams [mailto:nico@cryptonector.com] 
Sent: Wednesday, October 12, 2011 1:01 PM
To: Leeyoung
Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-wson-impairments@tools.ietf.org
Subject: Re: Review of draft-ietf-ccamp-wson-impairments-07

On Wed, Oct 12, 2011 at 12:30 PM, Leeyoung <leeyoung@huawei.com> wrote:
> Modified security section reads:
>
>   This document discusses a number of control plane architectures that
>   incorporate knowledge of impairments in optical networks. If such
>   architecture is put into use within a network it will by its nature
>   contain details of the physical characteristics of an optical
>   network. Such information would need to be protected from intentional
>   or unintentional disclosure similar to other network information used
>   within intra-domain protocols.
>
>   This document does not require changes to the security models within
>   GMPLS and associated protocols.  That is, the OSPF-TE, RSVP-TE, and
>   PCEP security models could be operated unchanged. However, satisfying
>   the requirements for impairment information dissemination using the existing
>   protocols may significantly affect the loading of those protocols.
>   This may make the operation of the network more vulnerable to denial-
>   of-service attacks or active attacks.  Therefore, additional care maybe
>   required to ensure that the protocols are secure in the impairment-aware
>   WSON environment.
>
>   Furthermore, the additional information distributed in order to
>   address impairment information represents a disclosure of network
>   capabilities that an operator may wish to keep private. Consideration
>   should be given to securing this information.  For a general discussion
>   on MPLS- and GMPLS-related security issues, see the MPLS/GMPLS security
>   framework [RFC5920].
>
> Please suggest some texts if these are not satisfactory to your need. Thanks.

I'm not concerned about denial of service attacks in particular as it
is often the case that there are denial of service attack surfaces
about which there's little we can do.  What I'm concerned about is
whether the framework can handle active attacks such as injections,
impersonation, and MITMs.  The reference to OSPF and friends is
probably sufficient in this regard for me to figure out an answer,
though saying something to the effect that a) you rely on such
protocols for security (your proposed change says so), and b) that
those protocols meet whatever you think the requirements ought to be
for IA-RWA.  Oh, and I suppose you should c) list what you think those
requirements are.  Of course, if these protocols don't today meet
those requirements, then that'd be a problem, but I suspect that won't
prove to be the case.

This is one of those occasions where it's good to ask "what's your
threat model" too.  My guess is that there isn't that much of a threat
from eavesdropping on IA-RWA, so passive attackers are not part of the
threat model.  What active attacks might be in the threat model?

Nico
--