draft-ietf-tcpm-tcp-auth-opt-09.txt   draft-ietf-tcpm-tcp-auth-opt-10.txt 
TCPM WG J. Touch TCPM WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Obsoletes: 2385 A. Mankin Obsoletes: 2385 A. Mankin
Intended status: Proposed Standard Johns Hopkins Univ. Intended status: Proposed Standard Johns Hopkins Univ.
Expires: July 2010 R. Bonica Expires: July 2010 R. Bonica
Juniper Networks Juniper Networks
January 31, 2010 January 31, 2010
The TCP Authentication Option The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-09.txt draft-ietf-tcpm-tcp-auth-opt-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 2, line 45 skipping to change at page 2, line 45
set of MACs with minimal other system and operational changes. TCP-AO set of MACs with minimal other system and operational changes. TCP-AO
uses a different option identifier than TCP MD5, even though TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO
and TCP MD5 are never permitted to be used simultaneously. TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO
supports IPv6, and is fully compatible with the proposed requirements supports IPv6, and is fully compatible with the proposed requirements
for the replacement of TCP MD5. for the replacement of TCP MD5.
Table of Contents Table of Contents
1. Contributors...................................................3 1. Contributors...................................................3
2. Introduction...................................................4 2. Introduction...................................................4
2.1. Applicability Statement...................................4 2.1. Applicability Statement...................................5
2.2. Executive Summary.........................................5 2.2. Executive Summary.........................................5
3. Conventions used in this document..............................7 3. Conventions used in this document..............................7
4. The TCP Authentication Option..................................7 4. The TCP Authentication Option..................................7
4.1. Review of TCP MD5 Option..................................7 4.1. Review of TCP MD5 Option..................................7
4.2. The TCP-AO Option.........................................8 4.2. The TCP-AO Option.........................................8
5. TCP-AO Keys and Their Properties..............................10 5. TCP-AO Keys and Their Properties..............................10
5.1. Master Key Tuple.........................................10 5.1. Master Key Tuple.........................................10
5.2. Traffic Keys.............................................12 5.2. Traffic Keys.............................................12
5.3. MKT Properties...........................................13 5.3. MKT Properties...........................................13
skipping to change at page 3, line 27 skipping to change at page 3, line 27
8.1. Coordinating Use of New MKTs.............................23 8.1. Coordinating Use of New MKTs.............................23
8.2. Preventing replay attacks within long-lived connections..24 8.2. Preventing replay attacks within long-lived connections..24
9. TCP-AO Interaction with TCP...................................26 9. TCP-AO Interaction with TCP...................................26
9.1. TCP User Interface.......................................27 9.1. TCP User Interface.......................................27
9.2. TCP States and Transitions...............................28 9.2. TCP States and Transitions...............................28
9.3. TCP Segments.............................................28 9.3. TCP Segments.............................................28
9.4. Sending TCP Segments.....................................29 9.4. Sending TCP Segments.....................................29
9.5. Receiving TCP Segments...................................30 9.5. Receiving TCP Segments...................................30
9.6. Impact on TCP Header Size................................32 9.6. Impact on TCP Header Size................................32
9.7. Connectionless Resets....................................33 9.7. Connectionless Resets....................................33
9.8. ICMP Handling............................................34
10. Obsoleting TCP MD5 and Legacy Interactions...................34 10. Obsoleting TCP MD5 and Legacy Interactions...................34
11. Interactions with Middleboxes................................34 11. Interactions with Middleboxes................................35
11.1. Interactions with non-NAT/NAPT Middleboxes..............34 11.1. Interactions with non-NAT/NAPT Middleboxes..............35
11.2. Interactions with NAT/NAPT Devices......................35 11.2. Interactions with NAT/NAPT Devices......................36
12. Evaluation of Requirements Satisfaction......................35 12. Evaluation of Requirements Satisfaction......................36
13. Security Considerations......................................41 13. Security Considerations......................................42
14. IANA Considerations..........................................43 14. IANA Considerations..........................................43
15. References...................................................44 15. References...................................................44
15.1. Normative References....................................44 15.1. Normative References....................................44
15.2. Informative References..................................45 15.2. Informative References..................................45
16. Acknowledgments..............................................47 16. Acknowledgments..............................................47
1. Contributors 1. Contributors
This document evolved as the result of collaboration of the TCP This document evolved as the result of collaboration of the TCP
Authentication Design team (tcp-auth-dt), whose members were Authentication Design team (tcp-auth-dt), whose members were
skipping to change at page 21, line 39 skipping to change at page 21, line 39
S-IP S-port S-ISN D-IP D-port D-ISN S-IP S-port S-ISN D-IP D-port D-ISN
---------------------------------------------------------------- ----------------------------------------------------------------
Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0 Send_SYN_traffic_key l-IP l-port l-ISN r-IP r-port 0
Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0 Receive_SYN_traffic_key r-IP r-port r-ISN l-IP l-port 0
Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN Send_other_traffic_key l-IP l-port l-ISN r-IP r-port r-ISN
Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN Receive_other_traffic_key r-IP r-port r-ISN l-IP l-port l-ISN
The use of both ISNs in the traffic key computations ensures that The use of both ISNs in the traffic key computations ensures that
segments cannot be replayed across repeated connections reusing the segments cannot be replayed across repeated connections reusing the
same socket pair (provided the ISN pair does not repeat, which is same socket, their 32-bit space avoids repeated use except under
unlikely because both endpoints should select ISNs pseudorandomly
[RFC1948], their 32-bit space avoids repeated use except under
reboot, and reuse assumes both sides repeat their use on the same reboot, and reuse assumes both sides repeat their use on the same
connection). connection). We do expect that:
>> Endpoints should select ISNs pseudorandomly, e.g., as in [RFC1948]
A SYN is authenticated using a destination ISN of zero (whether sent A SYN is authenticated using a destination ISN of zero (whether sent
or received), and all other segments would be authenticated using the or received), and all other segments would be authenticated using the
ISN pair for the connection. There are other cases in which the ISN pair for the connection. There are other cases in which the
destination ISN is not known, but segments are emitted, such as after destination ISN is not known, but segments are emitted, such as after
an endpoint reboots, when is possible that the two endpoints would an endpoint reboots, when is possible that the two endpoints would
not have enough information to authenticate segments. This is not have enough information to authenticate segments. This is
addressed further in Section 9.7. addressed further in Section 9.7.
7.3. Traffic Key Establishment and Duration Issues 7.3. Traffic Key Establishment and Duration Issues
skipping to change at page 34, line 5 skipping to change at page 34, line 5
using TCP-AO. using TCP-AO.
We recognize that support for graceful restart is not always We recognize that support for graceful restart is not always
feasible. As a result: feasible. As a result:
>> When BGP without graceful restart is used with TCP-AO, both sides >> When BGP without graceful restart is used with TCP-AO, both sides
of the connection SHOULD save traffic keys in storage that persists of the connection SHOULD save traffic keys in storage that persists
across reboots and restore them after a reboot, and SHOULD limit any across reboots and restore them after a reboot, and SHOULD limit any
performance impacts that result from this storage/restoration. performance impacts that result from this storage/restoration.
9.8. ICMP Handling
TCP can be attacked both in-band, using TCP segments, or out-of-band
using ICMP. ICMP packets cannot be protected using TCP-AO mechanisms,
however; in this way, both TCP-AO and IPsec do not directly solve the
need for protected ICMP signaling. TCP-AO does make specific
recommendations on how to handle certain ICMPs, beyond what IPsec
requires, and these are made possible because TCP-AO operates inside
the context of a TCP connection.
IPsec makes recommendations regarding dropping ICMPs in certain
contexts, or requiring that they are endpoint authenticated in others
[RFC4301]. There are other mechanisms proposed to reduce the impact
of ICMP attacks by further validating ICMP contents and changing the
effect of some messages based on TCP state, but these do not provide
the level of authentication for ICMP that TCP-AO provides for TCP
[Go09]. As a result, we recommend a conservative approach to
accepting ICMP attacks as summarized in [Go09]:
>> A TCP-AO implementation MUST default to ignore incoming ICMP
messages of Type 3 (destination unreachable) Codes 2-4 (protocol
unreachable, port unreachable, and fragmentation needed - 'hard
errors') intended for connections that match MKTs.
>> A TCP-AO implementation SHOULD allow whether such ICMPs are
ignored to be configured on a per-connection basis.
>> A TCP-AO implementation SHOULD implement measures to protect ICMP
"packet too big" messages, some examples of which are discussed in
[Go09]
>> An implementation SHOULD allow ignored ICMPs to be logged.
This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection [RFC1122]. This recommendation
is intended to be similar to how IPsec would handle those messages,
with an additional default assumed [RFC4301].
10. Obsoleting TCP MD5 and Legacy Interactions 10. Obsoleting TCP MD5 and Legacy Interactions
TCP-AO obsoletes TCP MD5. As we have noted earlier: TCP-AO obsoletes TCP MD5. As we have noted earlier:
>> TCP implementations MUST support TCP-AO. >> TCP implementations MUST support TCP-AO.
Systems implementing TCP MD5 only are considered legacy, and ought to Systems implementing TCP MD5 only are considered legacy, and ought to
be upgraded when possible. In order to support interoperation with be upgraded when possible. In order to support interoperation with
such legacy systems until upgrades are available: such legacy systems until upgrades are available:
skipping to change at page 41, line 13 skipping to change at page 41, line 34
This is supported - see Section 9.5. This is supported - see Section 9.5.
e. Non-interaction with TCP MD5. e. Non-interaction with TCP MD5.
The use of this option for a given connection should not The use of this option for a given connection should not
preclude the use of TCP MD5, e.g., for legacy use, for other preclude the use of TCP MD5, e.g., for legacy use, for other
connections. connections.
This is supported - see Section 9.7. This is supported - see Section 9.7.
f. Optional ICMP discard. f. "Hard" ICMP discard.
The option should allow certain ICMPs to be discarded, notably The option should allow certain ICMPs to be discarded, notably
Type 3 (destination unreachable), Codes 2-4 (transport Type 3 (destination unreachable), Codes 2-4 (transport
protocol unreachable, port unreachable, or fragmentation protocol unreachable, port unreachable, or fragmentation
needed and IP DF field set), i.e., the ones indicating the needed and IP DF field set), i.e., the ones indicating the
failure of the endpoint to communicate. failure of the endpoint to communicate.
This is supported - see Section 13. This is supported - see Section 13.
g. Maintain TCP connection semantics, in which the socket pair g. Maintain TCP connection semantics, in which the socket pair
skipping to change at page 42, line 21 skipping to change at page 42, line 45
timeout, which is what should be expected when the intended receiver timeout, which is what should be expected when the intended receiver
is not capable of the TCP variant required anyway. Backoff is not is not capable of the TCP variant required anyway. Backoff is not
optimized because it would present an opportunity for attackers on optimized because it would present an opportunity for attackers on
the wire to abort authenticated connection attempts by sending the wire to abort authenticated connection attempts by sending
spoofed SYN-ACKs without the TCP-AO option. spoofed SYN-ACKs without the TCP-AO option.
TCP-AO is intended to provide similar protections to IPsec, but is TCP-AO is intended to provide similar protections to IPsec, but is
not intended to replace the use of IPsec or IKE either for more not intended to replace the use of IPsec or IKE either for more
robust security or more sophisticated security management. TCP-AO is robust security or more sophisticated security management. TCP-AO is
intended to protect the TCP protocol itself from attacks that TLS, intended to protect the TCP protocol itself from attacks that TLS,
sBGP/soBGP, and other data stream protection mechanism cannot. sBGP/soBGP, and other data stream protection mechanism cannot. Like
IPsec, TCP-AO does not address the overall issue of ICMP attacks on
TCP-AO does not address the issue of ICMP attacks on TCP. IPsec makes TCP, but does limit the impact of ICMPs, as noted in Section 9.8.
recommendations regarding dropping ICMPs in certain contexts, or
requiring that they are endpoint authenticated in others [RFC4301].
There are other mechanisms proposed to reduce the impact of ICMP
attacks by further validating ICMP contents and changing the effect
of some messages based on TCP state, but these do not provide the
level of authentication for ICMP that TCP-AO provides for TCP [Go09].
>> A TCP-AO implementation MUST allow the system administrator to
configure whether TCP will ignore incoming ICMP messages of Type 3
(destination unreachable) Codes 2-4 (protocol unreachable, port
unreachable, and fragmentation needed - 'hard errors') intended for
connections that match MKTs. An implementation SHOULD allow ignored
ICMPs to be logged.
This control affects only ICMPs that currently require 'hard errors',
which would abort the TCP connection [RFC1122]. This recommendation
is intended to be similar to how IPsec would handle those messages
[RFC4301].
TCP-AO includes the TCP connection ID (the socket pair) in the MAC TCP-AO includes the TCP connection ID (the socket pair) in the MAC
calculation. This prevents different concurrent connections using the calculation. This prevents different concurrent connections using the
same MKT (for whatever reason) from potentially enabling a traffic- same MKT (for whatever reason) from potentially enabling a traffic-
crossing attack, in which segments to one socket pair are diverted to crossing attack, in which segments to one socket pair are diverted to
attack a different socket pair. When multiple connections use the attack a different socket pair. When multiple connections use the
same MKT, it would be useful to know that segments intended for one same MKT, it would be useful to know that segments intended for one
ID could not be (maliciously or otherwise) modified in transit and ID could not be (maliciously or otherwise) modified in transit and
end up being authenticated for the other ID. That requirement would end up being authenticated for the other ID. That requirement would
place an additional burden of uniqueness on MKTs within endsystems, place an additional burden of uniqueness on MKTs within endsystems,
 End of changes. 9 change blocks. 
33 lines changed or deleted 54 lines changed or added

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