Internet Engineering Task Force S. Blake
Internet-Draft Extreme Networks
Intended status: Standards Track November 3, 2008
Expires: May 7, 2009
Use of the IPv6 Flow Label as a Transport-Layer Nonce
to Defend Against Off-Path Spoofing Attacks
draft-blake-ipv6-flow-label-nonce-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009.
Abstract
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
Blake Expires May 7, 2009 [Page 1]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
easily implementable, allows for incremental deployment, and is fully
compliant with the rules for Flow Label use defined in RFC 3697.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Additional Requirements on Flow Label Value Generation and
Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. TCP Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. UDP Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. DCCP Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. RTP Considerations . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Blake Expires May 7, 2009 [Page 2]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
1. Introduction
Recent effort has been directed towards identifying and reducing the
vulnerability of TCP [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) [RFC4953][RFC5082]
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-tcpsecure]
[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 host,
with similar negative consequences [I-D.ietf-tcpm-icmp-attacks].
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 [RFC2385], TCP Authentication
Option [I-D.ietf-tcpm-tcp-auth-opt], and IPsec [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 applications.
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
[RFC2827][RFC3704]. But network ingress filtering is not universally
deployed, leaving many networks vulnerable to spoofed packet attacks.
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).
Obfuscation techniques can be employed to increase the effort
required of an attacker. Initial sequence number randomization
[RFC1948] [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 [RFC4953]. Source port randomization
Blake Expires May 7, 2009 [Page 3]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
[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.
Both obfuscation schemes are compliant with [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.
[I-D.weaver-dnsext-comprehensive-resolver] argues that 40 bits of
entropy is desirable to make off-path spoofing attacks impractical.
IPv6 [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>
uniquely identifies a particular flow during its lifetime (plus a
subsequent quarantine period). Rules for the generation and usage of
Flow Label values are defined in [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.
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 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 initial sequence number
randomization is also used (i.e., in TCP), the entropy is increased
to > 40 bits, making off-path snooping attacks impractical.
The concept of labeling transport connections to prevent off-path
spoofing attacks was proposed in [McGann05], in the context of
stateful firewalls. This scheme may be useful for other transport
Blake Expires May 7, 2009 [Page 4]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
protocols such as SCTP [RFC4960], UDP [RFC0768], UDP-Lite [RFC3828],
DCCP [RFC4340], and RTP [RFC3550]. Host implementations in
compliance with [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.
Section 3 specifies additional requirements on Flow Label generation.
Section 4 describes the use of this scheme with TCP. Section 5
describes the use of this scheme with UDP and UDP-Lite. Section 6
describes the use of this scheme with SCTP. Section 7 describes the
use of this scheme with DCCP. Section 8 describes the use of this
scheme with RTP over UDP or DCCP.
2. Requirements Language
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 [RFC2119].
3. Additional Requirements on Flow Label Value Generation and Use
[RFC3697] specifies the rules governing use of the IPv6 Flow Label.
The primary requirements relevant to our purpose are as follows
(quoting directly):
o The Flow Label value set by the source MUST be delivered unchanged
to the destination node(s).
o To enable Flow Label based classification, source nodes SHOULD
assign each unrelated transport connection and application data
stream to a new flow.
o The source node SHOULD be able to select unused Flow Label values
for flows not requesting a specific value to be used.
o 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.
o 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.
Blake Expires May 7, 2009 [Page 5]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
o 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.
o 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.
We wish to use the Flow Label value as an unguessable nonce. Hence,
the following additional requirements are implied:
o Source hosts MUST assign each unrelated transport connection and
application data stream to a new flow.
o 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.
o 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 [RFC4086] MUST be used to generate Flow Label values not
explicitly requested by an application.
o 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.
o 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).
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 [RFC3697] against
Blake Expires May 7, 2009 [Page 6]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
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.
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.
ICMPv6 error messages contain the IPv6 header of the packet
triggering the error [RFC4443]. A host receiving an ICMPv6 error
message can validate the Flow Label value in the message payload to
protect against ICMPv6 spoofing attacks [I-D.ietf-tcpm-icmp-attacks].
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.
The additional requirements given here for Flow Label generation and
use are not in conflict with the requirements in [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.
4. TCP Considerations
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.
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
Blake Expires May 7, 2009 [Page 7]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
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.
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.
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 [McGann05] [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 [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.
[RFC0793] specifies that a connection should remain in TIME_WAIT
state for 2 * MSL (Maximum Segment Lifetime) seconds. [RFC0793]
specifies MSL as 120 seconds, although many implementations default
Blake Expires May 7, 2009 [Page 8]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
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.
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
[RFC2385][I-D.ietf-tcpm-tcp-auth-opt] [RFC4301].
5. UDP Considerations
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.
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/
Blake Expires May 7, 2009 [Page 9]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
port pair is to utilize different source and/or destination port
values for each data stream.
There is no standard sockets API for either setting the Flow Label
value in outgoing packets, nor retrieving it in incoming packets
[RFC3493][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.
One application where the use of the Flow Label as a nonce would be
beneficial is in protection against blind DNS cache poisoning attacks
[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.
UDP-Lite [RFC3828] differs from UDP by allowing an application to
exclude parts of the payload from the UDP-Lite checksum. Since the
Flow Label field is not part of the UDP-Lite pseudo header [RFC2460],
its value could be altered by data transmission errors (that are not
corrected or rejected by the data link layer) that are not detected
by the destination. Therefore, UDP-Lite applications SHOULD NOT
check the Flow Label value received in packets of a data stream
carried over UDP-Lite.
6. SCTP Considerations
Use of the Flow Label with SCTP will be discussed in a subsequent
revision of this document.
7. DCCP Considerations
Use of the Flow Label with DCCP will be discussed in a subsequent
revision of this document.
8. RTP Considerations
Use of the Flow Label with RTP applications will be discussed in a
Blake Expires May 7, 2009 [Page 10]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
subsequent revision of this document.
9. Acknowledgements
[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.
The author would like to thank Brian Carpenter for his valuable
feedback.
This document was produced using the xml2rfc tool [RFC2629].
10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
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 must be used in high threat environments.
12. References
12.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Blake Expires May 7, 2009 [Page 11]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
(IPv6) Specification", RFC 2460, December 1998.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
12.2. Informative References
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, February 2003.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003.
Blake Expires May 7, 2009 [Page 12]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-03 (work in progress),
March 2008.
[I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks",
draft-ietf-tcpm-tcpsecure-10 (work in progress),
July 2008.
[I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization",
draft-ietf-tsvwg-port-randomization-02 (work in progress),
August 2008.
[I-D.ietf-tcpm-tcp-auth-opt]
Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", draft-ietf-tcpm-tcp-auth-opt-01
(work in progress), July 2008.
[I-D.weaver-dnsext-comprehensive-resolver]
Weaver, N., "Comprehensive DNS Resolver Defenses Against
Cache Poisoning",
draft-weaver-dnsext-comprehensive-resolver-00 (work in
progress), September 2008.
[McGann05]
McGann, O. and D. Malone, "Flow Label Filtering
Feasibility", European Conference on Computer Network
Defence, December 2005.
Blake Expires May 7, 2009 [Page 13]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
Author's Address
Steven Blake
Extreme Networks
Pamlico Building One, Suite 100
3306/08 E. NC Hwy 54
RTP, NC 27709
USA
Phone: +1 919 884 3211
Email: sblake@extremenetworks.com
Blake Expires May 7, 2009 [Page 14]
Internet-Draft Flow Label as Transport-Layer Nonce November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Blake Expires May 7, 2009 [Page 15]