2.8.20 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-23

Ted Faber <faber@isi.edu>
Mark Allman <mallman@icir.org>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Mailing Lists:
General Discussion: tcpm@ietf.org
To Subscribe: tcpm-request@ietf.org
In Body: subscribe email_address
Archive: http://www.ietf.org/mail-archive/web/tcpm/index.html
Description of Working Group:
TCP is currently the Internet's predominant transport protocol. To maintain TCP's utility the IETF has regularly updated both the protocol itself and the congestion control algorithms implemented by the protocol that are crucial for the stability of the Internet. These changes reflect our evolving understanding of transport protocols, congestion control and new needs presented by an ever-changing network. The TCPM WG will provide a venue within the IETF to work on these issues. The WG will serve several purposes:

* The WG will mostly focus on maintenance issues (e.g., bug fixes) and modest changes to the protocol and algorithms that maintain TCP's utility. * The WG will be a venue for moving current TCP specifications along the standards track (as community energy is available for such efforts).

* The WG will write a document that outlines "what is TCP". This document will be a roadmap of sorts to the various TCP specifications in the RFC series.

TCPM will take a subset of the work which has been conducted in the Transport Area WG over the past several years. Specifically, some of the WG's initial work will be moved from the Transport Area WG (tsvwg).

TCPM is expected to be the working group within the IETF to handle TCP changes. Proposals for additional TCP work items should be brought up within the working group. While fundamental changes to TCP or its congestion control algorithms (e.g., departure from loss-based congestion control) should be brought through TCPM, it is expected that such large changes will ultimately be handled by the Transport Area WG (tsvwg). All additional work items for TCPM will, naturally, require the approval of the Transport Services Area Area Directors and the IESG.

TCP's congestion control algorithms are the model followed by alternate transports (e.g., SCTP and (in some cases) DCCP). In addition, the IETF has recently worked on several documents about algorithms that are specified for multiple protocols (e.g., TCP and SCTP) in the same document. Which WG shepherds such documents in the future will determined on a case-by-case basis. In any case, the TCPM WG will remain in close contact with other relevant WGs working on these protocols to ensure openness and stringent review from all angles.

Specific Goals:

* A revision of RFC 1323 based on experience and evaluation. Depending on the conclusions of the WG and the nature of the updates this document could be a candidate for Draft Standard. A current Internet-Draft has been submitted to start this process (draft-jacobson-tsvwg-1323bis-00.txt).

* A "roadmap" for TCP. The protocol and associated algorithms have become spread out throughout the RFC series. This WG will issue a document that catalogs all the various TCP specifications and informational documents in the RFC series in a single location. An initial discussion (and strawman start at a list of such RFCs) has been conducted on the end2end interest list.

* While there is no consensus on exactly how to deal with spurious retransmits (caused by bad RTO estimates or packet reordering) there are several proposals that will be fleshed out in this WG and likely issued as experimental documents. The current set of proposals is:

draft-sarolahti-tsvwg-tcp-frto-03.txt draft-blanton-tcp-reordering-00.txt draft-bhandarkar-tcp-dcr-00.txt

Goals and Milestones:
Mar 04  Submit FRTO draft to IESG for publication as an Experimental RFC
Mar 04  Submit Reordering Mitigation draft to IESG for publication as an Experimental RFC
May 04  Submit DCR draft to IESG for publication as an Experimental RFC
May 04  Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC
May 04  Develop (providing editors are available) milestones for advancement to Draft Standard of identified important TCP specs (e.g. RFC 2018, 2581, 2988...)
Jun 04  Submit a revision of RFC 1323 to the IESG for publication as a Proposed or Draft Standard (depending on the nature of the changes to the document)
  • - draft-ietf-tcpm-tcp-dcr-01.txt
  • - draft-ietf-tcpm-tcpsecure-01.txt
  • - draft-ietf-tcpm-frto-01.txt
  • No Request For Comments

    Current Meeting Report

    TCPM working group

    Monday, August 2nd, 2004

    Minutes taken by Aaron Falk <falk@isi.edu>

    - Agenda bashing
    - WG status

    - Proposal on using ICMP host unreachable messages as indications to transport to use a different IP address (Pekka Savola, for Fernando Gont)

    - Joe Touch: Why not open multiple connections simultaneously? Nothing stopping an application from opening a connection for every address returned from DNS. The proposal interferes with rfc1822 specification. Application can just timeout and avoid passing all the information up to app.

    - Dave Borman, Cray: what Joe said. This is the issue of how to choose which address to connect to. Changing all the applications is hard but an application should be able to pass a bunch of addresses to lower layers and let them try multiple ones. Also, SYN-RECEIVE doesn't make sense. (lost reason why...) Meta issue: should we make small, surgical fix (choosing which answers first) or address larger issue (picking addresses). Should look at this further.

    - Eddie Kohler, UCLA. The approach of using soft state as hard will cause connections which would have worked to be dropped. E.g., for intermittent connections like flaky dialup. Pekka: author wants to provide a system level toggle to allow disabling of this function and dial-up is uncommon.

    - Ted: hearing from group that two issues need to be addressed before taking this document into tcpm are: 1) is this the right place to make the fix (as opposed to the app) and 2) addressing how to handle packets delayed in the network.

    - TCP User Timeout Option, Lars Eggert, NEC & Fernando Gont, UTN/FRH

    - Timeouts control how long data may remain unacked before a connection aborts. usually a system-wide constant O(minutes). Proposal is for a mechanism to exchange per-connection user timeouts using a new TCP option (without suggesting values). Two proposed drafts which are merging and mailing list consensus is that there is interest.

    - Issues on which authors disagree:

    - always include option in SYN (whether you want to use it or not)

    - if two users pick different values for timeout how to pick?

    - which states to use timeout in?

    - Phil Karn, Qualcomm: why do I need this option? (A: for intermittently connected/disconnected hosts) Why does one side need to know the other sides timeout?

    - David Borman: this is to make the timeout longer to allow the connection to survive... forgot my other point...

    - Tim Sheperd: (Arguing in favor.) An end system sets a timeout based on how precious they perceive their resources. Perhaps a timeout should be set to weeks. There's nothing more frustrating to an upper layer than insufficient patience at the lower layer (from humans on down).

    - Randall Stewart: Isn't this a question of just having the right API? Allow applications to negotiate timeouts then pass them down.

    - Borman: keep alives are for identifying connections that haven't gone away; outstanding data forces connections to close more quickly. On choosing: choose the larger -> the goal is to keep the connecting up. Regarding negotiating options in SYN: I'm for negotiating in other packets (getting away from SYN only).

    - Eddie Kohler: would be nice for the draft to explicitly consider how much this gives you beyond a very long timeout. Want both a long timeout and a negotiation.

    - Andrew McGregor: it's frustrating today for an application to know what the timeouts are. A negotiation allows timeouts to be explicit.

    - TCP Corruption Notification Options, Michael Welzl

    - There are well-known problems for TCP over wireless links. All that's needed to get solutions moving is signaling. Also, have partial checksums (in UDP and DCCP). Proposal is to add separate checksums to TCP. Only use if normal TCP checksum fails. If new checksum succeeds, you know that packet experienced corruption. (ed: huh?) Requires link layer cooperation to forward known corrupt data. But don't always want links to forward corrupt data so signaling is needed to enable "link layers notices corruption" feature. Proposal describes how to use feedback. (Table showing feedback usage and results of discussion with Joe Touch.)

    Summary: research demand + potential benefits + partial checksums = time to add this to TCP. Looking for volunteers for implementations and simulations.

    - Phil Karn: authors should read rfc3819. Contains long discussion about TCP checksum is known to be too weak to provide useful data. What is the application of this feature? Common FEC techniques are either all good or all corrupt yielding little useful data when link is bad.

    - Gorry Fairhurst: utility comparison to UDP-Lite isn't fair, TCP apps don't want data with errors where UDP apps may.

    - Ted: sounds like this needs more research and need to read and respond to advice in rfc3819.

    - Anantha Ramaiah, Cisco: what is the wg policy for dealing with TCP option space?

    - Allman: Wes Eddy is preparing a draft with a proposal on this, draft-tcp-loo-00

    - Improving the Robustness of TCP to Non-Congestive Events, Sumitha Bhandarkar, Texas A&M

    - Problem: sub-optimal performance of TCP in network with non-negligible non-congestion events, e.g. packet recovery due to link ARQ.

    - Proposed solution: delay the response to dupacks by one RTT, allow underlying mechanisms to recover from non-congestion events...

    - Issues: buffer requirements at the receiver are large waiting for packet to arrive, but mitigated by cap; dependence on underlying schemes to recover from non-congestion events.

    - What is expected from underlying mechanism?

    - For packet reordering: no explicit mechanisms is needed: reordering less than one RTT can be recovered.

    - For channel errors: link layer retransmissions (could result in higher RTT variance), preference given to retransmissions, does note attempt in-order delivery, or FEC could be used

    - 802.11 uses stop and wait ARQ which forces in-order delivery, doesn't generate DUPACKs, wastes valuable satellite bandwidth, possible workaround with 802.11e

    - What is the effect of adding delay? If recovery is possible, no issue. If recovery isn't possible: delay is bounded by 1 RTT, RTT estimation holds due to Karn's alg. There are fairness implications: calling it TCP-compatible, think 'slowly responsive'.

    - Benefits: unified, simple, sender side only mods, no explicit signaling, no negotiated options, incremental deployment possible.

    - Gorry Fairhurst, Univ. Aberdeen: should ref rfc3366 on link ARQ. Have you looked at the different classes of ARQ? A: need either go-back-n, not stop-and-wait. Gorry: out of order delivery has implications on UDP users.

    - Sally Floyd, ICIR: I like this proposal a lot. One enabling piece of technology would be to feedback from transport to link to indicate "this transport is robust to reordering". Would allow links to do smart things. To Gorry: Advice to link layer designers is from an older era which implies that links only adapt and TCP won't.

    - Tom Henderson, Boeing: from implementation standpoint, does this require you to keep a scoreboard? A: when first dupack comes in you start a timer, which you stop when new ack comes in. Tom: Did you compare this to Eiffel? A: yes. very similar when reordering was in the range of 1 RTT.

    - DoS vulnerability - Carlos J. Bernardos

    - Malicious receiver can spoof TCP sender to saturate its outbound interface. Experiment where a 56kbps modem could make a sender send at 20Mbps. Proposed solution:

    1) a server must start slow start if it receives an ACK for unsent data but within the transmitter send window (intended to penalize an attacker), couldn't be used by a third party to attack a legitimate TCP connection

    2) matching SEG.ACK and (SEG.SEQ + SEG.LEN), a server should randomize segment boundaries in the range of [MS, a*MS], a in [0,1], server should accept an ACK but NOT increase its' CWND if the SEG.ACK fulfills certain conditions.

    - Joe Touch: 3 third party _could attack a legitimate connection, will send details to mail list. Please explain why randomizing the boundaries will help.

    - Carlos J. Bernardos: this is intended to make 1) more effective, increases that a blind attacker will pick an illegal SEQ.

    - TCP RST Spoofing Attacks

    - Allman: game plan: Touch will give overview of problem, review three drafts of solutions, Eric will talk about MD5 in future; then discussion of IPR, kicked off by Scott at end, finally an open discussion.

    - draft-touch-tcp-antispoof, Joe Touch

    - Draft is intended to outline problem, provide a taxonomy of solutions, make some recommendations, hint at underlying opportunity. Problem first published in RFC2385 many years ago. Sequence numbers can be guessed and connections can be jammed by an attacker. Exacerbated by long lived (BGP) connections. Requires knowledge of IP addresses, ports and the window. Router communication makes it easier to guess addresses and ports. As window size grows relative to sequence number space, it becomes easier to guess. Vulnerability is f(BE^2), higher BDP leads to larger windows. Proposed solutions are in two categories: explicit protection - TCP/MD5, IPsec/IKE - and obfuscation - window attenuation/timestamps, larger number space/cookies/ISN. Summary of issues... Proposing solution which uses IPsec between anonymous users, i.e., pairwise keys w/o shared secrets and to be discussed in SAAG.

    - Tcpsecure, Mitesh Dalal

    - A challenge/response solution: RST without an exact match to the RCV.NXT but within window, send a challenge ACK, response RST with an exact match for valid abort. Similar response for data injection vulnerability. Solution is simple, totally backward compatible, running in field for 3 months, inter-operated with five vendors. Concerns expressed: ACK war with middle boxes and randomizing the client port allocation.

    - Protection via the timestamp option, Kaechong Poon, Sun

    - Draft uses timestamps to do some authentication. treats SEG.TSecr as a "cookie", TS.Echo to store the hightes SEG.TSecr received, New acceptance check, initial timestamp chosen must be random so that it cannot be easily guessed, can defend against data injection.

    - Issues: IPR issue on one paragraph which will be removed in next revision. Acceptable range can be too big after idle. May require remote sided modification to be effective RST handling, app timeout is a possible remedy.

    - draft-shepard-tcp-reassign-port-number-00.txt, Tim Shepard

    - Most TCP connections are not vulnerable. For the ones that are, e.g., BGP, proposing making them 'unknown' by not publishing port numbers in, e.g., SNMP. Use good random port numbers. Client asks server to pick new random port number for an existing known port. Option is carried only in packet with SYN bit turned on. Attacker now has to search a space of over 4 billion combinations just to match port numbers correctly. Requires no extra RTs. Planning to implement in FreeBSD in next few weeks. Analysis: takes average of 45 minutes at 1Gbps to hit port number. Issues include firewalls and NATs will probably break.

    - TCP packet authenticate on the cheap, Eric Rescorla

    - see slides...

    - cheap solution 1: nonce-keyed TCP MD5

    - cheap solution 2: short nonce-keyed TCP MAC

    - cheap solution 3: auto-keyed TCP MAC

    - cheap solution 4: auto-keyed TCP checksum

    - Cisco IPR Disclosure on IPR, Scott Bradner

    - Presentation only about Cisco IPR disclosure and its meaning. Scott presenting only because he edited IPR documents and is 'in the loop.'

    "Cisco is the owner of one or more pending patent applications relating to the subject matter of "Transmissions Control Protocol security considerations" <draft-ietf-tcpm-tcpsecure-00.txt>."

    If technology in this document is included in a standard adopted by the IETF and any claims of any Cisco patents are necessary for...

    - Did Cisco follow the rules? yes.

    Why didn't Cisco include a note on the IPR in the tcpsecure ID? (because it wasn't supposed to per rfc3668 section 11)

    Do you have to get a license from Cisco to implement? no

    Do you need to pay Cisco a fee? no

    What about open source? yes, so long as you don't sue Cisco for patent infringement

    Can Cisco change the rules later? can remove conditions but not add.

    Can Cisco stop someone from using tcpsecure (even if they sue Cisco)? no

    What does 'reciprocity' mean in the Cisco IPR disclosure? Cisco expects a RAND license from anyone holding IPR relating to tcpsecure, all bets are off if this is not the case.

    Does the Cisco statement grant Cisco a license to patent owned by another company? no

    - Tim: does this need to be a standard before it can be implemented?
    Scott: Cisco's commitment is contingent on becoming a standard.

    - Loughney: do wg chairs need to ask for IPR awareness before taking new work? Scott: it avoids pain.

    - Mankin: if this becomes an Informational do we need to go back to Cisco for clarification? Scott: Up to Cisco, indications are that they may be less inclined to RAND terms.

    - Words from the AD: there are some alternatives. RFC3368 gives some guidance on options, see section 8: there is a strong predisposition towards IPR free, mandatory to implement security technologies. Is there a VERY GOOD REASON to adopt this solution. The decision lies with the working group.

    - Scott (speaking for himself): there is no such thing as a technology that is known to be IPR-free. A patent holder may turn up at any time. Decision is left to wg.

    - Ekr: Appears to me that the Cisco approach is the best approach since it doesn't require changing both sides. (Ted disagrees.) IPR situation is quite problematic and Cisco's isn't that much better.

    - Joe T.: the working group never chose to make this a wg item

    - Bora Akyol, Cisco: tcpsecure just moves the 'can of worms' to IKE. Everything else has problems with intermediary routers, although Tim's idea was really cool.

    - Tim: this is important enough that the wg should address this problem.

    - Eddie: could the wg adopt multiple solutions to this problem? (Ted: yes, moral but not logical authority) None of these, except for MD5, will solve the problem permanently. E.g., combining reduction of the attack space from tcpsecure with the reduction of attack space that comes from ???.

    - Jon Peterson: What is the urgency of getting a solution?

    - Ekr: do we need to solve the problem at all? The major motivator is BGP. Is it simply enough that BGP users upgrade to TCP/MD5? BGP is important because it is an important capability of the network.

    - Randall: there are other applications besides BGP: there's a Cisco call server in an IP phone system.

    - Tim: there's something wrong with all the solutions presented today. E.g., tcpsecure changes the state/transition diagram so that when a packet shows up you emit a packet when you used to do nothing. In IPsec there's no good way for one end to tell a sender that I don't have a security association.

    - Eddie: this is an important problem to solve since TCP isn't doing the job it is supposed to: provide a reliable byte stream. Only tcpsecure and timestamps are appropriate for standardization for all TCP sessions. Take tcpsecure at least to PS, even with the IPR.

    - Bora: ignoring IPR, you get a very robust protection with tcpsecure.

    - Joe T.: 1) We had 16 years of advanced notice on this problem. 2) Think twice about modifying TCP, then don't. TCP only ensures that *if you send the data and *if you get an ACK, it got there.

    - Shelby???: anyone from hacker community in the room? no. This is a very juicy recipe for attack.

    - Randall: almost all Cisco and Juniper routers deployed this very aggressively.

    - Ekr: measured uptake for servers is about 1/3 within month 1, then flattens out a lot until attacks start. DoS attacks are about $15k. This vulnerability may not be the easiest way to attack. It's important to work on: some. What's important are the core routers, which are running Cisco and Juniper which are already done. (The problem has sort of gone away.)

    - Scott: in distributed code, not just patches

    - Anantha Ramaiah, Cisco: What about FIN attacks? a time bomb waiting to explode. tcpsecure solves this problem too.

    - Bora: security patches from Cisco go into routers very quickly and for free

    - WG chairs: taking a few hums

    - "Hum if you think this vulnerability is important enough to warrant this working to worry about further"

    - strong hum in favor

    - "hum on whether you think these mitigations are reasonable to think about further, not necessarily a wg item"

    - tcpsecure: medium hum in favor, small number against
    result: "lukewarm support"

    - timestamps: medium hum in favor, non against
    result: "lukewarm"

    - port randomization: small hum in favor, medium hum against
    result: "group does not support"

    - sleazy schemes from Ekr: medium hum in favor, small hum against
    result: "lukewarm"

    - "Does Cisco's IPR on tcpsecure & timestamps (if it holds) make these mitigations non-starters"

    - small hum in favor, medium hum against
    result: "IPR is not a show-stopper"

    - "is the antispoof overview document an important doc to have"

    - strong hum in favor, small against
    result: "important doc"

    - Joe: I have in there some recommendations but am willing to take them out.

    - "should we look for no new solutions?"

    - small hum in favor, medium hum against
    result: "keep looking for solutions"


    TCP’s Reaction to Soft Errors
    TCP User Timeout Option
    TCP Corruption Notification Options
    Cisco IPR Disclosure Relating to tcpsecure
    DoS vulnerability of TCP by acknowledging not received segments
    TCP packet authentication on the cheap
    Cisco IPR Disclosure Relating to tcpsecure