rfcused.bib

@misc{rfc1272,
  author="C. Mills and D. Hirsh and G.R. Ruth",
  title="{Internet Accounting: Background}",
  howpublished="RFC 1272 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="1272",
  pages="1--19",
  year=1991,
  month=nov,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc1272.txt",
  key="RFC 1272",
  abstract={This document provides background information for the ``Internet Accounting Architecture''.  This memo provides information for the Internet community.  It does not specify an Internet standard.},
  doi="10.17487/RFC1272",
  }

  
@misc{rfc7258,
  author="S. Farrell and H. Tschofenig",
  title="{Pervasive Monitoring Is an Attack}",
  howpublished="RFC 7258 (Best Current Practice)",
  series="Internet Request for Comments",
  type="RFC",
  number="7258",
  pages="1--6",
  year=2014,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7258.txt",
  key="RFC 7258",
  abstract={Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.},
  keywords="pervasive monitoring",
  doi="10.17487/RFC7258",
  }

@misc{rfc2722,
  author="N. Brownlee and C. Mills and G. Ruth",
  title="{Traffic Flow Measurement: Architecture}",
  howpublished="RFC 2722 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2722",
  pages="1--48",
  year=1999,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc2722.txt",
  key="RFC 2722",
  abstract={This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used with
in the Internet.  This memo provides information for the Internet community.},
  keywords="network, meters, data",
  doi="10.17487/RFC2722",
  }

@misc{rfc3954,
  author="B. Claise",
  title="{Cisco Systems NetFlow Services Export Version 9}",
  howpublished="RFC 3954 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3954",
  pages="1--33",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3954.txt",
  key="RFC 3954",
  abstract={This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs.  The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner.  A template defines a collection of fields, with corresponding descriptions of structure and semantics.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3954",
  }

@misc{rfc3917,
  author="J. Quittek and T. Zseby and B. Claise and S. Zander",
  title="{Requirements for IP Flow Information Export (IPFIX)}",
  howpublished="RFC 3917 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3917",
  pages="1--33",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3917.txt",
  key="RFC 3917",
  abstract={This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes.  This memo provides information for the Internet community.},
  keywords="ipfix, routers, measurment, middleboxes",
  doi="10.17487/RFC3917",
  }
  
@misc{rfc3955,
  author="S. Leinen",
  title="{Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)}",
  howpublished="RFC 3955 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3955",
  pages="1--23",
  year=2004,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3955.txt",
  key="RFC 3955",
  abstract={This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group.  The protocols are characterized and grouped in broad categories, and evaluated against specific requirements.  Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.  This memo provides information for the Internet community.},
  doi="10.17487/RFC3955",
  }

@misc{rfc5103,
  author="B. Trammell and E. Boschi",
  title="{Bidirectional Flow Export Using IP Flow Information Export (IPFIX)}",
  howpublished="RFC 5103 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5103",
  pages="1--24",
  year=2008,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5103.txt",
  key="RFC 5103",
  abstract={This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]},
  keywords="flow record, biflow",
  doi="10.17487/RFC5103",
  }

@misc{rfc5470,
  author="G. Sadasivan and N. Brownlee and B. Claise and J. Quittek",
  title="{Architecture for IP Flow Information Export}",
  howpublished="RFC 5470 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5470",
  pages="1--31",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6183",
url="https://www.rfc-editor.org/rfc/rfc5470.txt",
  key="RFC 5470",
  abstract={This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.  This memo provides information for the Internet community.},
  keywords="ipfix, ipfix device, ipfix collector",
  doi="10.17487/RFC5470",
  }

@misc{rfc5473,
  author="E. Boschi and L. Mark and B. Claise",
  title="{Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports}",
  howpublished="RFC 5473 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5473",
  pages="1--27",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5473.txt",
  key="RFC 5473",
  abstract={This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well. This method works by separating information common to several Flow Records from information specific to an individual Flow Record. Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. This memo provides information for the Internet community.},
  doi="10.17487/RFC5473",
  }

@misc{rfc5815,
  author="T. Dietz and A. Kobayashi and B. Claise and G. Muenz",
  title="{Definitions of Managed Objects for IP Flow Information Export}",
  howpublished="RFC 5815 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5815",
  pages="1--64",
  year=2010,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Obsoleted by RFC 6615",
url="https://www.rfc-editor.org/rfc/rfc5815.txt",
  key="RFC 5815",
  abstract={This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. [STANDARDS-TRACK]},
  keywords="Selector, Collector, Exporter, Sampling, Filtering, IPFIX, IPFIX-MIB, IPFIX-SELECTOR-MIB",
  doi="10.17487/RFC5815",
  }


@misc{rfc5982,
  author="A. Kobayashi and B. Claise",
  title="{IP Flow Information Export (IPFIX) Mediation: Problem Statement}",
  howpublished="RFC 5982 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="5982",
  pages="1--25",
  year=2010,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5982.txt",
  key="RFC 5982",
  abstract={Flow-based measurement is a popular method for various network monitoring usages.  The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP Flow Information Export (IPFIX) Mediation may help resolve.  This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIX Mediation applicability examples along with the problems.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  keywords="flow-based measurement",
  doi="10.17487/RFC5982",
  }



@misc{rfc6183,
  author="A. Kobayashi and B. Claise and G. Muenz and K. Ishibashi",
  title="{IP Flow Information Export (IPFIX) Mediation: Framework}",
  howpublished="RFC 6183 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6183",
  pages="1--29",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6183.txt",
  key="RFC 6183",
  abstract={This document describes a framework for IP Flow Information Export (IPFIX) Mediation.  This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components.  This document is not an Internet Standards Track specification; it is published for informational purposes.},
  doi="10.17487/RFC6183",
  }
  
@misc{rfc6235,
  author="E. Boschi and B. Trammell",
  title="{IP Flow Anonymization Support}",
  howpublished="RFC 6235 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="6235",
  pages="1--43",
  year=2011,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6235.txt",
  key="RFC 6235",
  abstract={This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol.  It categorizes common anonymization schemes and defines the parameters needed to describe them.  It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.  This document defines an Experimental Protocol for the Internet community.},
  keywords="IPFIX, flow information export, address anonymization, pseudonymization, data protection, privacy",
  doi="10.17487/RFC6235",
  }


@misc{rfc6728,
  author="G. Muenz and B. Claise and P. Aitken",
  title="{Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols}",
  howpublished="RFC 6728 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6728",
  pages="1--129",
  year=2012,
  month=oct,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6728.txt",
  key="RFC 6728",
  abstract={This document specifies a data model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) protocols.  It is for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant Monitoring Devices using the Network Configuration Protocol (NETCONF).  The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG.  The configuration data is encoded in Extensible Markup Language (XML). [STANDARDS-TRACK]},
  doi="10.17487/RFC6728",
  }
  
@misc{rfc7011,
  author="B. Claise and B. Trammell and P. Aitken",
  title="{Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information}",
  howpublished="RFC 7011 (Internet Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7011",
  pages="1--76",
  year=2013,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7011.txt",
  key="RFC 7011",
  abstract={This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.},
  doi="10.17487/RFC7011",
  }

@misc{rfc3176,
  author="P. Phaal and S. Panchen and N. McKee",
  title="{InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks}",
  howpublished="RFC 3176 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="3176",
  pages="1--31",
  year=2001,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3176.txt",
  key="RFC 3176",
  abstract={This memo defines InMon Corporation's sFlow system.  sFlow is a technology for monitoring traffic in data networks containing switches and routers.  In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector.  This memo provides information for the Internet community.},
  keywords="agent, data, MIB, management, information, base",
  doi="10.17487/RFC3176",
  }

@misc{rfc5477,
  author="T. Dietz and B. Claise and P. Aitken and F. Dressler and G. Carle",
  title="{Information Model for Packet Sampling Exports}",
  howpublished="RFC 5477 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5477",
  pages="1--46",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5477.txt",
  key="RFC 5477",
  abstract={This memo defines an information model for the Packet SAMPling (PSAMP) protocol.  It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.  As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]},
  keywords="psamp, ipfix, ip flow information export",
  doi="10.17487/RFC5477",
  }

@misc{rfc5475,
  author="T. Zseby and M. Molina and N. Duffield and S. Niccolini and F. Raspall",
  title="{Sampling and Filtering Techniques for IP Packet Selection}",
  howpublished="RFC 5475 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5475",
  pages="1--46",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5475.txt",
  key="RFC 5475",
  abstract={This document describes Sampling and Filtering techniques for IP packet selection.  It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes.  Furthermore, it shows how techniques can be combine
d to build more elaborate packet Selectors.  The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. [STANDARDS-TRACK]},
  keywords="psamp, metering process",
  doi="10.17487/RFC5475",
  }

@misc{rfc5476,
  author="B. Claise and A. Johnson and J. Quittek",
  title="{Packet Sampling (PSAMP) Protocol Specifications}",
  howpublished="RFC 5476 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5476",
  pages="1--45",
  year=2009,
  month=mar,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc5476.txt",
  key="RFC 5476",
  abstract={This document specifies the export of packet information from a Packet SAMPling (PSAMP) Exporting Process to a PSAMP Collecting Process.  For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP archi
tecture match very well, and the means provided by the IPFIX protocol are sufficient.  The document specifies in detail how the IPFIX protocol is used for PSAMP export of packet information. [STANDARDS-TRACK]},
  keywords="exporting process, collecting process, ipfix, ip flow information export",
  doi="10.17487/RFC5476",
  }


@misc{rfc6615,
  author="T. Dietz and A. Kobayashi and B. Claise and G. Muenz",
  title="{Definitions of Managed Objects for IP Flow Information Export}",
  howpublished="RFC 6615 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="6615",
  pages="1--65",
  year=2012,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6615.txt",
  key="RFC 6615",
  abstract={This document defines managed objects for IP Flow Information eXport (IPFIX).  These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors, including basic configuration information. [STANDARDS-TRACK]},
  keywords="IPFIX, MIB, Filtering, Sampling, Selection",
  doi="10.17487/RFC6615",
  }

@misc{rfc7125,
  author="B. Trammell and P. Aitken",
  title="{Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element}",
  howpublished="RFC 7125 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="7125",
  pages="1--6",
  year=2014,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7125.txt",
  key="RFC 7125",
  abstract={This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.},
  doi="10.17487/RFC7125",
  }

@misc{rfc8038,
  author="P. Aitken and B. Claise and S. B S and C. McDowall and J. Schoenwaelder",
  title="{Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol}",
  howpublished="RFC 8038 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="8038",
  pages="1--85",
  year=2017,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc8038.txt",
  key="RFC 8038",
  abstract={This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified. Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.},
  keywords="IPFIX, MIB, SNMP",
  doi="10.17487/RFC8038",
  }

@misc{rfc3540,
  author="N. Spring and D. Wetherall and D. Ely",
  title="{Robust Explicit Congestion Notification (ECN) Signaling with Nonces}",
  howpublished="RFC 3540 (Experimental)",
  series="Internet Request for Comments",
  type="RFC",
  number="3540",
  pages="1--13",
  year=2003,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3540.txt",
  key="RFC 3540",
  abstract={This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender.  It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.  The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header.  It is computationally efficient for both routers and hosts.  This memo defines an Experimental Protocol for the Internet community.},
  keywords="congestion control, tcp, traffic control protocol",
  doi="10.17487/RFC3540",
  }

@misc{rfc4366,
  author="S. Blake-Wilson and M. Nystrom and D. Hopwood and J. Mikkelsen and T. Wright",
  title="{Transport Layer Security (TLS) Extensions}",
  howpublished="RFC 4366 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4366",
  pages="1--30",
  year=2006,
  month=apr,
  note="Obsoleted by RFCs 5246, 6066, updated by RFC 5746",
  url="https://www.rfc-editor.org/rfc/rfc4366.txt",
  key="RFC 4366",
  abstract={This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS-TRACK]},
  keywords="transport, protocol, layer, authentication, privacy",
  doi="10.17487/RFC4366",
  }

@misc{rfc5246,
  author="T. Dierks and E. Rescorla",
  title="{The Transport Layer Security (TLS) Protocol Version 1.2}",
  howpublished="RFC 5246 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5246",
  pages="1--104",
  year=2008,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685, 7905, 7919",
url="https://www.rfc-editor.org/rfc/rfc5246.txt",
  key="RFC 5246",
  abstract={This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]},
  keywords="idea, international data algorithm, symmetric, transport protocol layer, authentication, privacy",
  doi="10.17487/RFC5246",
  }

@misc{rfc4253,
  author="T. Ylonen and C. Lonvick",
  title="{The Secure Shell (SSH) Transport Layer Protocol}",
  howpublished="RFC 4253 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4253",
  pages="1--32",
  year=2006,
  month=jan,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6668",
url="https://www.rfc-editor.org/rfc/rfc4253.txt",
  key="RFC 4253",
  abstract={The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]},
  keywords="remote login, encryption, server authentication, integrity protection, diffie-hellman key exchange, diffie hellman",
  doi="10.17487/RFC4253",
  }

@misc{rfc5280,
  author="D. Cooper and S. Santesson and S. Farrell and S. Boeyen and R. Housley and W. Polk",
  title="{Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile}",
  howpublished="RFC 5280 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5280",
  pages="1--151",
  year=2008,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 6818",
url="https://www.rfc-editor.org/rfc/rfc5280.txt",
  key="RFC 5280",
  abstract={This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]},
  keywords="X.509 v3, X.509 v2, certificate extensions",
  doi="10.17487/RFC5280",
  }

@misc{rfc5996,
  author="C. Kaufman and P. Hoffman and Y. Nir and P. Eronen",
  title="{Internet Key Exchange Protocol Version 2 (IKEv2)}",
  howpublished="RFC 5996 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="5996",
  pages="1--138",
  year=2010,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  note="Obsoleted by RFC 7296, updated by RFCs 5998, 6989",
  url="https://www.rfc-editor.org/rfc/rfc5996.txt",
  key="RFC 5996",
  abstract={This document describes version 2 of the Internet Key Exchange (IKE) protocol.  IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs).  This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. [STANDARDS-TRACK]},
  keywords="IKE, IPsec",
  doi="10.17487/RFC5996",
  }

@misc{rfc4303,
  author="S. Kent",
  title="{IP Encapsulating Security Payload (ESP)}",
  howpublished="RFC 4303 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4303",
  pages="1--44",
  year=2005,
  month=dec,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc4303.txt",
  key="RFC 4303",
  abstract={This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6.  ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality.  This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK]},
  keywords="ESP, ipsec, internet, protocol, encapsulating, security, ipv4, ipv6, ip security, confidentiality, authentication, integrity, anti-replay, ah, ip authentication header, ike, internet key exchange, ikev2, esn, extended sequence number",
  doi="10.17487/RFC4303",
  }

@misc{rfc6101,
  author="A. Freier and P. Karlton and P. Kocher",
  title="{The Secure Sockets Layer (SSL) Protocol Version 3.0}",
  howpublished="RFC 6101 (Historic)",
  series="Internet Request for Comments",
  type="RFC",
  number="6101",
  pages="1--67",
  year=2011,
  month=aug,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6101.txt",
  key="RFC 6101",
  abstract={This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows. This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. This document defines a Historic Document for the Internet community.},
  keywords="Transport layer security",
  doi="10.17487/RFC6101",
  }

@misc{rfc7230,
  author="R. Fielding and J. Reschke",
  title="{Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing}",
  howpublished="RFC 7230 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="7230",
  pages="1--89",
  year=2014,
  month=jun,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc7230.txt",
  key="RFC 7230",
  abstract={The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the ``http'' and ``https'' Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.},
  keywords="Hyptertext Transfer Protocol, HTTP, HTTP message format",
  doi="10.17487/RFC7230",
  }

  @misc{rfc3056,
  author="B. Carpenter and K. Moore",
  title="{Connection of IPv6 Domains via IPv4 Clouds}",
  howpublished="RFC 3056 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="3056",
  pages="1--23",
  year=2001,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc3056.txt",
  key="RFC 3056",
  abstract={This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. [STANDARDS-TRACK]},
  keywords="internet, protocol, wide area, network, unicast, point-to-point",
  doi="10.17487/RFC3056",
  }

@misc{rfc4861,
  author="T. Narten and E. Nordmark and W. Simpson and H. Soliman",
  title="{Neighbor Discovery for IP version 6 (IPv6)}",
  howpublished="RFC 4861 (Draft Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4861",
  pages="1--97",
  year=2007,
  month=sep,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028",
url="https://www.rfc-editor.org/rfc/rfc4861.txt",
  key="RFC 4861",
  abstract={This document specifies the Neighbor Discovery protocol for IP Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]},
  keywords="IPV6-ND, internet protocol, link-layer, link-layer address",
  doi="10.17487/RFC4861",
  }

@misc{rfc6169,
  author="S. Krishnan and D. Thaler and J. Hoagland",
  title="{Security Concerns with IP Tunneling}",
  howpublished="RFC 6169 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6169",
  pages="1--20",
  year=2011,
  month=apr,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6169.txt",
  key="RFC 6169",
  abstract={A number of security concerns with IP tunnels are documented in this memo.  The intended audience of this document includes network administrators and future protocol developers.  The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC6169",
  }

@misc{rfc4380,
  author="C. Huitema",
  title="{Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)}",
  howpublished="RFC 4380 (Proposed Standard)",
  series="Internet Request for Comments",
  type="RFC",
  number="4380",
  pages="1--53",
  year=2006,
  month=feb,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFCs 5991, 6081",
url="https://www.rfc-editor.org/rfc/rfc4380.txt",
  key="RFC 4380",
  abstract={We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service.  Running the service requires the help of ``Teredo servers'' and ``Teredo relays''.  The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the ``native'' IPv6 Internet.  The relays can also provide interoperability with hosts using other transition mechanisms such as ``6to4''. [STANDARDS-TRACK]},
  keywords="",
  doi="10.17487/RFC4380",
  }

@misc{rfc2330,
  author="V. Paxson and G. Almes and J. Mahdavi and M. Mathis",
  title="{Framework for IP Performance Metrics}",
  howpublished="RFC 2330 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="2330",
  pages="1--40",
  year=1998,
  month=may,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
    note="Updated by RFC 7312",
url="https://www.rfc-editor.org/rfc/rfc2330.txt",
  key="RFC 2330",
  abstract={The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort.  This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.},
  keywords="Internet, Protocol, measurement, statistics",
  doi="10.17487/RFC2330",
  }

@misc{rfc6985,
  author="A. Morton",
  title="{IMIX Genome: Specification of Variable Packet Sizes for Additional Testing}",
  howpublished="RFC 6985 (Informational)",
  series="Internet Request for Comments",
  type="RFC",
  number="6985",
  pages="1--10",
  year=2013,
  month=jul,
  issn="2070-1721",
  publisher="RFC Editor",
  institution="RFC Editor",
  organization="RFC Editor",
  address="Fremont, CA, USA",
  url="https://www.rfc-editor.org/rfc/rfc6985.txt",
  key="RFC 6985",
  abstract={Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested.  Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or ``IMIX'' (``Internet Mix'').  The mixture of sizes a networking device will encounter is highly variable and depends on many factors.  An IMIX suited for one networking device and deployment will not be appropriate for another.  However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests.  To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification.},
  keywords="Traffic, Pattern, Benchmarking",
  doi="10.17487/RFC6985",
  }