Re: [secdir] SecDir review of draft-ietf-ccamp-general-constraint-encode

Leeyoung <leeyoung@huawei.com> Thu, 15 January 2015 21:30 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FA21A90CD; Thu, 15 Jan 2015 13:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmWYVDMxGYP6; Thu, 15 Jan 2015 13:30:00 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471561A8993; Thu, 15 Jan 2015 13:29:59 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ91060; Thu, 15 Jan 2015 21:29:57 +0000 (GMT)
Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 Jan 2015 21:29:57 +0000
Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml701-chm ([10.193.5.50]) with mapi id 14.03.0158.001; Thu, 15 Jan 2015 13:29:48 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Warren Kumari <warren@kumari.net>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org" <draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org>
Thread-Topic: SecDir review of draft-ietf-ccamp-general-constraint-encode
Thread-Index: AQHQLdwpi9kcjmRWWUyL0vaRwgDJ2pzBtVMQ
Date: Thu, 15 Jan 2015 21:29:48 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729C71F5E@dfweml706-chm>
References: <CAHw9_iJg0K=9wUSBVekDe5eVJw4PkVu3doPRYu=9=XeQ_5wFAA@mail.gmail.com>
In-Reply-To: <CAHw9_iJg0K=9wUSBVekDe5eVJw4PkVu3doPRYu=9=XeQ_5wFAA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-hashedpuzzle: DcPy Gjx2 IyHl JhFI MdHN O1Ll PB6N QH7z RISL TV6n c/gc d3eD jAS2 oSw4 ohcz rii0; 4; ZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAZQBuAGUAcgBhAGwALQBjAG8AbgBzAHQAcgBhAGkAbgB0AC0AZQBuAGMAbwBkAGUALgBhAGwAbABAAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA7AHcAYQByAHIAZQBuAEAAawB1AG0AYQByAGkALgBuAGUAdAA=; Sosha1_v1; 7; {670DBCAF-364A-4217-84B0-09F46A49422A}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Thu, 15 Jan 2015 21:29:39 GMT; UgBFADoAIABTAGUAYwBEAGkAcgAgAHIAZQB2AGkAZQB3ACAAbwBmACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGcAZQBuAGUAcgBhAGwALQBjAG8AbgBzAHQAcgBhAGkAbgB0AC0AZQBuAGMAbwBkAGUA
x-cr-puzzleid: {670DBCAF-364A-4217-84B0-09F46A49422A}
x-originating-ip: [10.192.11.120]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/rJT-yqgUR8ao_FRacfH8NZlkhfg>
Subject: Re: [secdir] SecDir review of draft-ietf-ccamp-general-constraint-encode
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 15 Jan 2015 21:30:02 -0000

Hi Warren,

Thanks for your through review and comments. 

I think all your comment are acceptable. Please see inline for details. 

Thanks,
Young

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net] 
Sent: Sunday, January 11, 2015 2:21 PM
To: iesg@ietf.org; secdir@ietf.org; draft-ietf-ccamp-general-constraint-encode.all@tools.ietf.org
Subject: SecDir review of draft-ietf-ccamp-general-constraint-encode

Be ye not alarmed...

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

tl;dr: Ready with nits.

Summary:
This draft contains a Standards Track document on encoding label and
connectivity constraints on GMPLS controlled networks. It also has
some wicked ASCII art....

I'm not really a GMPLS person, and so some of the constraints that
this discussed hadn't really occurred to me (like some gear not being
able to do wavelength conversion -- by the time I see a link its in a
router :-)). Anyway, this seem like a real problem, and the solution
seems reasonable.
From a security standpoint I couldn't really see much issue here -- I
guess a suitably placed attacker could signal additional constraints,
either forcing paths to be built past a place where he could intercept
them, or adding constraints that prevent paths from being built at
all. An attacker with this level of access has already won, and so I
don't view this as a major issue.

I *do* however have a pile o' nits, see below, in COPE (Comment,
Original, Proposed, Error) format. These are all readability /
grammar, no substantive changes below....

Abstract

   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies. In some of these technologies network

[O]In some of these technologies network

[P] In some of these technologies, network

//YOUNG// OK. 

[C] grammar

   elements and links may impose additional routing constraints such as
   asymmetric switch connectivity, non-local label assignment, and
   label range limitations on links.

  [ SNIP ]



     1.1. Node Switching Asymmetry Constraints

   For some network elements the ability of a signal or packet on a

[O] For some network elements the ability

[P] For some network elements, the ability

//YOUNG// OK. 

[C] grammar/readability

   particular input port to reach a particular output port may be
   limited. In addition, in some network elements the connectivity
   between some input ports and output ports may be fixed, e.g., a
   simple multiplexer. To take into account such constraints during
   path computation we model this aspect of a network element via a

[O] path computation we model

[P] path computation, we model

//YOUNG// OK. 

[C] grammar/readability



   connectivity matrix.

   The connectivity matrix (ConnectivityMatrix) represents either the
   potential connectivity matrix for asymmetric switches or fixed
   connectivity for an asymmetric device such as a multiplexer. Note
   that this matrix does not represent any particular internal blocking
   behavior but indicates which input ports and labels (e.g.,
   wavelengths) could possibly be connected to a particular output port
   and label pair. Representing internal state dependent blocking for a
   node is beyond the scope of this document and due to it's highly
   implementation dependent nature would most likely not be subject to

[O] and due to it's highly implementation dependent nature would most

[P] and, due to its highly implementation-dependent nature, would most

//YOUNG// OK. 

[C] apostrophe removed and two commas added; grammar/readability

   standardization in the future. The connectivity matrix is a
   conceptual M*m by N*n matrix where M represents the number of input
   ports each with m labels and N the number of output ports each with
   n labels.

     1.2. Non-Local Label Assignment Constraints

   If the nature of the equipment involved in a network results in a
   requirement for non-local label assignment we can have constraints

[O] for non-local label assignment we can have

[P] for non-local label assignment, we can have

//YOUNG// OK. 

[C] grammar/readability



   based on limits imposed by the ports themselves and those that are
   implied by the current label usage. Note that constraints such as
   these only become important when label assignment has a non-local
   character. For example in MPLS an LSR may have a limited range of
   labels available for use on an output port and a set of labels
   already in use on that port and hence unavailable for use. This

[O] For example in MPLS an LSR may have a limited range of

   labels available for use on an output port and a set of labels
   already in use on that port and hence unavailable for use.

[P] For example, in MPLS an LSR may have a limited range of labels
available for use on an output port, and a set of labels

   already in use on that port, and hence unavailable for use.

//YOUNG// OK. 

[C] grammar/readability


   information, however, does not need to be shared unless there is
   some limitation on the LSR's label swapping ability. For example if
   a TDM node lacks the ability to perform time-slot interchange or a
   WSON lacks the ability to perform wavelength conversion then the
   label assignment process is not local to a single node and it may be
   advantageous to share the label assignment constraint information
   for use in path computation.

[O] For example if

   a TDM node lacks the ability to perform time-slot interchange or a
   WSON lacks the ability to perform wavelength conversion then the
   label assignment process is not local to a single node and it may be
   advantageous to share the label assignment constraint information
   for use in path computation.

[P] For example, if a TDM node lacks the ability to perform time-slot
interchange, or a WSON lacks the ability to perform wavelength
conversion, then the label assignment process is not local to a single
node. In this case, it is may be advantageous to share the label
assignment constraint information for use in path computation.

//YOUNG// OK. 

[C] run on sentence; broken up and punctuated for readability.

   Port label restrictions (PortLabelRestriction) model the label
   restrictions that the network element (node) and link may impose on
   a port. These restrictions tell us what labels may or may not be



[ SNIP ]

   The Connectivity Matrix Field represents how input ports are
   connected to output ports for network elements. The switch and fixed
   connectivity matrices can be compactly represented in terms of a
   minimal list of input and output port set pairs that have mutual
   connectivity. As described in [Switch] such a minimal list

[O] As described in [Switch] such a minimal list

[P] As described in [Switch], such a minimal list

//YOUNG// OK. 

[C] grammar/readability

   representation leads naturally to a graph representation for path
   computation purposes that involves the fewest additional nodes and
   links.

 [SNIP]

   o  Link Set A dir=input, Link Set B dir=output

     The meaning of the pair of link sets A and B in this case is that
     any signal that inputs a link in set A can be potentially switched
     out of an output link in set B.

[O]  The meaning of the pair of link sets A and B in this case is that

     any signal that inputs a link in set A can be potentially switched
     out of an output link in set B.

[P] In this case, the meaning of the pair of link sets A and B is that
any signal that inputs a link in set A can be potentially switched out
of an output link in set B.

//YOUNG// OK. 

[C] readability

   o  Link Set A dir=bidirectional, Link Set B dir=bidirectional


[SNIP]

   The port label restriction can be encoded as follows: More than one
   of these fields may be needed to fully specify a complex port
   constraint. When more than one of these fields are present the

[O] When more than one of these fields are present the

[P] When more than one of these fields are present, the

//YOUNG// OK. 

[C] grammar

   resulting restriction is the union of the restrictions expressed in
   each field. To indicate that a restriction applies to the port in
   general and not to a specific connectivity matrix use the reserved
   value of 0xFF for the MatrixID.


[O] To indicate that a restriction applies to the port in

   general and not to a specific connectivity matrix use the reserved
   value of 0xFF for the MatrixID.

[P] Use the reserved value of 0xFF for the MatrixID to indicate that a
restriction applies to the port.

//YOUNG// OK. 

[C] grammar/readability


   [BIG SNIP]




3. Security Considerations

   This document defines protocol-independent encodings for WSON
   information and does not introduce any security issues.

   However, other documents that make use of these encodings within
   protocol extensions need to consider the issues and risks associated



Bernstein and Lee       Expires June 29, 2015                 [Page 17]

Internet-Draft General Network Element Constraint Encoding December
2014


   with, inspection, interception, modification, or spoofing of any of

[O]  with, inspection

[P] with inspection

//YOUNG// OK.

[R] no comma needed




-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf