Re: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10

Tom Yu <tlyu@MIT.EDU> Thu, 27 June 2013 22:59 UTC

Return-Path: <tlyu@mit.edu>
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 7125A21F9DCA; Thu, 27 Jun 2013 15:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 4J0hIOo6Qww0; Thu, 27 Jun 2013 15:59:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8498021F9DC7; Thu, 27 Jun 2013 15:59:37 -0700 (PDT)
X-AuditID: 12074425-b7f0c8e000000953-aa-51ccc3d8825a
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 39.A5.02387.8D3CCC15; Thu, 27 Jun 2013 18:59:36 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r5RMxYhR002084; Thu, 27 Jun 2013 18:59:34 -0400
Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5RMxVqQ024213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 18:59:33 -0400
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r5RMxVmi021077; Thu, 27 Jun 2013 18:59:31 -0400 (EDT)
To: curtis@ipv6.occnc.com
References: <201306201717.r5KHHaaW004832@gateway1.orleans.occnc.com>
From: Tom Yu <tlyu@MIT.EDU>
Date: Thu, 27 Jun 2013 18:59:31 -0400
In-Reply-To: <201306201717.r5KHHaaW004832@gateway1.orleans.occnc.com> (Curtis Villamizar's message of "Thu, 20 Jun 2013 13:17:36 -0400")
Message-ID: <ldvppv7qhws.fsf@cathode-dark-space.mit.edu>
Lines: 125
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrXvj8JlAg2vzmS0mzzrDZrGjS9ti xp+JzBYfFj5kcWDxWLLkJ5PHsvsX2Ty+XP7MFsAcxWWTkpqTWZZapG+XwJXxuaGdveCMccXW kxcZGxgfaXYxcnJICJhInD3dwwphi0lcuLeerYuRi0NIYB+jxMtvR9ghnI2MEkeb97NCOOeY JFpf9zJBOF2MEov+X2AE6RcRkJT4dvAk2CxmgXiJ7e83MIPYwgIOEsvmv2cDsYUEXCQ+7P4G 1MzBwSYgLXF0cRlImEVAVWLhxuVgqzkFOhglnr46DjaTV8BCoqX9INhMHgEuia0fHjJBxAUl Ts58wgKxS0vixr+XTBMYBWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NE LzWldBMjKJDZXVR3ME44pHSIUYCDUYmH90bymUAh1sSy4srcQ4ySHExKorwbDgKF+JLyUyoz Eosz4otKc1KLDzFKcDArifDeWQCU401JrKxKLcqHSUlzsCiJ84rd2hkoJJCeWJKanZpakFoE k5Xh4FCS4N16CKhRsCg1PbUiLTOnBCHNxMEJMpwHaPg+kBre4oLE3OLMdIj8KUZFKXGIhABI IqM0D64XlmheMYoDvSLMGwFyNw8wScF1vwIazAQ0eOaSUyCDSxIRUlINjHv1bzXe7pNTT06Y e6/UWr7tW8/uPVtn/DZpsgg1TTkWmiU2KfOFb0ba9cSU6z8cwrcy6TwrnZ6qULZiD59c6Cxn WZVObt3U/4lTu5otjAPX31h4slRc6mFC0guRaMe+YLlThsLvPzQwttaEH79a7SHS2xuaLXhU ReP/Oom6vw8up7S1nNutxFKckWioxVxUnAgA4i2H7Q8DAAA=
Cc: draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-rtgwg-cl-requirement-10
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: Thu, 27 Jun 2013 22:59:44 -0000

Curtis Villamizar <curtis@ipv6.occnc.com> writes:

> The entire one paragraph section is:
>
>    This document specifies a set of requirements.  The requirements
>    themselves do not pose a security threat.  If these requirements are
>    met using MPLS signaling as commonly practiced today with
>    authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP,
>    then the requirement to provide additional information in this
>    communication presents additional information that could conceivably
>    be gathered in a man-in-the-middle confidentiality breach.  Such an
>    attack would require a capability to monitor this signaling either
>    through a provider breach or access to provider physical transmission
>    infrastructure.  A provider breach already poses a threat of numerous
>    tpes of attacks which are of far more serious consequence.  Encrption
>    of the signaling can prevent or render more difficult any
>    confidentiality breach that otherwise might occur by means of access
>    to provider physical transmission infrastructure.
>
> What is meant by "man-in-the-middle confidentiality breach" is a
> man-in-the-middle situation in which the extent of damage is loss of
> confidentiality due to routing protocols generally being authenticated
> but in the clear, in this case the OSPF-TE and ISIS-TE.  This is no
> different, except now additional information is present, such as
> delay.  Providers already feel that topology is sensitive information
> that they would prefer competitors didn't have and delay would be at
> least as sensitive.

Readers with security backgrounds would assume that
"man-in-the-middle" refers to an active attack (see RFC 4949).  I
suggest removing that phrase, because it seems that in your
"authenticated but unencrypted" case, a passive attack is sufficient
to compromise confidentiality, and implying an active attack is
confusing to the reader.

> The sentence in question is the first third "If these requirements are
> met using MPLS signaling as commonly practiced today with
> authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP,
> then the requirement to provide additional information in this
> communication presents additional information that could conceivably
> be gathered in a man-in-the-middle confidentiality breach."

Is the additional information of equal, greater, or lesser value than
the information exchanged with the existing routing and signaling
protocols?  Does it add nontrivial value (to an attacker) to the
existing information that the routing and signaling protocols already
exchange?  If an attacker can manipulate the additional information,
e.g., delay measurements, can there be results such as routing
instabilities?

If such harmful results can occur from manipulation of the additional
information that this document specifies, it seems that would require
a minimum of an authenticated integrity-protected channel (or
acceptance of the risks involved with relying on the physical and
logical security of the service provider's equipment and transmission
links).

>> What scope of compromise does "provider breach" designate?
>
> What is meant by "provider breach" is any breach in which equipment
> used in the provider infrastructure or management of that
> infrastructure is fully compromised.  It is well known that really bad
> things can happen if a router is compromised and can inject bad
> information.  It is also well known that bad things can happen if
> there is a compromise of management systems and in some cases
> workstations involved in network management.

There are equipment compromises less serious than a full compromise
that could have an impact on confidentiality.

> The access to physical transmission infrastructure means being able to
> listen in on microwave or being able to put a bend in fiber and get
> som light to leak out or somehow otherwise monitoring the signal,
> demodulating it, and looking at anything in the clear.

These physical link attacks, while possibly expensive to execute, are
still only passive attacks from a cryptographic perspective, not
"man-in-the-middle" active attacks.

> The entire section is acknowledging an imperfect status quo and trying
> to say that it makes it no worse.  Perhaps is does so unclearly.
> Maybe we could just replace the section with the standard boilerplate:
>
>    The security considerations for MPLS/GMPLS and for MPLS-TP are
>    documented in
>    <xref target="RFC5920" /> and
>    <xref target="RFC6941" />.
>    This document does not impact the security of MPLS, GMPLS, or
>    MPLS-TP.
>
> That would certainly be more clear.  This type of boilerplate is in
> the framework document but could be moved to the requirements
> document.  See draft-ietf-rtgwg-cl-framework.

I agree that acknowledging the imperfect status quo is useful.
Whether the proposed extensions make things worse depends on the
relative value of the additional information that protocol
participants will exchange, but it seems that you believe it to be of
minimal additional value to an attacker.

I'm not clear on whether your proposed replacement text encompasses
the entire set of routing and signaling protocols that could be
affected by this requirements document, but maybe I'm not sufficiently
familiar with this space.

> Would you prefer a wholesale replacement, or fixing up the existing
> wording to make it more clear?  If the latter, can you please suggest
> text that you feel is clear.  I prefer the two sentence replacement
> above since it is clear and simple and accurate.

I think the two sentences you propose above would be sufficient as
replacement text if combined with text like the following, assuming it
is accurate for the situation:

    The additional information that this document requires does not
    provide significant additional value to an attacker beyond the
    information already typically available from attacking a routing
    or signaling protocol.  If the requirements of this document are
    met by extending an existing routing or signaling protocol, the
    security considerations of the protocol being extended apply.  If
    the requirements of this document are met by specifying a new
    protocol, the security considerations of that new protocol should
    include an evaluation of what level of protection is required by
    the additional information specified in this document, such as
    data origin authentication.