One document matched: draft-blake-ipv6-flow-label-nonce-02.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 RFC1948 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1948.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.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 RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.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 RFC3704 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.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 RFC5015 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5015.xml">
<!ENTITY RFC5082 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5082.xml">
<!ENTITY RFC5294 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5294.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">
<!ENTITY I-D.mrw-behave-nat66 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrw-behave-nat66.xml">
<!ENTITY I-D.rja-ilnp-intro SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rja-ilnp-intro.xml">
<!ENTITY I-D.van-beijnum-1e-mp-tcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.van-beijnum-1e-mp-tcp.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-02" ipr="pre5378Trust200902">
<!-- 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="2009" />
<!-- 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 guess 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">
<section title="TCP's Vulnerability to Blind Spoofing Attacks">
<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, or SYN
segments into a TCP connection, enabling throughput reduction,
data corruption, or connection termination with a single correctly
constructed packet. Similarly, by correctly guessing values for these
fields, an attacker is able to forge ICMP messages to a host, 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 for some applications.
</t>
<t>
Network ingress filtering of IP source addresses has been widely
deployed at network boundaries, significantly reducing the set of
networks that a particular host can inject spoof packets into
<xref target="RFC2827" /><xref target="RFC3704" />. But network
ingress filtering is not universally deployed, leaving many networks
vulnerable to spoofed packet attacks (including the attacker's network).
Note also that network ingress filtering typically provides no
protection against ICMP spoofing attacks, since the attacker does not
need to spoof the IP source address in the ICMP packet header (only
the IP destination address in the ICMP message payload).
</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 approximately 32 bits of entropy (~17 + ~15) with typical
window sizes in use today. 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. Therefore, the margin of protection
provided by these obfuscation mechanisms will decrease over time.
</t>
</section>
<section title="IPv6 Flow Label">
<t>
IPv6 <xref target="RFC2460" /> includes a 20-bit Flow Label field,
which can be used by hosts to uniquely label a uni-directional 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> is intended to 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 fixed 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 may 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 a 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 TCP initial sequence number randomization is also used (i.e., in
TCP), the entropy is increased to > 40 bits (even for large windows),
making off-path snooping attacks impractical.
</t>
<t>
The Flow Label field is not included in the pseudo header checksum of
any of the standard transport protocols. Corruption of the Flow Label
value (that is not detected by any link-layer checksum) will be
interpreted by the receiving host as evidence of an attack (rather than
otherwise being ignored). The recommended response by the receiving
host (to silently discard the packet) is the same as in the case of
a packet with a checksum error.
</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 with some other constant. Therefore, this scheme is
incrementally deployable by either peer in a connection. By introducing
an incentive for hosts to begin utilizing the Flow Label, its utility
for other network applications (e.g., as part of the ECMP load balancing
key in routers) is improved.
</t>
<t>
<xref target="Flow_Label_Rules" /> specifies additional requirements
on Flow Label generation. <xref target="TCP_Considerations" /> describes
the use of this scheme with TCP.
<xref target="UDP_Considerations" /> describes the use of this
scheme with UDP and UDP-Lite.
<xref target="SCTP_Considerations" /> describes the use of this scheme
with SCTP.
<xref target="DCCP_Considerations" /> describes the use of this scheme
with DCCP.
<xref target="RTP_Considerations" /> describes the use of this
scheme with RTP over UDP or DCCP.
<xref target="NAT_Considerations" /> describes the implications of IPv6
network address translation with respect to this scheme.
<xref target="Sub-flow_Considerations" /> describes an alternative
receiver behavior which allows support for multiple sub-flows within
a transport connection.
</t>
</section>
</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>
A Flow Label of zero is used to indicate packets not part of any flow.
</t>
<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 (i.e., with a non-zero Flow Label
value).
</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 hosts 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 host after traffic flow has ceased (e.g., TIME-WAIT
state in TCP).
</t>
</list>
</t>
<t>
We assume that the requirement of <xref target="RFC3697" />
that "The Flow Label value set by the source MUST be delivered unchanged
to the destination node(s)" applies also when the Flow Label value is 0.
By implication we assume that intermediate nodes are not allowed to
assign a packet to a flow, whether or not the source node did so.
</t>
<t>
For this particular application of the Flow Label field, no problem
would be posed 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.
Any application request to assign a specific Flow Label value already
in use by another flow MUST be rejected.
</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, this 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., for special QoS handling, load balancing, etc.)
can be applied simultaneously with the use of the Flow Label field as a
transport-layer nonce, so long as an additional application does not
limit the permissible values of the Flow Label in any way which violates
the requirement that the value be unpredictable.
</t>
</section>
<section anchor="TCP_Considerations" title="TCP Considerations">
<t>
Uni-directional 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; either explicitly by the application or automatically by
the host's TCP/IP stack. 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 into multiple flows 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 (whether to one
or a multiple of destination hosts) 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. Both directions of traffic flow in a TCP connection
are not required to share the same Flow Label value, nor are they
prohibited from doing so.
</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. The Flow Label
selection algorithm can run simultaneously with TCP source port
and initial sequence number selection (e.g., by generating a single
random variable and assigning bit-ranges within it to each field).
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, this
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="McGann05" />
<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 derive the Flow Label value from a hash of the
the connection 4-tuple plus a random secret <xref target="McGann05" />.
Another approach 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). When the connection is established, the same
Flow Label value will be used in both directions of traffic.
This approach leaves a small 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, although
receipt of an initial packet with a non-zero Flow Label suggests that
the sending host may support this specification. 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. The level of vulnerability is specific to each
application-layer protocol running over UDP. 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
SOCk_DGRAM 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 uni-directional traffic flow between a
pair of hosts, or between a host and the receivers of a multicast
group. UDP applications MUST assign each connection to a unique
flow, and hence MUST 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. Applications
MUST check the Flow Label value of a received packet against
INCOMING_FLOW_ID for the associated flow, and MUST silently discard the
packet if the values do not match. If a significant number of such
packets are received, this event SHOULD be logged. 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>
Note that the Flow Label nonce does not provide any additional
protection for multicast applications. Source address spoofing is
usually prevented through use of reverse path forwarding (RPF) checks
as part of the multicast forwarding procedure, and in cases where RPF is
not in use (e.g., in BIDIR-PIM)
<xref target="RFC5015" /><xref target="RFC5294" />,
the attacker can learn the Flow Label values used by one or more senders
by joining the multicast group.
</t>
<t>
There is no standard, widely implemented 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 would
be beneficial is in protection against blind DNS cache poisoning
attacks <xref target="I-D.weaver-dnsext-comprehensive-resolver" />.
If DNS queries are each assigned a unique Flow Label value, and if DNS
servers send 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 together provide approximately 51 bits of entropy.
</t>
<t>
The procedures described above for UDP are equally applicable for
UDP-Lite <xref target="RFC3828" />.
</t>
</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>
<!--
DCCP is a connection-oriented transport protocol which does not
attempt to provide reliable in-order delivery of packets
<xref target="RFC4340" />. DCCP incorporates a larger sequence
number space than TCP, and stronger sequence number checking rules,
making it more difficult for an attacker to correctly guess a
valid sequence numbers in a spoof packet. DCCP also incorporates
the Init Cookie option to protect against SYN-flood-like attacks.
</t>
<t>
Unidirectional traffic in a DCCP connection is assumed to constitute
a single flow, and hence MUST be assigned a unique Flo Label value
by the source host.
- 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="NAT_Considerations" title="NAT Considerations">
<t>
IPv6 network address translators (NATs) are not common, and there is
no widely accepted definition for their correct behavior. One proposal
<xref target="I-D.mrw-behave-nat66" /> assumes that the NAT66 device
performs stateless one-to-one address translation between internal and
external addresses. In this scenario there is no address multiplexing,
and the Flow Label values SHOULD NOT be changed by the NAT66 device.
The same is true for protocols permitting locator translation, such as
ILNP <xref target="I-D.rja-ilnp-intro" />.
</t>
<t>
An IPv6 NAT device performing address multiplexing (e.g., a NAPT) must
obey the same Flow Label rules in <xref target="Flow_Label_Rules" /> as
any host; i.e., no two independent flows originating from the same
translated address may share the same Flow Label value. Therefore, such
a NAT device MUST modify the Flow Label value of any arriving flow of
packets to ensure that it does not collide with any currently in-use
Flow Label values originating from the same translated address.
</t>
</section>
<section anchor="Sub-flow_Considerations" title="Support for Transport
Connection Sub-Flows">
<t>
The procedures described in this specification mandate that each
transport connection must be assigned to a new flow with a unique
Flow Label value. This does not permit the use of multiple IPv6 flows
within a TCP connection. Such a capability would be useful for some
approaches to TCP multi-path, such as
<xref target="I-D.van-beijnum-1e-mp-tcp" />, which use the same address/port
pairs for all sub-flows of the connection, and which would like to utilize
the IPv6 Flow Label as part of the ECMP load balancing key in routers.
</t>
<t>
To enable the instantiation of multiple IPv6 flows per-transport
connection, while retaining the benefits of the Flow Label as a nonce,
we propose the following alternative procedures:
<list style="symbols">
<t>
Source hosts MUST assign each flow within a single transport connection
with an OUTGOING_FLOW_ID sharing the same value for the
least-significant 16 bits.
</t>
<t>
Destination hosts check on the least-significant 16 bits of
INCOMING_FLOW_ID for each transport connection.
</t>
</list>
</t>
<t>
This modified procedure does not significantly weaken the overall strenght
of Flow Label nonce mechanism (when combined with other obfuscation
techniques), while enabling up to 16 sub-flows per-transport connection).
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
<xref target="McGann05" /> describes the use of the
Flow Label as a transport-layer nonce. If others are aware of when
and where this concept might have been discussed previously, please
contact the author.
</t>
<t>
The author would like to thank Brian Carpenter, Gorry Fairhurst,
Joe Touch, Bob Briscoe, Iljitsch van Beijnum, and Marcelo Bagnulo Braun
for their valuable feedback.
</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>
This memo describes the use of the IPv6 Flow Label as a
transport-layer nonce to help protect transport connections and
application data streams from blind spoofed packet injection
attacks. Blind spoofed packet injection attacks have been described
in several publications, and are well known to the community. This
memo addresses the use of this mechanism with different transport
protocols. This mechanism is only applicable for hosts
communicating via the IPv6 protocol. This mechanism does not
provide protection for any on-path (man-in-the-middle attacks);
therefore, additional security mechanisms should be used in high threat
environments.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC0768;
&RFC0793;
&RFC2119;
&RFC2460;
&RFC3550;
&RFC3697;
&RFC3828;
&RFC4086;
&RFC4340;
&RFC4443;
&RFC4960;
</references>
<references title="Informative References">
&RFC1948;
&RFC2385;
&RFC2629;
&RFC2827;
&RFC3493;
&RFC3542;
&RFC3704;
&RFC4301;
&RFC4953;
&RFC4987;
&RFC5015;
&RFC5082;
&RFC5294;
&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;
&I-D.mrw-behave-nat66;
&I-D.rja-ilnp-intro;
&I-D.van-beijnum-1e-mp-tcp;
<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
-00 First draft
-01 Second draft. Adds Security Considerations.
-02
-->
| PAFTECH AB 2003-2026 | 2026-04-21 18:01:04 |