2.8.17 TCP Maintenance and Minor Extensions (tcpm)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-31

Chair(s):

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 2004  Submit Reordering Mitigation draft to IESG for publication as an Experimental RFC
Done  Submit FRTO draft to IESG for publication as an Experimental RFC
May 2004  Submit DCR draft to IESG for publication as an Experimental RFC
May 2004  Develop (providing editors are available) milestones for advancement to Draft Standard of identified important TCP specs (e.g. RFC 2018, 2581, 2988...)
Done  Submit TCP Roadmap document to IESG for publication as a Best Current Practices RFC
Jun 2004  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)

Internet-Drafts:

  • draft-ietf-tcpm-tcp-dcr-05.txt
  • draft-ietf-tcpm-tcpsecure-03.txt
  • draft-ietf-tcpm-tcp-roadmap-05.txt
  • draft-ietf-tcpm-tcp-antispoof-02.txt
  • draft-ietf-tcpm-tcp-uto-02.txt

    Request For Comments:

    RFCStatusTitle
    RFC4138 E Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)

    Current Meeting Report

    TCPM Meeting
    Chair: Ted Faber
    November 10, 2005
    Vancouver, Canada
    Notes by Aaron Falk
    
    Status
    - TCPSECURE: in major edit
    - ANTISPOOF: revised, may be ready for WGLC
        Joe Touch: getting  a little feedback with fixes, will revise
        Q: have read?  a few.
    - NCR: clarifications sought, new revision coming, WGLC soon
    
    Proposed Milestones
    - NCR/DCR (merged); seeking experimental status WGLC in Feb06; to IESG
      May06
    - TCPSECURE: WGLC around Dallas, to IESG May06
    - UTO: (Lars Eggert: should be Experimental track)
    - soft errors/informational: WGLC around Dallas; to IESG May06
    
      Discussion
      - Markku: when will 2581bis be out?  Allman says: 1-2 weeks
      - Lars: happy with proposed milestones
    
    New Work
    
    - Develop milestones for advancement to DS of important TCP specs:
      2018, 2581, 2988
    
      - Matt Mathis: 2018 & 2581 are old-style RFCs 'requesting comments';
        need to move it on because it is effectively a Standard; the work
        to be done is really process related, not technical
    
      - Markku: this work should move forward; ready to work on
        implementation report
    
      - Gorry Fairhurst: it needs to be done and done in tcpm.  willing to read the
        docs. 
    
      - Colin Perkins: need to simply write an email to IESG saying 'I tested the
        protocol and it works'
    
      - Pekka Savola: the process spec asks for fine grain testing but IESG
        has been willing to accept more high level implementation reports
    
      - Mark Allman: should be able to leverage the literature on
        implementation reports but still requires energy
    
      - William : How long a list can we create for this?
      	Ted: concerned about expanding beyond available effort. 
    	William: there are many experimentals which might be worth doing.
    	Ted: Exp's are more work. 
    	W: FRTO?
    	T: would love to see it move quick.
    
    
    - RFC1323 needs submission to IESG as PS or possibly DS.
    
    Ted: Room says this list and plan is OK
    
    ============
    
    TCP User Timeout Options - Lars Eggert (NEC), Fernando Gont  (UTN/FRH)
    
    - <>
    - Problem
    - Issue
    
      Tim Shepard (Shep): why do end points need to agree on user time out?
      Lars: can't know ahead of time what the communication pattern will be?
      Shep: so it isn't *required* that they coordinate.
    
      Shep: my UTO sets my persistence, how does it help for you to know that?
    
      Touch: it helps for bidirectional communication, where the effective
      timeout is the lower bound of the two directions, so you invest buffer
      space only for connections that benefit from it
    
      Shep: I don't see any value in using the UTO option to *raise* the
      value of timeout, trying to see the value of *reducing* the value 
    
    - Changes
    - Are we done?
    
      Lars: Looking for folks to commit to reading the entire draft.
      Touch: I'll do it.
    
      Matt Mathis: basic semantics seem correct but the API needs work.
      Needs to be able to tell the stack whether you are negotiating up or
      down, lots of cases where it would be useful to negotiate this but you
      need to know which way the application would prefer.
    
      Anantha Ramaiah: what is the urgent need for this?
      Lars: comes from running TCP over disrupted links, like nomadic
      links
      Anantha Ramaiah: have you checked with mobile IP groups to see if they need
      it?
      Lars: still need it even without mobility
    
      Bob Braden: seems sensible; what would Jon Postel say?  The way you
      treat the information from this option is application specific, so
      it should be done at the application layer.  Jon was opposed to
      keep-alives for the same reason.
    
      Touch: rebutting Braden.  This is not a negotiation, TCP is just
      communicating the information to the other end; its the application
      that makes the decision on what to do.
    
        Ted: No, you are setting a default variable; if the application
        says 'I don't care', the default wins. So, it is TCP not
        application behavior.
    
      Shep: to Matt: Does putting something in TCP to signal this e2e help
      the situation?  I do believe there is a problem here, that the stack
      has a hard-wired timeout option and mobile users have a problem.
      TCP needs to be changed both on the mobile node and the server.
      What we need is that TCP has a mechanism to change the policy on the
      machine to raise the values.  Suggest this is a policy negotiation
      issue, not relevant to the value.  WG should publish a document on
      what the problem is.
    
      Randall Stewart: I like the idea of having more control.  This should be off
      by default.
    
    ============
    
    ICMP Attacks Against TCP - Fernando Gont (UTN/FRH)
    
    <>
    - Overview
    - Considerations
    - Mitigating the blind connection-reset attack
    - Mitigating the blind throughput-reduction attack
    - Mitigating the blind performance-degrading attack
    - Running Code
    - Issues Raised on the Mailing List
    - Moving Forward
    
      Matt Mathis: a version of this work is critically important;
      original documents were just informal implementation agreements;
      this document is taking current implementation processing and
      writing a standard around it; the code in the field is quite a bit
      different from what's in the original documents; haven't reviewed
      the actual code; the key issue is that this is a standards revision
      document, not a security document
    
      Anantha Ramaiah: support this as a working group item
    
      Touch: like the concept of this doc; but this current draft is spun
      wrong; wish the doc highlighted checking checksum, window,
      signature; need to be specific about not checking window when saying
      discussing staleness
    
        Fernando: current specs don't require including full packet to
        allow checking checksum and MD5 sig; *that's* the point
    
        Touch: then why do you think you can parse a TCP header if there
        is no valid checksum?
    
        Fernando: that it's more conservative to perform as
        many checks as possible on the received ICMP message (even if you
        were not able to check the checksum) than to simply honor the ICMP
        message without performing these checks. (It's not that it's the
        best thing you could do.... but for most ICMP messages you won't be
        able to check the checksum).
    
      Ted: I like tying the hard error/soft error check to validity checks
    
      Pekka Savola: important work and critical to IETF remaining
      relevant in TCP; agree with Matt; 
    
      John Heffner: like that this document documents the current implementer
      practice; may make a good Informational RFC; PTMU WG was working on
      something similar
    
        Fernando: may want to break PMTUD into two phases
    
     Ted: sense of the room on taking on this draft as a WG item.
    
       In favor of WG item: strong hum
       opposed: none
       
       Discussion
    
         Matt: another possible strategy is to completely rewrite the ICMP
         processing of 1122; out of scope of this WG but is what is really
         needed. 
    
           Ted: my digging shows that the material is sprinkled throughout
           the doc
    
         Gorry:  an Informational is good; but should we do a protocol spec
         here?  [ Specifically there are 2 issues, documenting current usage
         and proposals to change protocols and these may need to be
         separated into 2 documents if both issues are addressed. --
         clarification from Gorry ]
    
           Joe: This will have implications on DCCP and SCTP; should
           address it in a transport protocol-agnostic way; make this
           document more as an Informational on what is currently done;
           take the other issue to tsvwg;
    
           Fernando: DCCP and other protocols are handling this
           themselves
    
           Ted: would like an overarching document
    
           Touch: would volunteer to work on doc 
    
         Randall: in SCTP our strategy was to write a doc that noted all
         deviations of 1122 on ICMP handling, in all cases new behavior is
         more strict
    
         Lars: in DCCP this issues has not come up yet
    
         Aaron: actually it came up and decision was to let TCPM deal with
         it
    
    Ted: another hum "hum if you are in support of taking on this document
         as a...
         PS: weak
         info/BCP: strong
    
         Ted: Encourage folks to work on overarching document on ICMP handling,
         updating 1122 but in a WG where it is on topic, probably tsvwg.
    
    =============
    
    TCP's Reaction to Soft Errors -- Fernando Gont
    
    --<>
    - Overview
    - WG consensus
    - Moving forward
    
    Ted: who's read it?  ~3
    
    Fernando: though the consensus was to describe implementations
    
    Touch: would like to see more evidence that folks have read this *before* WGLC
    
    Matt: does this need to be separate from the previous document?
    
      Ted: yes, very different; last document was conservative, this one
      is more aggressive
    
      Matt: but both are just documenting current practices in ICMP and TCP 
    
      Pekka: goal of documents are different so should not be combined;
      but a common document on TCP and ICMP protocols would cover both
    
      Braden: too easy to create lots of documents without common view of
      the field; RFC793 would be six documents if done today.  Matt
      articulated a common goal that would absorb both.
    
    =============
    
    Authentication for TCP-based Routing and Management Protocols - Ron
    Bonica, Juniper
    
    --<>
    - (problem statement?)
    - Constraints Upon a Solution
    - Proposed Solution
    - Configuration
    - Receiving Station Procedure
    - Choosing Hash Algorithms
    
    Pekka: this may be useful but IMO it is good to remember that there
    may good reasons why this is not being used.
    
    Touch: in BTNS about why folks don't turn on TCP MD5; most reports
    focus on CPU utilization.  Do you have any measurements on relative
    weight.  (no.)  My previous experience is that SHA-1 is faster.
    Another issue is the having the ability to negotiation the keys on the
    fly.  Your architecture focuses on manually keying; I see this as a
    high hurdle to using this.  Would be preferable to have a mid-stream
    D-H negotiation than use a key chain.
    
      Ron Bonica: much of this process came from IPsec; we assume there
      are keys obtained somehow, and down the road we'll figure out how
      to deal with it eventually
    
      Touch: would like to see this addressed in *this* document.  you
      can't automatically key, you can't automatically re-key.  should fix
      in this doc.
    
    Matt:  this service is slightly above the transport layer that is
    really just generic out of band data.  Doesn't feel like there is a
    good fit between some of the semantics of your options and the key
    material.  
    
    Chandra, cisco: today we can change MD5 keys.  but you need to change
    the keys on both sides before expiration of the session.  So the issue
    is mostly operational.  Re: CPU utilization is not really relevant.
    Feel MD5 is not used because it is 'a little inconvenient'.
    
    David McGrew, Cisco, CFRG chair: great to see something other than
    keyed MD5 (which is essentially broken).  Should have a strong message
    authentication code, current mode should be deprecated.
    
      Ted: need to have a mandatory algorithm
    
      Bill: look to this group for advice on which one should be mandatory
    
      David: SHA-1 is facing deprecation from NIST
    
    Touch: CPU utilization: SHA-1 is a lot worse than MD5; not clear
    attacks are valid over the lifetime of the keys; prefer two mandatory
    algorithms: one strong algorithm and one (weak) fast one.  
    
    Randall: do you mention NTP?
    
      Bill: nope, no assumption on clocks
    
      Randall: if someone can scam your NTP they can adjust your time so
      two people can't talk since they would be on different keys
    
      Bill: this is why tolerance is a parameter
    
    Chandra: Key rollover and algorithm are independent and different
    problems.  We have draft on solving key rollover.
    
    Shep: are the mandatory pieces going to be mandatory parts of *TCP*?
    
      Ted: no, just as part of this option
    
    Pekka: would like to understand the goal here?  Is this a
    standards-track thing?  The proposal is probably insufficiently secure
    to be accepted by the IETF security community.  Perhaps just want to
    document it as informational or experimental.  
    
      Touch: biggest problem would be to call it the "TCP MD5 Option",
      calling it the TCP Security option would be more likely to succeed.
      need to address whether keying is inside the system or using IKE or
      what.  Not clear to me that this should NOT become standards track.
      Well, a standard option.
    
    Anantha Ramaiah: Issues I raised on the list need to be addressed, too.
    
    Ted: sense of the room.  
    
      Touch: wondering what the security communities reaction is?  Suggest
      taking the proposal to SAAG.
    
        Bill: sure
    
      Chandra: would like to see more written
    
      Al Morten, The Deathstar: this is an area of exposure, need to have
      this fixed soon.  Well studied is better than hasty.
    
      Shep: agree with Touch.  TCPM probably isn't the right place to
      evaluate the security properties.
    
      Chandra: what is the question for SAAG?
    
        Shep: SAAG needs to have a higher level discussion on how to solve
        this problem.
    
        Touch: Q: should we waste our time trying to fix the TCP security
        option?
    
    Ted: have people read this?  ~5
    
    ========
    
    The TCP ESTATS MIB - Matt Mathis, PSC
    
    --<>
    - TCP ESTATS MIB
    - Implementation Status
    - Plans Forward
    

    Slides

    Chairs' presentation
    Eggert & Gont UTO Overview
    ICMP attacks against TCP
    TCP's Reaction to Soft Errors
    Authentication for TCP-based Routing and Management Protocols
    TCP Extended Statistics MIB