Skip to main content

Last Call Review of draft-ietf-ipfix-mediation-protocol-07
review-ietf-ipfix-mediation-protocol-07-secdir-lc-kent-2013-10-24-00

Request Review of draft-ietf-ipfix-mediation-protocol
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-10-25
Requested 2013-10-17
Authors Benoît Claise , Atsushi Kobayashi , Brian Trammell
I-D last updated 2013-10-24
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Genart Telechat review of -08 by Meral Shirazipour (diff)
Secdir Last Call review of -07 by Stephen Kent (diff)
Opsdir Telechat review of -07 by Jürgen Schönwälder (diff)
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-ipfix-mediation-protocol by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Ready
Completed 2013-10-24
review-ietf-ipfix-mediation-protocol-07-secdir-lc-kent-2013-10-24-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.




 




The document
        describes how
        IPFIX (IP Flow Information Export) operates in the context of
        IPFIX
        “mediators.” In the IPFIX context, a mediator is an entity that
        processes data
        received from an “exporter” (e.g., a router), before passing the
        data to a
        consuming entity (e.g., a network management system), in theb
        IPFIX format. A
        mediator can perform various types of processing on IPFIX data,
        e.g.,
        aggregation, correlation, and anonymizing, in addition to format
        conversion.




 




The security
        considerations section in this document is brief, just three
        paragraphs. It
        cites the corresponding sections of RFC 7011 (the base IPFIX
        specification) and
        RFC 5655 (the IPFIX file specification). It 

also addresses two considerations that
        the authors view as specific to the mediator context.
        Specifically, the authors
        note that a mediator is an MITM, and thus the confidentiality
        and integrity of
        the IP flow data that traverses a mediator can be affected. The
        authors note
        although one can use certificates to identify upstream source of
        processing
        entities (supported by data elements defined in RFC 5655), this
        does not
        provide secure, end-to-end assertions about the upstream
        entities.

  

Both of these
        considerations are accurate an
        well-described here.





        I briefly examined the security
        considerations sections of the cited RFCs. I was impressed by
        the scope of the
        security discussion in RFC 7011; it mandates support for TLS
        (v1.1 or later)
        and DTLS, and calls for (SHOULD) use of certificates in support
        of mutual
        authentication of IPFIX entities. There is even a DoS
        discussion. Good job!








        The
        security considerations section of RFC 5655 is shorter, but also
        appropriate
        for its context. 5655 calls for (SHOULD) use of CMS (vs. TLS and
        DTLS) for
        IPFIX files. It also examines additional security issues
        relevant to the files.
        (I have one minor quibble with the text here; it refers to using
        TLS to “sign”
        data, which is not correct. The integrity and authentication
        mechanisms offered
        by TLS do not include signatures.) Citing the security
        considerations sections
        of these other RFcs was appropriate. 







 




I wish more
        I-Ds did as
        good a job as this one (and its predecessor RFCs) with respect
        to security
        considerations sections.