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

From: Tom Yu <[email-masked]>
Date: Wed, 19 Jun 2013 23:58:21 -0400

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.

This document states many requirements on properties of proposed
solutions, but it seems that none of these requirements is a security
requirement.  If nodes need to send new information that existing
routing or signaling protocols do not currently send, what level of
protection does that information require?

In the Security Considerations section, I'm not sure what the intent
is in using the phrasing "man-in-the-middle confidentiality breach".
I generally consider "man-in-the-middle" to mean an active attacker
(one that can receive, suppress, modify, and transmit arbitrary data);
this type of attacker primarily has consequences for integrity.  (An
active attacker could also compromise the confidentiality of a channel
that is secure against passive attackers).  A passive attack is often
sufficient to compromise confidentiality, especially if a protocol
sends information in the clear.

What scope of compromise does "provider breach" designate?

Editorial:

This document uses many acronyms without expanding them -- almost all
of them, from what I can see.  Some of the more prominent ones include
DSCP, LDP, LSP, PW, RSVP-TE.  Arguably terms such as MPLS, VLAN, and
VPN count as well-known acronyms in the IETF community.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 Jun 2013 13:17:36 -0400

> protection does that information require?

Hi Tom,

> sends information in the clear.

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.

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."

> 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.

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.

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.

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.

> VPN count as well-known acronyms in the IETF community.

Stewart Bryant pointed this out and I have made changes and sent the
diffs to Stewart.

Curtis

---

From: Tom Yu <[email-masked]>
Date: Thu, 27 Jun 2013 18:59:31 -0400

> that they would prefer competitors didn't have and delay would be at

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.

> 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).

> workstations involved in network management.

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

> 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.

> 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.

> 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.

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 29 Jun 2013 20:25:28 -0400

Tom,

See inline, at the bottom.

In message <[email-masked]>
>     data origin authentication.

This paragraph is accurate.  The two sentences above, plus this
paragraph will replace the existing security section.

As you alreay know, this document will be going back to WGLC due to
the nature of the changes called for in the RtgDir review, which IMHO
greatly improve the document.

Thanks again for the review,

Curtis