Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Stephen Kent writes:
> 
> Curtis,
>  
> Thanks for the quick reply.
>  
> I agree that a thorough summary of the relevant security considerations
> from the many normative references would be a non-trivial task ;-).
> The brief summary you assembled is excellent!
>  
> I am satisfied with the changes/responses.
>  
> Steve


Steve,

If you don't mind I'd like to add a little to this.  This is the very
last paragraph and follows the numbered list.

 OLD PROPOSED

   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).

 NEW PROPOSED

   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).  THe MPLS-TP
   security framework [RFC6941] build upon this, focusing largely on
   the MPLS-TP OAM additions and OAM channels with some attention
   given to using network management in place of control plane setup.
   In both security framework documents MPLS is assumed to run within
   a "trusted zuone", defined as being where a single service provider
   (SP) has total operational control over that part of the network.

   If control plane security and management plane security are
   sufficiently robust, compromise of a single network element may
   result in chaos in the data plane anywhere in the network through
   denial of service attacks, but not a Byzantine security failure in
   which other network elements are fully compromised.

   MPLS security, or lack of, can affect whether traffic can be
   misrouted and lost, or intercepted, or intercepted and reinserted
   (a man-in-the-middle attack) or spoofed.  End user applications,
   including control plane and management plane protocols used by the
   SP, are expected to make use of appropriate end-to-end
   authentication and where appropriate end-to-end encryption.

I think the original, while not incorrect, was too brief.  This new
text provides a better summary, indicating the underlying "trusted
zuone" assumption and the lack of any meaningful data plane security
if that underlying assumption proves invalid for any reason, but most
likely invalid due to a breach or a physical intercept along
transmission media.

Please let me know if this further change is an improvement or if we
should leave it out (or change it).

Curtis