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

[Curtis Villamizar <[e-mail]>]

Tom,

See inline, at the bottom.

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

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