Re: [secdir] SECDIR review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05

[Lizhong Jin <[e-mail]>]

Hi Stephen,
We upload the new version. The URL:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-06
Please check if you are OK with this version. Thank you for detail review.

Regards
Lizhong


On Thursday, April 17, 2014, Lizhong Jin <[e-mail]> wrote:

>  Hi Stephen,
>
> See my reply inline below. Thank you.
>
>
>
> Regards
>
> Lizhong
>
>
>
>
>
> *From:* Stephen Kent [mailto:[e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>]
>
> *Sent:* Thursday, April 17, 2014 9:55 PM
> *To:* Lizhong Jin; 'secdir'; [e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>;
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>;
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>;
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>;
> 'Adrian Farrel'; [e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>;
> [e-mail]<javascript:_e(%7B%7D,'cvml','[e-mail]');>
> *Subject:* Re: SECDIR review of
> draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
>
>
>
> Lizhong,
>
>
> Thanks for the quick reply.
>
> Hi Stephen,
>
> Thank you for the detail review. See my reply inline below.
>
>
>
> Regards
>
> Lizhong
>
>
>
> *From:* Stephen Kent [mailto:[e-mail]]
> *Sent:* Wednesday, April 16, 2014 5:05 AM
> *To:* secdir; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Adrian Farrel; [e-mail];
> [e-mail]
> *Subject:* SECDIR review of
> draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
>
>
>
> I 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.
>
>
>
> This is a very brief document, just 12 pages. The Abstract for this
> document, n its entirety, says: “In many existing Virtual Private LAN
> Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has
> been deployed without node redundancy, or with node redundancy in a single
> domain. This document describes a solution for inter-domain VPLS based on
> RFC 4762 with node and link redundancy in both domains.”
>
>
>
> Unfortunately, this confusing wording is typical of the writing in several
> areas of this document. The RFC Editor will need to work closely with the
> authors to make this document easier to read. Also, there are several
> instances of acronyms used without expansion (e.g., ASBR), making reading
> even harder.
>
> [Lizhong] I try to rephrase the abstract below to make it more clear. I
> will check again for the acronyms in detail. BTW, the ASBR has been
> expanded in section 3 line 193.
>
> The first use of ASBR is before then, I believe.
>
> [Lizhong] I see the first use of ASBR now. Will fix it.
>
>
>
>  In many existing RFC 4762 based Virtual Private LAN Service (VPLS)
> inter-domain deployments, the pseudowire (PW) connectivity has been
> deployed without node redundancy, or with node redundancy only in a single
> domain. That will take high risk of service interruption, since at least
> one domain will not have PW node redundancy.  This document describes a
> inter-domain VPLS solution which could provide PW node redundancy in both
> domains.
>
> I think it would be clearer to say:
>
> In many existing Virtual Private LAN Service (VPLS) inter-domain
> deployments (based on RFC 4762), pseudowire (PW) connectivity offers no
> node redundancy, or offers node redundancy only with a single domain. This
> deployment approach incurs a high risk of service interruption, since at
> least one domain will not offer PW node redundancy. This document describes
> an inter-domain VPLS solution that provides PW node redundancy across
> domains.
> [Lizhong] accepted, thank you.
>
>
>
>
>
> I like the fact that the document includes a “Motivation” section. It
> provided a good description of why a new approach to achieving redundancy
> in the VPLS context is needed.
>
>
>
> Section 5 ends with a curious statement:
>
>
>
> There are two PW redundancy modes defined in [RFC6870]:
>
> Independent mode and Master/Slave mode.  For the inter-
>
> domain four-PW scenario, it is required for PEs to ensure
>
> that the same mode is supported on the two ICCP peers in
>
> the same RG.  One method to ensure mode consistency is by
>
> manual operation.  Other methods are also possible and are
>
> out of the scope of this document.
>
>
>
> This says that two ASes have to ensure that both employ the same
> redundancy mode choice, notes that they can verify this manually, and that
> says there are other options to meet this requirement, but provides no
> description of the other options.  Not very useful.
>
>  [Lizhong] I think the text is OK. If you insist, I could remove.
>
> the text is not OK, because its states that there are multiple ways to
> ensure consistency, but  identifies only one.
> [Lizhong] hope you are OK with Adrian’s proposal.
>
>
>
> ...
>
> Section 5.3 describes switchover operation in the more complex four PW
> cases. It contains some RFC 2119 key words, but there are several instances
> of lowercase “should”. Is this intentional?
>
>  [Lizhong] I will check again, some is intentional, but some is not.
>
> If you are defining rules for how to achieve switchover, use of
> non-normative text is not
> of much value.
>
>  The Security Considerations section is brief, only 4 short paragraphs.
> It cites the Security Considerations sections of RFCs 4762 and 6870, plus
> the I-D (draft-ietf-pwe3-iccp) that forms the basis of part of the solution
> described here.
>
>
>
> RFC 4762 also contains a brief Security Considerations section, referring
> the reader to RFC 4111, the PPVPN Security Framework. That document
> discusses security in detail, although most of the discussion does not
> appear to be directly applicable to the redundancy mechanisms of this
> document.
>
>
>
> RFC 6870 is directly relevant. It contains a two-sentence Security
> Considerations section (almost a record for brevity?) with a lowercase
> “must” for emphasis? This section refers to RFC 4447, which contains a
> meaningful SC section (finally). That document mandates use of the TCP/MD5
> option for LDP. This is almost consistent with the second paragraph of the
> SC section in this document (which weakens this to a MAY), but not with the
> third paragraph (which seems to call for TCP-AO).
>
>  [Lizhong] RFC6870 SC is only valid for PW control plane. The second,
> third and fourth paragraph is described for ICCP control plane. I will make
> that clear in the text.
>
> OK.
>
>  ...
>
>
>
> [Lizhong] thank you for the comments. I tend to remove the conflict parts
> with [I-D.ietf-pwe3-iccp], and only describe the new security
> considerations. Please help to review the following text:
>
> Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control
> plane, [RFC4762] and [RFC6870] for PW control plane, this document will
> have additional security consideration for ICCP control plane.
>
>
>
> In this document, ICCP protocol is deployed between two PEs or ASBRs. The
> two PEs or ASBRs should only be connected by a well managed and highly
> monitored network. This should be ensured by the operator.
>
>
>
>