[tcpm] minutes from Philly

Mark Allman <mallman@icir.org> Thu, 03 April 2008 18:51 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 44A353A6809; Thu, 3 Apr 2008 11:51:04 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id C37213A6DCE for <tcpm@core3.amsl.com>; Thu, 3 Apr 2008 11:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id yEaGFHrDMcaw for <tcpm@core3.amsl.com>; Thu, 3 Apr 2008 11:50:58 -0700 (PDT)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU []) by core3.amsl.com (Postfix) with ESMTP id 6C5203A6809 for <tcpm@ietf.org>; Thu, 3 Apr 2008 11:50:58 -0700 (PDT)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net []) by pork.ICSI.Berkeley.EDU ( with ESMTP id m33Ip1V8026686 for <tcpm@ietf.org>; Thu, 3 Apr 2008 11:51:02 -0700
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net []) by guns.icir.org (Postfix) with ESMTP id 782B41DD0BB4 for <tcpm@ietf.org>; Thu, 3 Apr 2008 14:49:52 -0400 (EDT)
Received: from lawyers.icir.org (localhost []) by lawyers.icir.org (Postfix) with ESMTP id 7D08147605F for <tcpm@ietf.org>; Thu, 3 Apr 2008 14:49:29 -0400 (EDT)
To: tcpm@ietf.org
From: Mark Allman <mallman@icir.org>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: Dreams
MIME-Version: 1.0
Date: Thu, 03 Apr 2008 14:49:29 -0400
Message-Id: <20080403184929.7D08147605F@lawyers.icir.org>
Subject: [tcpm] minutes from Philly
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1479727282=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


Attached are a first cut at minutes from the TCPM meeting in
Philadelphia.  Please let us know if there are corrections.  Also, there
is a "???" where there should be a name in the authentication option
discussion.  If that person could raise their hand, it'd be great.



TCP Maintenance and Minor Extensions WG
March 11, 2008, IETF-71
Minutes taken by Gorry Fairhurst

1. WG Status + Agenda bashing (10min)

  Mark Allman reviewed the Agenda.


    ECN-SYN has been sent to IESG

    Waiting for proto writeup by WG Chairs:

    TCP-Secure has been through WGLC. Applicability statement has
    been drafted, and recommendations need to be firmed-up. Did
    anyone object or have comments ion this topic? <no comments>

    Two new items of work were expected:
      Compound TCP (from ICCRG)
      Early Retransmit (to be verified as a TCPM Item by the WG)

    PSavola via jabber: What is the status of
    This needs some work, and has been languishing for some
    time. The WG Chairs don't have any update on the current
    status. Mark is looking for energy - offers of help from people
    interested. The Chairs will contact the author and check the

2. 2581bis update - Mark Allman

  Ted (on the list) considered this document has passed WGLC when
  the comments have been addresed. The authors think all changes
  have been implemented.

3. Advancing F-RTO - Pasi Sarolahti

  Pasi presented the draft. Lars said they had talked about F-RTO at
  the last meeting, and there was support for this going
  forward. Ted and Mark have discussed this and people seem to be
  liking this and the experience is good. We think we should start a
  WGLC after this meeting. There were no objections.

4. 1323bis - David Borman
  David said this now referenced RFC 2581. There was currently a
  null security considerations section. Joe Touch said we should
  identify issues. Matt Mathis - there could be security
  issues. Time Stamps can cause robustness issues. Eric Rescorla -
  see if this changes anything. Joe Touch - can the path
  change. Matt there is a robustness issue with middleboxes doing
  things they should not. Joe Touch: It was suggesting the
  middleboxes can protect only some headers, if you are protecting
  the TCP header, must this be included? Eric: The option could be
  removed on path (e.g. from the initial SYN), he will send
  comments. David will get back to the list with these comments. 

  Gorry: How appropriate are Jumbograms to a general internet
  David said this was really meant for point-to-point links, and not
   for the general Internet. Matt added the experimentation was 15
   years old. 

  PSavola:  One potential issue in RFC 1323bis: do we want to
   discuss the specifics how Timestamps option have been used in
   practice? (e.g., for signalling in the presence of SYN
   cookies. David had added text describing an offset. 
  David said that he would like to make a separate I-D on TCP MSS
  Mark said this sounds OK, people can comment if this needs to be
   done different. 

  Joe Touch: If you supply one example in section 3.3 on RTTM, this
   will become the default. David, we could choose an alternative
   RTTM implementation style. 
  Mark: A few people have solved this by changing the weights on the
  David said that he expected that this should then illustrate that
   there were multiple approaches. ... We should be careful that we
   don't suggest something that is too extreme, we need to support
   this with research. 
  Mark said there were published papers that talk about weight
  Joe said we should recommend alternatives that we know are safe -
   but not too much importance to one unless we know how to
  David said that he should tell people what to do, and not
   prescribe an algorithm. 
  Mark said we needed to keep the variance and adjust the gain based
   on the cwnd. 

  Hope to make the next version ready for a WGLC. Lars said we
  should add milestones for the two documents (Ted to do). 

  Mark: How many have read this version? (2).
  Mark: How many have read a version since we started updating 1323? (10).

5. TCP Authentication - Joe Touch

  Presented the draft to SAAG in Vancouver, and feedback from Eric
  Rescorla. Are we writing an applicability statement here? Joe said
  it was in the document.

  Eric: Does this system assume we do not do key management?  
  Joe said other people said this also. 
  Eric: there are a number of styles of key management: manual,
   external key management, inside TCP, etc. 
  The Design-Team seems convinced this does not fit in the space
   available, and must be established at SYN time, it starts
   authenticated and remains authenticated. 
  Eric this could possibly be wrong. 
  Joe said there was limited space in the SYN packet and then has to
   be consistent with the core of TCP. 
  Eric said I am not convinced. 
  Joe: There is a 40 Byte header in the SYN, but already used for
   TS, Window Scaling, and other things, at least half is already
   gone - if more than 15 bytes is needed, we are in trouble. 
  Eric: Be clear what is included and what is not included and say
  Lars said that in previous discussions the key management would be
   done in SAAG, but not that this would be done in the SYN option.

  Danny Macpherson: If there is the capability how will this be
   reconsidered - can we think about other non-routing protocol
  Joe said we need some sort of automated key management. 

  Joe: Do we need two documents for requirements and mechanism?
  Mark said he was not aware of the need for this, but if it made
   sense then we could split things up.

  ???: When you say asymmetric is not useful. I may want to be able
   to do this mid-connection. 
  Joe said the Design-Team said do not do this within the
  Eric said we should be clear what people want - this is not a
   replacement for TLS, it is DoS protection. 
  Joe, yes it protects the transport key. 
  Eric this means that we have prior arrangements, if either
   direction is DoSed then this attacks the connection. There is no
   management different between symmetric case and asymmetric, it's
   just performance - the keys are exchanged and then the packets are
  Brian Weis said this is just for routing.

  Eric: This issue is about cut and paste with the same port
   quartet. You need to be on the wire to do this attack. A pair-wise
   key per host pair is OK. 
  Joe said we could get this key from a key management system, SAAG
   mandated an automated key management system. The ISN may help. 
  Eric the state in the TCB is used, the first packet is protected
   by the master key and the ISN, this provides a way to bootstrap
   this. Would TS option help against replay attacks? 

  Eric and Joe discussed the relationship between the TSAD and TCB.

  Brian: The unkeyed case should result in silent reception. 
  Lars: default deny will result in loss of a connection, which is
  bad. The migration case is important. 
  Eric said if we turn on independently, then we need to handle
   this. This could be a case for asymmetric. 

  Eric: We need to be concerned about sequence number roll-over, and
   that the key should not be used for a large number of operations
   (although this is no longer true for modern MACs). We don't need
   to change the key. 
  Joe said the question was about coupling the ISN and MAC. One way
   is to synthesis a 64 bit sequence number, by counting the wraps of
   the sequence number space.

  There are pending modifications to the I-D. Joe said there was a
  list of open questions, all people were welcome to start
  discussions on this topic. 
tcpm mailing list