One document matched: draft-blake-ipv6-flow-label-nonce-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1948.xml">
<!ENTITY RFC2385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2385.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3493 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3493.xml">
<!ENTITY RFC3542 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3542.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC3697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3697.xml">
<!ENTITY RFC3828 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3828.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY RFC4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4443 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4953 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4953.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC5082 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY I-D.ietf-tcpm-icmp-attacks SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-icmp-attacks-03.xml">
<!ENTITY I-D.ietf-tcpm-tcpsecure SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-tcpsecure-10.xml">
<!ENTITY I-D.ietf-tsvwg-port-randomization SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-port-randomization-02.xml">
<!ENTITY I-D.ietf-tcpm-tcp-auth-opt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tcpm-tcp-auth-opt-01.xml">
<!ENTITY I-D.weaver-dnsext-comprehensive-resolver SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-weaver-dnsext-comprehensive-resolver-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="no" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-blake-ipv6-flow-label-nonce-00" ipr="full3978">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3978, noModification3978, noDerivatives3978
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Flow Label as Transport-Layer Nonce">
Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks</title>
<author fullname="Steven Blake" initials="S.B." surname="Blake">
<organization>Extreme Networks</organization>
<address>
<postal>
<street>Pamlico Building One, Suite 100</street>
<street>3306/08 E. NC Hwy 54</street>
<city>RTP</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 884 3211</phone>
<email>sblake@extremenetworks.com</email>
</address>
</author>
<date month="October" year="2008" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the
IETF. -->
<keyword>IPv6</keyword>
<keyword>flow label</keyword>
<keyword>TCP</keyword>
<keyword>nonce</keyword>
<!-- Keywords will be incorporated into HTML output files in a meta tag but
they have no effect on text or nroff output. If you submit your draft
to the RFC Editor, the keywords will be used for the search engine. -->
<abstract>
<t>
TCP and other transport-layer protocols are vulnerable to spoofing
attacks from off-path hosts. These attacks can be prevented through
the use of cryptographic authentication. However, it is difficult
to use cryptographic authentication in all circumstances.
A variety of obfuscation techniques -- such as initial sequence number
randomization and source port randomization -- increase the effort
required of an attacker to successfully spoof the packet header
fields which uniquely identify a transport connection. This
memo proposes the use of the IPv6 Flow Label field as a random,
per-connection nonce value, to add entropy to the set of packet
header fields used to identify a transport connection.
This mechanism is easily implementable, allows for incremental
deployment, and is fully compliant with the rules for Flow Label use
defined in RFC 3697.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Recent effort has been directed towards identifying and reducing the
vulnerability of TCP <xref target="RFC0793" /> to a variety of
"blind" spoofed packet injection attacks from hosts that are off-path
(i.e., not able to intercept communications between a pair of hosts)
<xref target="RFC4953" /><xref target="RFC5082" />
<xref target="I-D.ietf-tcpm-icmp-attacks" />
<xref target="I-D.ietf-tcpm-tcpsecure" />
<xref target="I-D.ietf-tsvwg-port-randomization" />. Off-path
spoofing attacks against TCP require an attacker to correctly guess
the 4-tuple of header fields <IP source address, TCP source port,
IP destination address, TCP destination port> uniquely identifying
a TCP connection, along with a valid (in-receive window) value for the
32-bit TCP sequence number. By correctly guessing values for these
fields, an attacker is then able to inject ACK, DATA, RST, of SYN segments
into a TCP connection, enabling throughput reduction,
data corruption, or connection termination. Similarly, by correctly
guessing values for these fields, an attacker is able to forge ICMP
messages to a sender, with similar negative consequences
<xref target="I-D.ietf-tcpm-icmp-attacks" />.
</t>
<t>
Increased use of long-duration connections by applications,
as well as faster access link speeds, increase the ability of
attackers to transmit a sufficient number of spoof packets to
successfully attack a connection, especially when either the
destination or source ports are easily guessable. Cryptographic
authentication mechanisms such as the TCP MD5 Authentication Option
<xref target="RFC2385" />, TCP Authentication Option
<xref target="I-D.ietf-tcpm-tcp-auth-opt" />, and IPsec
<xref target="RFC4301" /> can secure against these attacks,
as well as some on-path (man-in-the-middle) attacks. However, key
management and computational overhead makes the deployment of
cryptographic authentication prohibitively expensive in some
environments and applications.
</t>
<t>
Obfuscation techniques can be employed to increase the effort required
of an attacker. Initial sequence number randomization
<xref target="RFC1948" />
<xref target="I-D.ietf-tcpm-tcpsecure" /> can be implemented
by both the client (the host initiating a connection) and server.
For typical window sizes of approximately 32 Kbytes, this technique
forces an attacker to send approximately 57000 RST packets on
average to reset a connection <xref target="RFC4953" />.
Source port randomization
<xref target="I-D.ietf-tsvwg-port-randomization" /> can also be
implemented by a client to increase the number of guesses an attacker
must make to successfully attack a connection. This mechanism can
provide an additional ~15 bits of entropy (depending on
implementation). Source port randomization can also be used with
other transport protocols.
</t>
<t>
Both obfuscation schemes are compliant with
<xref target="RFC0793" />, and are incrementally deployable. Both
schemes used in combination introduce somewhat less than 32 bits of
entropy (~16 + ~15). However, as access link speeds (and
consequently, receive windows) increase in size, the amount of entropy
declines just as the number of spoof packets an attacker can generate
in a given interval increases.
<xref target="I-D.weaver-dnsext-comprehensive-resolver" />
argues that 40 bits of entropy is desirable to make off-path spoofing
attacks impractical.
</t>
<t>
IPv6 <xref target="RFC2460" /> includes a 20-bit Flow Label field,
which can be used by hosts to uniquely label a sequence of packets from
a host to a particular unicast, anycast, or multicast destination. The
tuple of <IP source address, IP destination address, Flow Label>
uniquely identify a particular flow during its lifetime plus a subsequent
quarantine period. Rules for the generation and usage of Flow
Label values are defined in <xref target="RFC3697" />. Because
transport-layer port fields may be located at a variable offset within
a packet due to IPv6 extension headers, or may be obscured due to
encryption, the Flow Label provides a common field in the IPv6 header
to facilitate flow classification in routers.
</t>
<t>
While originally intended to facilitate flow-specific packet handling
in routers (e.g., QoS, fast switching), the Flow Label can also be
used by hosts to uniquely label one or more transport connections.
An originating host can select a random Flow Label value at the beginning
of a connection, and continue to use it for the connection's duration.
The host (or hosts for multicast) at the other end of the connection
can record this Flow Label value, and use it as part of the connection
demultiplexing key, while also labeling response packets with the
same or different Flow Label value. The originating host can similarly
record the Flow Label value in response packets, and use it as part
of its connection demultiplexing key. In this way an additional 20 bits
of entropy is added to the set of header fields used to identify
a transport connection. When used in addition to source port
randomization, the total amount of entropy is approximately 34-35 bits.
When initial sequence number randomization is also used (i.e., in
TCP), the entropy is increased to > 40 bits, making off-path
snooping attacks impractical.
</t>
<t>
The concept of labeling transport connections to prevent off-path
spoofing attacks was proposed in <xref target="McGann05" />,
in the context of stateful firewalls. This scheme may be useful for
other transport protocols such as SCTP <xref target="RFC4960" />,
UDP <xref target="RFC0768" />, UDP-Lite <xref target="RFC3828" />,
DCCP <xref target="RFC4340" />, and RTP <xref target="RFC3550" />.
Host implementations in compliance with <xref target="RFC3697" />
which do not allocate multiple flows to a single transport connection,
will either label all packets in the connection with a Flow Label value
of 0, or some other constant. Therefore, this scheme is incrementally
deployable by either peer in a connection.
</t>
<t>
<xref target="Flow_Label_Rules" /> talks about additional requirements
on Flow Label generation. <xref target="TCP_Considerations" /> talks
about the use of this scheme with TCP.
<xref target="SCTP_Considerations" />
talks about the use of this scheme with SCTP.
<xref target="UDP_Considerations" /> talks about the use of this
scheme with UDP and UDP-Lite. <xref target="DCCP_Considerations" />
talks about the use of this scheme with DCCP.
<xref target="RTP_Considerations" /> talks about the use of this
scheme with RTP over UDP or DCCP.
</t>
</section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119" />.
</t>
</section>
<section anchor="Flow_Label_Rules" title="Additional Requirements on
Flow Label Value Generation and Use">
<t>
<xref target="RFC3697" /> specifies the rules governing use of the
IPv6 Flow Label. The primary requirements relevant to our purpose
are as follows (quoting directly):
</t>
<t>
<list style="symbols">
<t>
The Flow Label value set by the source MUST be delivered unchanged
to the destination node(s).
</t>
<t>
To enable Flow Label based classification, source nodes SHOULD
assign each unrelated transport connection and application data
stream to a new flow.
</t>
<t>
The source node SHOULD be able to select unused Flow Label values
for flows not requesting a specific value to be used.
</t>
<t>
A source node MUST ensure that it does not unintentionally reuse
Flow Label values it is currently using or has recently used
when creating new flows.
</t>
<t>
Flow Label values previously used with a specific pair of source
and destination addresses MUST NOT be assigned to new flows
with the same address pair within 120 seconds of the termination
of the previous flow.
</t>
<t>
The source node SHOULD provide the means for the applications
and transport protocols to specify quarantine periods longer than
the default 120 seconds for individual flows.
</t>
<t>
To avoid accidental Flow Label value reuse, the source node SHOULD
select the new Flow Label value in a well-defined sequence, (e.g.,
sequential or pseudo-random) and use an initial value that avoids
reuse of recently used Flow Label values each time the system
restarts. The initial value SHOULD be derived from a previous
value stored in non-volatile memory, or in the absence of such
history, a randomly generated initial value using techniques that
produce good randomness properties SHOULD be used.
</t>
</list>
</t>
<t>
We wish to use the Flow Label value as an unguessable nonce. Hence,
the following additional requirements are implied:
</t>
<t>
<list style="symbols">
<t>
Source hosts MUST assign each unrelated transport connection and
application data stream to a new flow.
</t>
<t>
Source hosts MUST be able to select unused Flow Label values
for flows not requesting a specific value to be used. The selected
Flow Label value must remain constant for the duration of the flow.
</t>
<t>
The Flow Label value MUST be practically unguessable, in a manner
similar to the TCP source port or initial sequence number when they are
randomized. A random number generator with good randomness properties
(i.e., uniformly distributed) as specified in
<xref target="RFC4086" /> MUST be used to generate Flow Label values
not explicitly requested by an application.
</t>
<t>
Flow Label state for a transport connection or application data stream
must be cleaned-up by the destination host(s) as part of the
transport connection/application data stream state clean-up.
</t>
<t>
Flow Label values previously used with a specific pair of source
and destination addresses MUST NOT be assigned to new flows
with the same address pair within X seconds of the termination
of the previous flow, where X is the maximum of either 120 seconds,
or the duration for which transport connection state might linger at
a destination host after traffic flow has ceased (e.g., TIME-WAIT
state in TCP).
</t>
</list>
</t>
<t>
For this application of the Flow Label field, it would not pose a
problem if multiple flows from a source host in unrelated transport
connections/application data streams coincidentally shared the
same Flow Label value, as long as the other previous requirements are
adhered to. However, the prohibition in <xref target="RFC3697" />
against simultaneous reuse of Flow Label values MUST be observed.
</t>
<t>
Transport-specific requirements on Flow Label use are provided in
the subsequent sections. However, as a general requirement, if a
packet is received on a transport connection/application data stream
with an unexpected Flow Label value, the packet MUST be silently
discarded. If excessive Flow Label errors are received, the event
SHOULD be logged.
</t>
<t>
ICMPv6 error messages contain the IPv6 header of the packet triggering
the error <xref target="RFC4443" />. A host receiving an ICMPv6
error message can validate the Flow Label value in the message payload
to protect against ICMPv6 spoofing attacks
<xref target="I-D.ietf-tcpm-icmp-attacks" />.
</t>
<t>
Use of the Flow Label value as an unguessable nonce is incrementally
deployable, whether a source host fails to support setting the
Flow Label to a non-zero value, or a destination host fails to
check its value. However, a Flow Label value of 0 is easily guessable,
so resistance to spoofing attacks is not improved. Hosts SHOULD NOT
rely on the mechanisms defined in this document when operating in
high-threat environments.
</t>
<t>
The additional requirements given here for Flow Label generation and
use are not in conflict with the requirements in
<xref target="RFC3697" />. Therefore, additional applications of the
Flow Label field (e.g., special QoS handling) can be applied
simultaneously with the use of the Flow Label field as a transport-layer
nonce.
</t>
</section>
<section anchor="TCP_Considerations" title="TCP Considerations">
<t>
Unidirectional traffic in a TCP connection is assumed to constitute a
single flow, and hence MUST be assigned a unique Flow Label value by the
source host. A single TCP connection MUST NOT be treated by a source
host as consisting of multiple flows. Given the Flow Label value's
additional use as a packet classification field in routers (for QoS or
other purposes), there is no compelling reason to sub-divide traffic
within a TCP connection for classification purposes.
</t>
<t>
For this application of the Flow Label field, it would not pose a
problem if multiple TCP connections from a source host to a particular
destination host reused the same Flow Label value. However, because
of the additional uses of the Flow Label field, a host MUST
NOT assign the same Flow Label value to multiple TCP connections.
It is not assumed that both directions of traffic flow in a TCP
connection must share the same Flow Label value, nor it is prohibited.
</t>
<t>
A host originating a TCP connection (client) selects a unique Flow Label
value for the connection, which it stores as the OUTGOING_FLOW_ID in
its Transport Control Block (TCB) for this connection. This Flow
Label value is included in the first (and subsequent) SYN packet(s)
sent to the destination host (server). The server receiving the first
SYN packet records the Flow Label value in its TCB for this connection
as the INCOMING_FLOW_ID. The server then selects a unique Flow Label
value for the connection, which it stores as the OUTGOING_FLOW_ID in the
connection's TCB. It includes this Flow Label value in the first
(and subsequent) SYN-ACK packet(s) sent to the client. The client
receiving the SYN-ACK packet from the server records the Flow Label
value in its TCB for this connection as the INCOMING_FLOW_ID. It
sends all additional packets of the connection to the server using
OUTGOING_FLOW_ID, and checks all incoming packets of the connection
from the server to ensure that they include INCOMING_FLOW_ID. The
server performs identical processing. Any packets received with
a Flow Label value that does not match INCOMING_FLOW_ID MUST be silently
discarded. If a significant number of such packets are received, the
event SHOULD be logged.
</t>
<t>
When a server implements a SYN cache and/or SYN cookies, the Flow Label
value used in the SYN-ACK packet MUST be consistent with the Flow
Label value used in subsequent packets <xref target="RFC4987" />.
For the SYN cache case, this can be handled easily by including
INCOMING_FLOW_ID and OUTGOING_FLOW_ID as part of each cache entry.
For SYN cookies, one approach to satisfying the requirement without
storing state is to use the Flow Label value received in the SYN
(INCOMING_FLOW_ID) as the Flow Label value in the SYN-ACK
(OUTGOING_FLOW_ID). This approach leaves a window of vulnerability
to spoofing before the connection is established.
</t>
<t>
<xref target="RFC0793" /> specifies that a connection should remain
in TIME_WAIT state for 2 * MSL (Maximum Segment Lifetime) seconds.
<xref target="RFC0793" /> specifies MSL as 120 seconds, although
many implementations default to a lower value. The Flow Label value
quarantine period MUST be no less than the maximum of either 2 * MSL
for the connection, or 120 seconds.
</t>
<t>
The specified behavior at the client and server will work even if either
the client or server fails to set a non-zero outgoing Flow Label value,
or check the incoming Flow Label value. However, resistance to
spoofing attacks is not improved. Further, no mechanism for detecting
whether a peer is supporting the Flow Label nonce is defined.
Therefore, some cryptographic authentication mechanism SHOULD BE used
when operating in a high-threat environment
<xref target="RFC2385" /><xref target="I-D.ietf-tcpm-tcp-auth-opt" />
<xref target="RFC4301" />.
</t>
</section>
<section anchor="UDP_Considerations" title="UDP Considerations">
<t>
UDP is a connectionless protocol, which is also vulnerable to
spoofing attacks. Source port randomization can be utilized with UDP,
but UDP does not have sequence numbers, so it is arguably more vulnerable
than TCP with source port and initial sequence number randomization.
With the exception of connected sockets, UDP/IP stacks (usually) do
not maintain sufficient state to maintain INCOMING_FLOW_ID or
OUTGOING_FLOW_ID values for each application data stream between a
source host and a destination host or multicast group. Therefore,
Flow Label generation and validation must happen at the application
layer.
</t>
<t>
For purposes of discussion, we define a UDP connection as a flow
of traffic matching the tuple <IP source address, UDP source port,
IP destination/group address, UDP destination port>. Note that
a UDP connection consists of unidirectional traffic flow between a
pair of hosts, or between a host and the receivers of a multicast
group. UDP applications SHOULD assign each connection to a unique
flow, and hence SHOULD assign each connection a unique Flow Label
value. One exception is where multiple application data streams are
multiplexed onto the same address/port pairs. In this case UDP
applications MUST assign application data streams to unique flows
(as appropriate for the intended QoS or other handling), and MUST use
application-layer demultiplexing to associate incoming data streams
with flows. Maintenance of INCOMING_FLOW_ID and OUTGOING_FLOW_ID
values for each flow MUST be provided by the application. Note that
an alternative to multiplexing multiple application data streams
onto the same address/port pair is to utilize different source and/or
destination port values for each data stream.
</t>
<t>
There is no standard sockets API for either setting the Flow Label value
in outgoing packets, nor retrieving it in incoming packets
<xref target="RFC3493" /><xref target="RFC3542" />. There is also
no standard sockets API for specifying that a non-zero Flow Label value
be used in outgoing packets. Therefore the requirements above
cannot be satisfied, except where a non-standard API is available,
or the functionality is provided automatically within the UDP/IP stack.
It would be worthwhile to define a standard sockets API for Flow Label
management.
</t>
<t>
One application where the use of the Flow Label as a nonce might
be beneficial is in protection against DNS cache poisoning attacks
<xref target="I-D.weaver-dnsext-comprehensive-resolver" />. If DNS
clients assign each DNS transaction to a unique flow, and if DNS servers
sends responses with an outgoing Flow Label value equal to the incoming
Flow Label value received in the request, then the client can validate
with high-probability that the request was generated by the targeted
server, since the UDP source port, DNS transaction ID, and Flow Label
provide approximately 51 bits of entropy.
</t>
<t>
Use of the Flow Label with UDP-Lite will be discussed in a subsequent
revision of this document.
</t>
<!--
- Is there a UDP Security Considerations document?
-->
</section>
<section anchor="SCTP_Considerations" title="SCTP Considerations">
<t>
Use of the Flow Label with SCTP will be discussed in a subsequent
revision of this document.
</t>
<!--
- Discuss issues regarding whether the same flow label value can be
used for multiple connections to a destination.
- Discuss why it doesn't make sense to use multiple flow label values
for a single SCTP connection.
- Should the same Flow Label value be used when the sending address
changes (multi-homing feature)?
- Are there sub-flows in SCTP that would benefit from different
Flow Label values?
- Is there a SCTP Security Considerations document?
- RFC 5062
-->
</section>
<section anchor="DCCP_Considerations" title="DCCP Considerations">
<t>
Use of the Flow Label with DCCP will be discussed in a subsequent
revision of this document.
</t>
<!--
- Elaborate on the UDP section if necessary.
- Is there a DCCP Security Considerations document?
-->
</section>
<section anchor="RTP_Considerations" title="RTP Considerations">
<t>
Use of the Flow Label with RTP applications will be discussed in a
subsequent revision of this document.
</t>
<!--
- May eliminate this and cover it in the UDP or DCCP conderations.
- Elaborate on the UDP/DCCP sections as necessary.
- Are there notions of sub-flows within an RTP stream?
- Is there a RTP Security Considerations Document?
- see draft-ietf-avt-srtp-not-mandatory-00
-->
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
<xref target="McGann05" /> proves that the concept of using the
Flow Label as a transport-layer nonce pre-dates this document
(although the author only discovered this paper after the writing of
this document commenced). If others are aware of when and where
this concept might have been discussed previously, please contact
the author.
</t>
<t>
This document was produced using the xml2rfc tool
<xref target="RFC2629" />.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
This memo includes no request to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
All drafts are required to have a security considerations section.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC2119;
&RFC1948;
&RFC2460;
&RFC3550;
&RFC3697;
&RFC3828;
&RFC4086;
&RFC4340;
&RFC4443;
&RFC4960;
</references>
<references title="Informative References">
&RFC2385;
&RFC2629;
&RFC3493;
&RFC3542;
&RFC4301;
&RFC4953;
&RFC4987;
&RFC5082;
&I-D.ietf-tcpm-icmp-attacks;
&I-D.ietf-tcpm-tcpsecure;
&I-D.ietf-tsvwg-port-randomization;
&I-D.ietf-tcpm-tcp-auth-opt;
&I-D.weaver-dnsext-comprehensive-resolver;
<reference anchor="McGann05">
<front>
<title>Flow Label Filtering Feasibility</title>
<author initials='O.' surname='McGann' fullname='Orla McGann'>
<organization>HEAnet, Ltd.</organization>
</author>
<author initials='D.' surname='Malone' fullname='David Malone'>
<organization>The Hamilton Institute</organization>
</author>
<date month='December' year='2005' />
</front>
<seriesInfo name='European Conference on'
value='Computer Network Defence'/>
</reference>
</references>
</back>
</rfc>
<!-- Change Log
-->
| PAFTECH AB 2003-2026 | 2026-04-21 18:02:55 |