Skip to main content

Last Call Review of draft-ietf-mpls-forwarding-06
review-ietf-mpls-forwarding-06-secdir-lc-kent-2014-02-06-00

Request Review of draft-ietf-mpls-forwarding
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-02-12
Requested 2014-01-30
Authors Curtis Villamizar , Kireeti Kompella , Shane Amante , Andrew G. Malis , Carlos Pignataro
I-D last updated 2014-02-06
Completed reviews Genart Last Call review of -06 by Joel M. Halpern (diff)
Secdir Last Call review of -06 by Stephen Kent (diff)
Secdir Telechat review of -08 by Stephen Kent (diff)
Opsdir Last Call review of -06 by Al Morton (diff)
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-mpls-forwarding by Security Area Directorate Assigned
Reviewed revision 06 (document currently at 09)
Result Has nits
Completed 2014-02-06
review-ietf-mpls-forwarding-06-secdir-lc-kent-2014-02-06-00


 




SECDIR
        review of 

draft-ietf-mpls-forwarding-06




 




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, WG chairs and ADs
        should treat 

these
        comments just like any other last call comments.




 




This document

 

is a candidate Informational
        RFC. It cites
        about 25 MPLS RFCs (normatively) as a basis for guidelines for
        MPLS router
        implementers and network providers, with respect to forwarding
        of MPLS traffic.
        




 




The Security
        Considerations Section is very brief. It correctly states that
        it is a review
        of forwarding behavior specified in numerous MPLS RFCs, and thus
        introduces no
        new security requirements. It makes specific reference to
        Section 4.6, which
        specifies (at a high level) some tests for DoS susceptibility in
        MPLS routers.
        The paragraph that includes this reference should be extended to
        include
        pointers to Section 2.6.1 (which discusses DoS concerns), and to
        Section 3.6 (which
        includes a list of DoS protection questions to be posed to
        suppliers). 




 




It might be
        nice to
        summarize the security considerations recommendations from the
        MPLS RFCs that
        are normative references in this document. Since this document
        is a summary of
        forwarding-relevant requirements from these documents, plus
        practical advice,
        such a summary would be useful here, and fitting.




 




Some
        suggested edits:




 




2.1.2.

  

MPLS Differentiated
        Services




 




   

[RFC2474] deprecates the
        IP Type of Service
        (TOS) and IP Precedence




   

(Prec) fields and replaces
        them with the
        Differentiated Services




   

Field more commonly known
        as the
        Differentiated Services Code Point




   

(DSCP) field.

  

[RFC2475] defines the
        Differentiated Services




   

architecture, which in
        other 

forum

 is often called a
        Quality of




   

Service (QoS)
        architecture.




 




Either use
        “fora” (correct
        Latin) or “forums” (common English)




 




2.1.8.1.

  

Pseudowire Sequence Number




 




   

Pseudowire (PW) sequence
        number support is
        most important for PW




   

payload types with a high
        expectation of
        lossless and/or in-order




   

delivery.

 
        

Identifying lost PW packets 

and
          exact amount


        of lost




   

payload is critical for PW
        services which
        maintain bit timing, such




   

as Time Division
        Multiplexing (TDM) services
        since these services




   

MUST compensate lost
        payload on a
        bit-for-bit basis.




 




“the exact
        amount”




 




 




With PW
        services which
        maintain bit timing, packets that have been




   

received out of order also
        MUST be
        identified and 

may

 be either re-




   

ordered or dropped.




 




Uppercase
        MAY?




 




The term
        “microflow” does
        not appear to be defined anywhere in this document, but is used
        a number of
        times. I suggest including the definition from RFC 2474.




 




2.4.4.

  

MPLS Entropy Label




 




   

The MPLS entropy label
        simplifies flow group
        identification [RFC6790] 

at midpoint
          LSR

.

  

Prior to
        the MPLS entropy 

label midpoint LSR


        needed 

 

to inspect the
        entire label stack and often
        the IP headers to provide …




 




Missing an
        article, or
        make LSR plural.




 




Many service
        providers
        consider it a hard requirement




that use of
        UDP and TCP
        ports can be disabled.

  

Therefore
        there is
        a 

stong

 incentive for
        implementations to provide
        both options.




 




“strong”




 




Cryptographic
        authentication can 

is

 some
        circumstances be
        subject




to DoS attack
        by
        overwhelming the capacity of the decryption with




a high volume
        of malicious
        traffic.




 




“in”