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

[Roman Danyliw <[e-mail]>]

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 


>