Re: [mpls] Secdir last call review of draft-ietf-mpls-egress-protection-framework-05

[Yimin Shen <[e-mail]>]

Hi Christian,

Thanks very much for your security review for this draft!

We agree with you on the possibility of attack via a CE or customer site. As you have mentioned, such kind of attack may well happen to a network in the absence of the egress protection in this draft. Our view is that the network should generally be defended by using a damping mechanism on egress routers, so that the service destinations associated with a constantly flapping link are suppressed from being accepted, recognized, and advertised to other egress routers. This should be able to defeat the root cause of the attack, and prevent it from triggering control plane activities in the MPLS network, including the egress protection activities. From that perspective, the egress protection in this draft does not make a network more vulnerable to such attack. We can add text to the Security Consideration section to clarify this.

Thanks,

-- Yimin Shen


On 6/17/19, 9:39 PM, "Christian Huitema via Datatracker" <[e-mail]> wrote:

    Reviewer: Christian Huitema
    Review result: Has Nits
    
    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.
    
    I think the document is almost ready, although I would like some considerations
    of a potential attack through the customer equipment.
    
    I reviewed draft-ietf-mpls-egress-protection-framework-05, MPLS Egress Protection Framework.
    The document specifies a framework for implementing protection of an MPLS tunnel against
    failure of the egress router or the egress link. 
    
    The implementation of the framework relies on the control functions of the MPLS network,
    and the security considerations correctly state that the security of the implementation relies on
    the security of these protocols. The security consideration also point out the need for
    special establishment of trust if the nodes involved are not under the same administrative
    authority.
    
    These general security considerations are correct, but I am concerned that the egress
    links between the MPLS network routers and the customer could also become a point of
    attack. Attackers that gain control of a customer's equipment might use it to simulate
    link failures and trigger the backup mechanism. They could do so in a coordinated fashion
    across a large number of customer equipments, to try overload the control plane or try
    create cascading effects in the network.
    
    It may well be that in the absence of the local backup mechanism, the attackers could mount
    the same type of attack and trigger an other type of control plane activity. The defenses
    against that might also defend against the attack listed in the previous paragraph. But
    it might be good to state it.