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

[Yimin Shen <[e-mail]>]

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.

https://datatracker.ietf.org/doc/draft-ietf-mpls-egress-protection-framework/

Thanks again for all the kind reviews !

-- Yimin Shen



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

    Hi Yimin!
    
    This revised addresses both of my discuss items.  Thank you synthesizing it.
    
    Regards,
    Roman
    
    > -----Original Message-----
    > From: Yimin Shen [mailto:[e-mail]]
    > Sent: Thursday, July 25, 2019 10:16 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 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
    > 
    > 
    >     >
    > 
    >