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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 09 Jul 2019 13:08:40 -0700

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework/

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

(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”?

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

(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/

(5) Section 9.  I’m missing something obvious -- what is a “label table
pe2.mpls”?

---

From: Yimin Shen <[email-masked]>
Date: Fri, 12 Jul 2019 13:59:13 +0000

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" <[email-masked]> wrote:

    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=X9HyscF98j23N9gokdZCH9iEG0x_yrqq45haf_Mseus&s=3coZyWz9ap2Zfz4Y4g17fpbs5CyIQnK3OecHx5BBXDE&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=X9HyscF98j23N9gokdZCH9iEG0x_yrqq45haf_Mseus&s=6r9KW52kfdX1MRN_rfpiU1ILMNibzZh7ub-VcoEKCQM&e= 

    

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

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

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

[yshen] Will fix this.

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

---

From: Yimin Shen <[email-masked]>
Date: Thu, 18 Jul 2019 20:50:57 +0000

Hi Roman,

We are planning to update the "Security Considerations" section as below to address your suggestions. Please let us know if you can agree on this and clear the discuss state.  

-----

       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. 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. Common secure measures include authentication methods and password-based methods. This framework does not foresee requiring additional security measures for these protocols. The security aspects SHOULD be defined in the protocol-specific documents.

       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 be allowed and run securely across the domain boundary. The forwarding performed by the routers in the data plane is also anticipated, as part of the planning 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. Such attack could occur regardless of the existence of egress protection. If egress link protection is in place, the attack might also trigger egress link protection activities. 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.

Thanks,

-- Yimin

On 7/12/19, 9:59 AM, "Yimin Shen" <[email-masked]> wrote:

    the same manner as that of an inter-AS protocols

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 23 Jul 2019 21:48:22 +0000

Hi Yimin!

> -----Original Message-----
> From: Yimin Shen [mailto:[email-masked]]
> Sent: Friday, July 12, 2019 9:59 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; Loa Andersson
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-mpls-egress-protection-
> framework-06: (with DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> 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
> 
>     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=
>     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=
> 
> 
> 
> [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.

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

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

>     recommend being explicit and saying and s/IPv4\\v6/IPv4 or v6/

Thanks.

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

---

From: Yimin Shen <[email-masked]>
Date: Thu, 25 Jul 2019 14:15:39 +0000

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" <[email-masked]> wrote:

    Hi Yimin!

    
    
    OLD:
       Some control
    
    NEW

    

    Thanks.

    Thanks.

    
    Roman

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 30 Jul 2019 16:14:13 +0000

Hi Yimin!

This revised addresses both of my discuss items.  Thank you synthesizing it.

Regards,
Roman

> Sent: Thursday, July 25, 2019 10:16 AM
> 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.
> 
>     > On 7/9/19, 4:08 PM, "Roman Danyliw via Datatracker"
> <[email-masked]>
>     > wrote:
>     >
>     >     (1) Section 11.  I appreciate that this a framework document that is
> trying
>     > to
>     >     choices (understandable) and the security services/properties they
> would
>     > 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.
> 
>     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.
> 
>     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".
> 
>     >     (3) Section 4.  Per “The framework MUST consider minimizing
> disruption
>     > during
>     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
> 
> 
>     >
> 
>

---

From: Yimin Shen <[email-masked]>
Date: Wed, 31 Jul 2019 14:02:52 +0000

Hi Roman,

We have uploaded a new version (07) of this draft. It has addressed the comments and incorporated the suggestions which we received from IESG review.

Thanks again for all the kind reviews !

-- Yimin Shen

On 7/30/19, 12:14 PM, "Roman Danyliw" <[email-masked]> wrote:

    Hi Yimin!

    Regards,
    Roman
    
    > implement