< draft-ietf-tcpm-tcpsecure-12.txt   draft-ietf-tcpm-tcpsecure-13.txt >
TCP Maintenance and Minor A. Ramaiah TCP Maintenance and Minor A. Ramaiah
Extensions Working Group Cisco Systems Extensions Working Group Cisco Systems
Internet-Draft R. Stewart Internet-Draft R. Stewart
Updates: 793 (if approved) Researcher Intended status: Standards Track Huawei
Intended status: Standards Track M. Dalal Expires: November 4, 2010 M. Dalal
Expires: March 17, 2010 Cisco Systems Cisco Systems
September 13, 2009 May 3, 2010
Improving TCP's Robustness to Blind In-Window Attacks Improving TCP's Robustness to Blind In-Window Attacks
draft-ietf-tcpm-tcpsecure-12.txt draft-ietf-tcpm-tcpsecure-13.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 March 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
TCP has historically been considered protected against spoofed off- TCP has historically been considered protected against spoofed off-
path packet injection attacks by relying on the fact that it is path packet injection attacks by relying on the fact that it is
difficult to guess the 4-tuple (the source and destination IP difficult to guess the 4-tuple (the source and destination IP
addresses and the source and destination ports) in combination with addresses and the source and destination ports) in combination with
the 32 bit sequence number(s). A combination of increasing window the 32 bit sequence number(s). A combination of increasing window
sizes and applications using longer term connections (e.g. H-323 or sizes and applications using longer term connections (e.g. H-323 or
Border Gateway Protocol [RFC4271]) have left modern TCP Border Gateway Protocol [RFC4271]) have left modern TCP
skipping to change at page 3, line 5 skipping to change at page 1, line 37
addresses and ports which makes it far easier for the 4-tuple addresses and ports which makes it far easier for the 4-tuple
(4-tuple is the same as the socket pair mentioned in [RFC0793]) to be (4-tuple is the same as the socket pair mentioned in [RFC0793]) to be
guessed. Having guessed the 4-tuple correctly, an attacker can guessed. Having guessed the 4-tuple correctly, an attacker can
inject a TCP segment with the RST bit set, the SYN bit set or data inject a TCP segment with the RST bit set, the SYN bit set or data
into a TCP connection by systematically guessing the sequence number into a TCP connection by systematically guessing the sequence number
of the spoofed segment to be in the current receive window. This can of the spoofed segment to be in the current receive window. This can
cause the connection to abort or cause data corruption. This cause the connection to abort or cause data corruption. This
document specifies small modifications to the way TCP handles inbound document specifies small modifications to the way TCP handles inbound
segments that can reduce the chances of a successful attack. segments that can reduce the chances of a successful attack.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 4, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 5 1.2. Basic Attack Methodology . . . . . . . . . . . . . . . . . 5
1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6 1.3. Attack probabilities . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9 3. Blind reset attack using the RST bit . . . . . . . . . . . . . 9
3.1. Description of the attack . . . . . . . . . . . . . . . . 9 3.1. Description of the attack . . . . . . . . . . . . . . . . 9
3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 27 skipping to change at page 3, line 27
4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Blind data injection attack . . . . . . . . . . . . . . . . . 13 5. Blind data injection attack . . . . . . . . . . . . . . . . . 13
5.1. Description of the attack . . . . . . . . . . . . . . . . 13 5.1. Description of the attack . . . . . . . . . . . . . . . . 13
5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15 6. Suggested Mitigation strengths . . . . . . . . . . . . . . . . 15
7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16 7. ACK throttling . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Backward Compatibility and Other considerations . . . . . . . 17 8. Backward Compatibility and Other considerations . . . . . . . 17
9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18 9. Middlebox considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18 9.1. Middlebox that resend RST's . . . . . . . . . . . . . . . 18
9.2. Middleboxes that advance sequence numbers . . . . . . . . 18 9.2. Middleboxes that advance sequence numbers . . . . . . . . 18
9.3. Middleboxes that drop the challenge ACK . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 7, line 42 skipping to change at page 7, line 42
For applications that can use the TCP MD5 option [RFC2385], such as For applications that can use the TCP MD5 option [RFC2385], such as
BGP, that option makes the attacks described in this specification BGP, that option makes the attacks described in this specification
effectively impossible. However, some applications or effectively impossible. However, some applications or
implementations may find that option expensive to implement. implementations may find that option expensive to implement.
There are alternative protections against the threats that this There are alternative protections against the threats that this
document addresses. For further details regarding the attacks and document addresses. For further details regarding the attacks and
the existing techniques, please refer to [RFC4953]. It also needs to the existing techniques, please refer to [RFC4953]. It also needs to
be emphasized that, as suggested in be emphasized that, as suggested in
[I-D.ietf-tsvwg-port-randomization](port randomization) and [RFC1948] [I-D.ietf-tsvwg-port-randomization] and [RFC1948], port randomization
(ISN randomization) would help improve the robustness of the TCP and ISN randomization would help improve the robustness of the TCP
connection against off-path attacks. connection against off-path attacks.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. TCP document are to be interpreted as described in [RFC2119]. TCP
terminology should be interpreted as described in [RFC0793]. terminology should be interpreted as described in [RFC0793].
3. Blind reset attack using the RST bit 3. Blind reset attack using the RST bit
skipping to change at page 20, line 5 skipping to change at page 19, line 21
3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 3. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED 4. ESTABLISHED --> <SEQ=100><ACK=300><WND=500><CTL=ACK> --> CLOSED
5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED 5. ESTABLISHED <-- <SEQ=800><ACK=100><CTL=RST> <-- CLOSED
Although the authors are not aware of an implementation that does the Although the authors are not aware of an implementation that does the
above, it could be mitigated by implementing the ACK throttling above, it could be mitigated by implementing the ACK throttling
mechanism described earlier. mechanism described earlier.
9.3. Middleboxes that drop the challenge ACK
It also needs to be noted that, some middleboxes (Firewalls/NATs)
which doesn't have the fix recommended in the document, may drop the
challenge ACK. This can happen because, the original RST segment
which was in window had already cleared the flow state pertaining to
the TCP connection in the middlebox. In such cases, the end hosts
which have implemented the RST mitigation described in this document,
will have the TCP connection left open. This is a corner case and
can go away if the middlebox is conformant with the changes proposed
in this document.
10. Security Considerations 10. Security Considerations
These changes to the TCP state machine do NOT protect an These changes to the TCP state machine do NOT protect an
implementation from on-path attacks. It also needs to be emphasized implementation from on-path attacks. It also needs to be emphasized
that while mitigations within this document make it harder for off- that while mitigations within this document make it harder for off-
path attackers to inject segments, it does NOT make it impossible. path attackers to inject segments, it does NOT make it impossible.
The only way to fully protect a TCP connection from both on and off The only way to fully protect a TCP connection from both on and off
path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP path attacks is by using either IPSEC-AH [RFC4302] or IPSEC-ESP
[RFC4303]. [RFC4303].
skipping to change at page 23, line 10 skipping to change at page 23, line 10
attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of attacks. Shrirang Bage of Cisco Systems, Qing Li and Preety Puri of
Wind River Systems and Xiaodan Tang of QNX Software along with the Wind River Systems and Xiaodan Tang of QNX Software along with the
folks above helped in ratifying and testing the interoperability of folks above helped in ratifying and testing the interoperability of
the suggested solutions. the suggested solutions.
13. Acknowledgments 13. Acknowledgments
Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern Special thanks to Mark Allman, Ted Faber, Steve Bellovin, Vern
Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong, Paxson, Allison Mankin, Sharad Ahlawat, Damir Rajnovic, John Wong,
Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra Joe Touch, Alfred Hoenes, Andre Oppermann, Fernando Gont, Sandra
Murphy, Brian Carpenter and other members of the tcpm WG for Murphy, Brian Carpenter, Cullen Jennings and other members of the
suggestions and comments. ACK throttling was introduced to this tcpm WG for suggestions and comments. ACK throttling was introduced
document by combining the suggestions from the tcpm working group. to this document by combining the suggestions from the tcpm working
group.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.2. Informative References
[I-D.ietf-tcpm-icmp-attacks] [I-D.ietf-tcpm-icmp-attacks]
Gont, F., "ICMP attacks against TCP", Gont, F., "ICMP attacks against TCP",
draft-ietf-tcpm-icmp-attacks-06 (work in progress), draft-ietf-tcpm-icmp-attacks-12 (work in progress),
August 2009. March 2010.
[I-D.ietf-tsvwg-port-randomization] [I-D.ietf-tsvwg-port-randomization]
Larsen, M. and F. Gont, "Port Randomization", Larsen, M. and F. Gont, "Transport Protocol Port
draft-ietf-tsvwg-port-randomization-04 (work in progress), Randomization Recommendations",
July 2009. draft-ietf-tsvwg-port-randomization-07 (work in progress),
April 2010.
[Medina05] [Medina05]
Medina, A., Allman, M., and S. Floyd, "Measuring the Medina, A., Allman, M., and S. Floyd, "Measuring the
Evolution of Transport Protocols in the Internet. ACM Evolution of Transport Protocols in the Internet. ACM
Computer Communication Review, 35(2), April 2005. Computer Communication Review, 35(2), April 2005.
http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps http://www.icir.org/mallman/papers/tcp-evo-ccr05.ps
(figure 6)". (figure 6)".
[NISCC] NISCC, "NISCC Vulnerability Advisory 236929 - [NISCC] NISCC, "NISCC Vulnerability Advisory 236929 -
Vulnerability Issues in TCP". Vulnerability Issues in TCP".
skipping to change at page 26, line 17 skipping to change at page 26, line 17
Anantha Ramaiah Anantha Ramaiah
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 525-6486 Phone: +1 (408) 525-6486
Email: ananth@cisco.com Email: ananth@cisco.com
Randall R. Stewart Randall R. Stewart
Researcher Huawei
Chapin 148 Crystal Cove Ct
SC 29036 Chapin, SC 29036
USA USA
Phone: +1 (803) 345-0369 Phone: +1 (803) 345-0369
Email: randall@lakerest.net Email: rstewart@huawei.com
Mitesh Dalal Mitesh Dalal
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 (408) 853-5257 Phone: +1 (408) 853-5257
Email: mdalal@cisco.com Email: mdalal@cisco.com
 End of changes. 11 change blocks. 
53 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/