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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Tom Yu writes:
> 
> 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?

Hi Tom,

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

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.

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

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

Curtis