Last Call Review of draft-ietf-l2vpn-vpls-inter-domain-redundancy-05
review-ietf-l2vpn-vpls-inter-domain-redundancy-05-secdir-lc-kent-2014-04-17-00

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.




 




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.




 




Sections
        5.1.1-3 provide switchover rules for redundancy. Sections 5.1.1
        and 5.1.2 both
        include SHOULDs, but 5.1.3 contains no analogous RFC 2119 key
        words. This lack
        of parallelism is confusing.




 




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?




 




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




 




The
        SC section of 

draft-ietf-pwe3-iccp
        calls
        for use of TCP-AO (SHOULD), which reinforces the references in
        the third
        paragraph of this SC, but is inconsistent with the second
        paragraph!




 




The
        second paragraph in the SC section 

 

of
        this document uses a lowercase “could.” I wonder if this should
        be uppercase,
        as per RFC 6919 

J

? The next paragraph directs implementers to three RFCs
        (6941, 6952,
        and 5925), and specifically cites TCP-AO. This is confusing
        guidance, given the
        MAY for TCP/MD5 use with LDP in the previous paragraph. Merely
        calling
        attention to these docs is not useful guidance. 




 




The
        final paragraph of this section contains two obvious spelling
        errors in the
        first sentence:




 




The 

activitiy


        on the inter-domain and intra-domain




pseudowire may cause security
        threats or be
        exploited to 




create denial of service 

attackes

.




 




Even
        if the spelling errors are corrected, it is not clear what value
        this sentence
        adds. The remaining two sentences of the paragraph provide
        useful guidance, and
        thus should be retained.




 




My
bottom
      line: the SC section of this document is internally inconsistent
      and
      conflicts with SC guidance in several of the other docs cited in
      the SC section.
      This needs