Re: [mpls] Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-framework-06: (with DISCUSS and COMMENT)

[Yimin Shen <[e-mail]>]

Hi Roman,

Thanks again for your detailed review and comments! Please see below for the revised text which has incorporated your suggestions. 

In particular, for your comment on the "In one possible case ..." about a CE-launched attack, this paragraph was added to address a comment from another view.  The case is not associated tightly with egress protection, but we thought it would be worth mentioning it, with a clarification that [1] such kind of attacks are not introduced by egress protection;  [2] they can happen regardless of egress protection; [3] there are existing mechanisms to deal with them. We have clarified more in the new text below.

Please let us know if you have more comment, or can resolve the discussion. Thanks again! 

----

12.  Security Considerations

   The framework in this document involves rerouting traffic around an
   egress node or link failure, via a bypass path from a PLR to a
   protector, and ultimately to a backup egress router.  
   The forwarding performed by the routers in the data plane
   is anticipated, as part of the planning of egress protection.

   Control plane protocols MAY be used to facilitate the provisioning of 
   the egress protection on the routers.  In particular, the framework requires 
   a service label distribution protocol between an egress router and a protector 
   over a secure session.  The security properties of this provisioning and label 
   distribution depend entirely on the underlying protocol chosen to implement 
   these activities . Their associated security considerations apply. This framework 
   introduces no new security requirements or guarantees relative to these activities.

   Also, the PLR, protector, and backup egress router are located close
   to the protected egress router, and normally in the same
   administrative domain.  If they are not in the same administrative
   domain, a certain level of trust MUST be established between them in
   order for the protocols to run securely across the domain
   boundary.  The basis of this trust is the security model of the protocols
   (as described above), and further security considerations for inter-domain
   scenarios should be addressed by the protocols as a common requirement.

   Security attacks may sometimes come from a customer domain.
   Such kind of attacks are not introduced by the framework
   in this document, and may occur regardless of the existence of 
   egress protection. In one possible case, the egress link between an egress 
   router and a CE could become a point of attack.  An attacker that gains control
   of the CE might use it to simulate link failures and trigger constant
   and cascading activities in the network. If egress link protection is 
   in place, egress link protection activities may also be triggered. 
   As a general solution to defeat the attack, a damping mechanism 
   SHOULD be used by the egress router to promptly
   suppress the services associated with the link or CE.  The egress
   router would stop advertising the services, essentially detaching
   them from the network and eliminating the effect of the simulated
   link failures.

   From the above perspectives, this framework does not introduce any
   new security threat to networks.


Thanks,

-- Yimin






On 7/23/19, 5:48 PM, "Roman Danyliw" <[e-mail]> wrote:

    Hi Yimin!
    
    > -----Original Message-----
    > From: Yimin Shen [mailto:[e-mail]]
    > Sent: Friday, July 12, 2019 9:59 AM
    > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
    > Cc: [e-mail]; Loa Andersson
    > <[e-mail]>; [e-mail]; [e-mail]
    > Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-
    > framework-06: (with DISCUSS and COMMENT)
    > 
    > Hi Roman,
    > 
    > Thanks very much for your review!
    > 
    > Please see inline below for the changes we plan to make, and let us know if
    > they are sufficient to resolve this discussion.
    > 
    > Thanks,
    > 
    > -- Yimin
    > 
    > On 7/9/19, 4:08 PM, "Roman Danyliw via Datatracker" <[e-mail]>
    > wrote:
    > 
    >     Roman Danyliw has entered the following ballot position for
    >     draft-ietf-mpls-egress-protection-framework-06: Discuss
    > 
    >     When responding, please keep the subject line intact and reply to all
    >     email addresses included in the To and CC lines. (Feel free to cut this
    >     introductory paragraph, however.)
    > 
    > 
    >     Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
    > 3A__www.ietf.org_iesg_statement_discuss-
    > 2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
    > ndb3voDTXcWzoCI&r=2-
    > nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
    > dZCH9iEG0x_yrqq45haf_Mseus&s=3coZyWz9ap2Zfz4Y4g17fpbs5CyIQnK3Oe
    > cHx5BBXDE&e=
    >     for more information about IESG DISCUSS and COMMENT positions.
    > 
    > 
    >     The document, along with other ballot positions, can be found here:
    >     https://urldefense.proofpoint.com/v2/url?u=https-
    > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmpls-2Degress-2Dprotection-
    > 2Dframework_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
    > ndb3voDTXcWzoCI&r=2-
    > nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=X9HyscF98j23N9gok
    > dZCH9iEG0x_yrqq45haf_Mseus&s=6r9KW52kfdX1MRN_rfpiU1ILMNibzZh7u
    > b-VcoEKCQM&e=
    > 
    > 
    > 
    >     ----------------------------------------------------------------------
    >     DISCUSS:
    >     ----------------------------------------------------------------------
    > 
    >     A few questions about the Security Considerations:
    > 
    >     (1) Section 11.  I appreciate that this a framework document that is trying
    > to
    >     be generic.  Section 4 (and others) seem to lay out generic requirements.
    >     However, this Security Considerations section is both vague on the
    > protocol
    >     choices (understandable) and the security services/properties they would
    > have
    >     (the gap).   For example, “The general security measures of the protocols
    >     SHOULD be used whenever applicable.” and “The available security
    > measures of
    >     the chosen protocol SHOULD be used to achieve a secured session
    > between the two
    >     routers.”  Some discussion of what a “secured session” would look like
    > would be
    >     helpful.
    > 
    > [yshen] We could say that “The general security measures of the protocols
    > SHOULD be used whenever needed and applicable, e.g. an authentication
    > method or password. The framework does not require additional security
    > measures for these protocols, other than what they already have."
    
    Thanks.  I think I better understand what is meant with the text.  Correct me here, but it seems like you're saying that the security of establishing the egress protection behavior rests on the underlying security properties of the control plane/service label distribution protocols used to establish the it.   Likewise, I'm assuming that the alluded alternative to using a control plan protocol (since the current text uses a MAY) is manual configuration.
    
    If my understanding is correct, might I suggest the following to make it clearer on what is in and out of scope:
    
    OLD:
       Some control
       plane protocols MAY be used between these routers to facilitate the
       establishment of egress protection.  The general security measures of
       the protocols SHOULD be used whenever applicable.  In particular, the
       framework requires a service label distribution protocol between an
       egress router and a protector.  The security measures of the chosen
       protocol SHOULD be used to achieve a secured session between the two
       routers.
    
    NEW
    Control plane protocols MAY be used to facilitate the provisioning of this egress protection on the routers.  In particular, this framework requires a service label distribution protocol between an egress router and a protector over secure session.  The security properties of this provisioning and label distribution depend entirely on the underlying protocol chosen to implement these activities .  Their associated security considerations apply.  This framework introduces no new security requirements or guarantees relative to these activities.
    
    >     (2) Section 11.  What are the elements and enablers of “a certain level of
    >     trust … [being] established between the routers for the protocols to run
    >     securely”?
    > 
    > [yshen] Here, the "trust" simply means that, first the routers are allowed to
    > run the protocols between them; and second, the protocols are run securely
    > like the above. Again, this should be the same manner as that of an inter-AS
    > protocols.
    
    Understood.  I believe we need a more detailed statement that (1) the basis of this trust is the security model of the selected protocols (like above); and a (paragraphing): "there security considerations for inter-AS protocols <as defined here> and they should be addressed by the implemented protocol".
    
    Finally, given what you've explained about the first two paragraphs, the second from last paragraph, "In one possible case ...",  seems to actually discuss a security issues relative to this framework.  Hence, I don't understand the basis of new last paragraph "From the above perspective, this framework doesn't introduce any new security threats to the network".
    
    >     ----------------------------------------------------------------------
    >     COMMENT:
    >     ----------------------------------------------------------------------
    > 
    >     (3) Section 4.  Per “The framework MUST consider minimizing disruption
    > during
    >     deployment”, why is this MUST only to _consider_ minimizing rather than
    >     actually minimizing the disruption?
    > 
    > [yshen] Will change this to "This framework must minimize disruption ...".
    > Also pointed out by some other viewers, the normative terms
    > MAY/SHOULD/MUST are not suitable for this "consideration" section. Will
    > replace them with may/should/must.
    
    Thanks.
    
    >     (4) Section 5.7.  Per “a globally unique IPv4/v6 address  is assigned to a
    >     protected egress {E, P} as the identifier of the protected egress {E, P}”, I
    >     recommend being explicit and saying and s/IPv4\\v6/IPv4 or v6/
    > 
    > [yshen] Will fix this.
    
    Thanks.
    
    >     (5) Section 9.  I’m missing something obvious -- what is a “label table
    >     pe2.mpls”?
    > 
    > [yshen] I think you are talking about the example in section 10. As it specifies
    > in the first paragraph, " On PE3, ....., and a table pe2.mpls is created to
    > represent PE2's label space."
    
    We're talking about the same thing, the section titled "Example: Layer-3 VPN egress protection" (it was section 9 in -05 and section 10 in -05).  I understand now.  Thank you for the clarification.
    
    Roman 
    
    
    >