From fernando.gont.netbook.win@gmail.com  Mon Jun  1 23:13:29 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834263A6876; Mon,  1 Jun 2009 23:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.53
X-Spam-Level: 
X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GurYTANP-dkt; Mon,  1 Jun 2009 23:13:28 -0700 (PDT)
Received: from mail-qy0-f114.google.com (mail-qy0-f114.google.com [209.85.221.114]) by core3.amsl.com (Postfix) with ESMTP id 61F073A679F; Mon,  1 Jun 2009 23:13:28 -0700 (PDT)
Received: by qyk12 with SMTP id 12so928026qyk.29 for <multiple recipients>; Mon, 01 Jun 2009 23:13:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=DC4uBODSWbZI0f6Fjw5Cqb+e3ekhs5he0uRVFq0BPyY=; b=KoB4uUz65nEld3+Is62lCe8XHm+aWK3RXoC3cNn/lDPXmsESu9mt5YE5Mu5X0yRk/B kT+H7zOsUkzFwOJibGgj4xLw4w7sV59eVGmoVw9n3cJ0GY1YyrdtyLEz7rJZUxTpvXfI jtWlEUGnERPWLyf7Zp0wfOatvWM9MZdHd3jAM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=QVZQS4qb62NL6da+cCwMAcZFe6EGYDnsNOuAVjPICrJ2sal7rc15GBvVTzqC/LlZQ4 GNOoNZm0SgSjsen1RUZTXAQDCC5D5JGAyAwxyKAkcRhSa+Lm75Ic6EQU9AMQ4usFyoZZ YOPw3L9+EWzGViPXgJtj+PcCFuisoqmcEhNg4=
Received: by 10.224.2.199 with SMTP id 7mr6481398qak.336.1243923205390; Mon, 01 Jun 2009 23:13:25 -0700 (PDT)
Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 2sm713559qwi.33.2009.06.01.23.13.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 23:13:23 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A24626E.90805@gont.com.ar>
Date: Mon, 01 Jun 2009 20:21:18 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Lars Eggert <lars.eggert@nokia.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>
In-Reply-To: <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Joel Jaeggli <joelja@bogus.com>, opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 02 Jun 2009 06:13:29 -0000

Lars Eggert wrote:

>> P.S.: Is there any specific proposal/advice to pursue this effort?
>> There's has been some talk about tcpm vs opsec, but so far it is not
>> clear to me how to proceed here.
> 
> if the IETF decides to work on this, I believe TCPM would be the most
> appropriate group, given that that's where the TCP expertise is. I'm
> fully OK with doing this in cooperation with OPSEC, maybe via a joint WG
> last call or other means, if they desire this.

Any plans on how to proceed? So far we have version -00 of the
individual submission, but it's not clear to me how to proceed....



> One question: If the IETF decides to publish a document in this space,
> and if you decide to offer draft-gont-tcp-security as a starting point
> for this work, are the UK CNPI and you as the author OK with the IETF WG
> obtaining change control? The WG consensus process would likely lead to
> changes compared to the current version, probably even significant changes.

Both UK CPNI and me are OK with the document being modified to reflect
IETF consensus. However, we do expect me to continue as the document
author, and UK CPNI to continue as the author's affiliation (there's
nothing unusual with this... but considering that strictly speaking once
a document is accepted by a WG the author may be changed, I'm just
clarifying that while neither UK CPNI nor me have problems with the
document reflecting WG consensus, we do expect the author (Fernando
Gont) and the author's affiliation (UK CPNI) to remain "as is").

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






From wwwrun@core3.amsl.com  Tue Jun  2 09:42:31 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 885F83A6F07; Tue,  2 Jun 2009 09:42:31 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20090602164231.885F83A6F07@core3.amsl.com>
Date: Tue,  2 Jun 2009 09:42:31 -0700 (PDT)
Cc: tcpm chair <tcpm-chairs@tools.ietf.org>, tcpm mailing list <tcpm@ietf.org>, Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [tcpm] Document Action: 'Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets' to Experimental RFC
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 02 Jun 2009 16:42:31 -0000

The IESG has approved the following document:

- 'Adding Explicit Congestion Notification (ECN) Capability to TCP's 
   SYN/ACK Packets '
   <draft-ietf-tcpm-ecnsyn-10.txt> as an Experimental RFC

This document is the product of the TCP Maintenance and Minor Extensions 
Working Group. 

The IESG contact persons are Lars Eggert and Magnus Westerlund.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-ecnsyn-10.txt

Technical Summary

  This draft specifies a modification to RFC 3168 to allow TCP SYN/ACK
  packets to be ECN-Capable.  For TCP, RFC 3168 only specifies setting
  an ECN-Capable codepoint on data packets, and not on SYN and SYN/ACK
  packets.  However, because of the high cost to the TCP transfer of
  having a SYN/ACK packet dropped, with the resulting retransmit
  timeout, this document specifies the use of ECN for the SYN/ACK
  packet itself, when sent in response to a SYN packet with the two ECN
  flags set in the TCP header, indicating a willingness to use ECN.
  Setting the initial TCP SYN/ACK packet as ECN-Capable can be of great
  benefit to the TCP connection, avoiding the severe penalty of a
  retransmit timeout for a connection that has not yet started placing
  a load on the network.  The TCP responder (the sender of the SYN/ACK
  packet) must reply to a report of an ECN-marked SYN/ACK packet by
  resending a SYN/ACK packet that is not ECN-Capable.  If the resent
  SYN/ACK packet is acknowledged, then the TCP responder reduces its
  initial congestion window from two, three, or four segments to one
  segment, thereby reducing the subsequent load from that connection on
  the network.  If instead the SYN/ACK packet is dropped, or for some
  other reason the TCP responder does not receive an acknowledgement in
  the specified time, the TCP responder follows TCP standards for a
  dropped SYN/ACK packet (setting the retransmit timer).  This document
  updates RFC 3168

Working Group Summary

  The WG process on this document was fairly smooth.  The most
  interesting bump in the road was that after successfully completing
  the first WG last call, the authors obtained additional simulation
  results that warranted changes in the document and a 2nd WG last call.

Document Quality

  There are existing implementations.  There is (at least) a Linux
  implementation in addition to the simulation code.  No vendors
  have formally indicated plans to the WG to implement the
  modifications in the document, but it is a backwards compatible
  end-host modification, not a full new protocol or one requiring
  additional infrastructure support.

Personnel

  Wesley Eddy (weddy@grc.nasa.gov) was the document shepherd.
  Lars Eggert (lars.eggert@nokia.com) reviewed the document for the IESG.


From joelja@bogus.com  Wed Jun  3 13:49:02 2009
Return-Path: <joelja@bogus.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51003A6782; Wed,  3 Jun 2009 13:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHgZqch8mqR5; Wed,  3 Jun 2009 13:49:01 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id C68633A6AA8; Wed,  3 Jun 2009 13:48:40 -0700 (PDT)
Received: from [209.97.124.84] ([209.97.124.84]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id n53KlqTT049645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Jun 2009 20:48:34 GMT (envelope-from joelja@bogus.com)
Message-ID: <4A26E173.6040802@bogus.com>
Date: Wed, 03 Jun 2009 13:47:47 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Thunderbird 2.0.0.21 (X11/20090409)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar> <49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar> <88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com> <4A24626E.90805@gont.com.ar>
In-Reply-To: <4A24626E.90805@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.94.2/9418/Wed Jun 3 12:18:15 2009 on nagasaki.bogus.com
X-Virus-Status: Clean
Cc: opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 03 Jun 2009 20:49:02 -0000

It's a tough question. In part I think the answer is up to you, I think
there's some understanding on the part of tcpm that if this work were to
progress on a standards track that tcpm (no opsec) is the place for that
to happen. That said there's also some question as what sort of general
recommendations about hardening tcp would actually be consider
acceptable (in narrow use cases a lot more of them may well be).

	The diligent blacksmith knows that hardening a tool also
	makes it more brittle...

The result of any such effort is likely to be greatly different than
what you have today.

An alternative track would have the document headed for informational
status either as a working group document or as indivdual submission
with an understanding of what sort of advice is provided and who should
consider it and the limitations of implmentation based on it's
recomendations. It still think exposure to a working group is very
important and useful in this context, as a purely independant submission
it's simply documentary evidence of the uk cpni's effort's at
documenting some percieved flaws in tcp and recomned mitigation strategy
which is useful but not dramatically better than putting it on a website.

Fernando Gont wrote:
> Lars Eggert wrote:
> 
>>> P.S.: Is there any specific proposal/advice to pursue this effort?
>>> There's has been some talk about tcpm vs opsec, but so far it is not
>>> clear to me how to proceed here.
>> if the IETF decides to work on this, I believe TCPM would be the most
>> appropriate group, given that that's where the TCP expertise is. I'm
>> fully OK with doing this in cooperation with OPSEC, maybe via a joint WG
>> last call or other means, if they desire this.
> 
> Any plans on how to proceed? So far we have version -00 of the
> individual submission, but it's not clear to me how to proceed....
> 
> 
> 
>> One question: If the IETF decides to publish a document in this space,
>> and if you decide to offer draft-gont-tcp-security as a starting point
>> for this work, are the UK CNPI and you as the author OK with the IETF WG
>> obtaining change control? The WG consensus process would likely lead to
>> changes compared to the current version, probably even significant changes.
> 
> Both UK CPNI and me are OK with the document being modified to reflect
> IETF consensus. However, we do expect me to continue as the document
> author, and UK CPNI to continue as the author's affiliation (there's
> nothing unusual with this... but considering that strictly speaking once
> a document is accepted by a WG the author may be changed, I'm just
> clarifying that while neither UK CPNI nor me have problems with the
> document reflecting WG consensus, we do expect the author (Fernando
> Gont) and the author's affiliation (UK CPNI) to remain "as is").
> 
> Thanks!
> 
> Kind regards,

From wwwrun@core3.amsl.com  Thu Jun  4 12:08:57 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 703BE3A70E4; Thu,  4 Jun 2009 12:08:57 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20090604190857.703BE3A70E4@core3.amsl.com>
Date: Thu,  4 Jun 2009 12:08:57 -0700 (PDT)
Cc: tcpm@ietf.org
Subject: [tcpm] Last Call: draft-ietf-tcpm-rfc2581bis (TCP Congestion Control) to Draft Standard
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 04 Jun 2009 19:08:57 -0000

The IESG has received a request from the TCP Maintenance and Minor 
Extensions WG (tcpm) to consider the following document:

- 'TCP Congestion Control '
   <draft-ietf-tcpm-rfc2581bis-05.txt> as a Draft Standard

The implementation report supporting the advancement to Draft Standard
is at: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-06-18. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-05.txt

Implementation Report can be accessed at
http://www.ietf.org/IESG/implementation.html


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14183&rfc_flag=0


From root@core3.amsl.com  Thu Jun  4 13:30:02 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: tcpm@ietf.org
Delivered-To: tcpm@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 1456F3A6D61; Thu,  4 Jun 2009 13:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090604203002.1456F3A6D61@core3.amsl.com>
Date: Thu,  4 Jun 2009 13:30:02 -0700 (PDT)
Cc: tcpm@ietf.org
Subject: [tcpm] I-D Action:draft-ietf-tcpm-icmp-attacks-05.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 04 Jun 2009 20:30:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF.


	Title           : ICMP attacks against TCP
	Author(s)       : F. Gont
	Filename        : draft-ietf-tcpm-icmp-attacks-05.txt
	Pages           : 37
	Date            : 2009-06-04

This document discusses the use of the Internet Control Message
Protocol (ICMP) to perform a variety of attacks against the
Transmission Control Protocol (TCP) and other similar protocols.
Additionally, describes a number of widely implemented modifications
to TCP's handling of ICMP error messages that help to mitigate these
issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-icmp-attacks-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-tcpm-icmp-attacks-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-06-04132057.I-D@ietf.org>


--NextPart--

From touch@ISI.EDU  Sat Jun  6 11:46:22 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284A328C0D7 for <tcpm@core3.amsl.com>; Sat,  6 Jun 2009 11:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level: 
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h00npPMMRyLq for <tcpm@core3.amsl.com>; Sat,  6 Jun 2009 11:46:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 540A53A68BA for <tcpm@ietf.org>; Sat,  6 Jun 2009 11:46:21 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-106-86-44.lsanca.dsl-w.verizon.net [71.106.86.44]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n56IkAEf026658; Sat, 6 Jun 2009 11:46:12 -0700 (PDT)
Message-ID: <4A2AB973.3030203@isi.edu>
Date: Sat, 06 Jun 2009 11:46:11 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: tcpm Extensions WG <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Subject: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 06 Jun 2009 18:46:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

One open issue remaining is how to express what was formerly a database
with a particular structure (TAPD, previously TSAD) in ways that impact
rekeying and possibly future master key management protocols. We decided
at the last meeting in SFO to do as follows:

	- require that each segment match only one key
		- segments for established connections must match
		only one connection key
		- segments for new connections (SYNs) must match
		only one master key

Connection keys never overlap; there would never be two connection keys
with the same keyID and socket pair. The open issue focuses on master
keys, which would more likely be specified with wildcards, masks, or
ranges, esp. for remote port numbers, but also potentially for addresses
or local port numbers. This issue is particularly relevant for rekeying
- - adding new master keys that would result in new connection keys being
derived for existing connections - and how an endpoint would be able to
ensure uniqueness as above.

Do we need additional constraints to ensure that master key descriptions
never overlap?

As review, the previous description of keys as a database also implied,
by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
was:

    a socket pair descriptor
        which may include wildcards or masks

    one or more MKTs, each of which includes:
        sendID
        recvID
        crypto info:
            master key
            MAC info
            KDF info

The TAPD was defined so that a segment matched at most one socket pair
descriptor, and that MKTs within that descriptor had distinct sendIDs
and recvIDs.

If we remove that data structure, it would most obviously be replaced
with MKTs with their own socket descriptors, i.e.:

    MKT
        socket pair descriptor (may include wildcards/masks)
        sendID
        recvID
        crypto info

The question that remains is whether MKTs that match a segment all have
identical socket pair descriptors, even down to their
wildcards/ranges/masks (which was previously required). If
not, then how do we ensure that MKTs don't interfere?

If we throw our hands up and say this is "implementation detail", then
IMO we could be hobbling any KMP, since there would be no common data
for the KMP to coordinate.

So how do we proceed? If we ensure that MKTs that all apply to a given
segment all share the same socket pair descriptor, why can't we call
that a data structure and describe it? (is the issue just that we call
it a database?) If not, how do we describe the MKTs so that we can
enable KMPs?

Please post thoughts to this list.

Thanks,

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoquXMACgkQE5f5cImnZrvPdwCfZOKNvKpraJ5rp2cuIe89g7MU
9lwAn3qfA+dyY7+vtbA6+C6N3FJbBQis
=Yp3/
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun  9 00:32:35 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309D23A698D; Tue,  9 Jun 2009 00:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHJWI50KU+gn; Tue,  9 Jun 2009 00:32:34 -0700 (PDT)
Received: from mail-qy0-f111.google.com (mail-qy0-f111.google.com [209.85.221.111]) by core3.amsl.com (Postfix) with ESMTP id 0CB093A68EC; Tue,  9 Jun 2009 00:32:33 -0700 (PDT)
Received: by qyk9 with SMTP id 9so233716qyk.29 for <multiple recipients>; Tue, 09 Jun 2009 00:32:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=KYEMqfOea6pUREOtZo7Sx1JsCkUqwlLkzlHqvfj+RbY=; b=OZZuIn6VmzqGfJ0SKgqk2xzaEq4pomIIwYqXF13Ioq7m/E1IiOD2qMB7by5SZSPiSn o0BVJ1a89QWSZYuA1ajJ9X7fjlaPStDx/YowHLxqTjctDpGJg7PXI7+8JBuPd6Yvb8uf 3cFFEMJlPPUPaKnddzszFqiPaLYA8niilFOE8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Z9/GzxmVLFxTvyxhd/Z2AnLfgfgYRmw5vlh1Ko1zSrLMyWphgn+1TuoU+7GZmlPb9R ykIzokCVXvct99h8s/+WF5+66CLlvDL39cKwDuMqYzda3vDpcXXWpbSWo9X+0jxXD5oZ PG5tyqcaOK5Xe2OP21e9/NJfijPb2KZqYQo80=
Received: by 10.224.60.203 with SMTP id q11mr7718504qah.245.1244532756811; Tue, 09 Jun 2009 00:32:36 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 8sm981208qwj.34.2009.06.09.00.32.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 00:32:34 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A2E1008.4060303@gont.com.ar>
Date: Tue, 09 Jun 2009 04:32:24 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joel Jaeggli <joelja@bogus.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar>	<49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar>	<88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>	<4A24626E.90805@gont.com.ar> <4A26E173.6040802@bogus.com>
In-Reply-To: <4A26E173.6040802@bogus.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 09 Jun 2009 07:32:35 -0000

Hello, Joel,

Comments in-line...


> It's a tough question. In part I think the answer is up to you, I think
> there's some understanding on the part of tcpm that if this work were to
> progress on a standards track that tcpm (no opsec) is the place for that
> to happen.  

Ok. My proposal is, that unless there's any alternative proposal, I'd
like this document to be pursued as "Informational" within opsec.


> That said there's also some question as what sort of general
> recommendations about hardening tcp would actually be consider
> acceptable (in narrow use cases a lot more of them may well be).
> 
> 	The diligent blacksmith knows that hardening a tool also
> 	makes it more brittle...

This is a nice quote, but... I'd like examples. e.g., start discussing
about which specific hardening proposal makes TCP more brittle.


> The result of any such effort is likely to be greatly different than
> what you have today.

That's not a problem.



> An alternative track would have the document headed for informational
> status either as a working group document or as indivdual submission
> with an understanding of what sort of advice is provided and who should
> consider it and the limitations of implmentation based on it's
> recomendations. It still think exposure to a working group is very
> important and useful in this context, 


Ok. Good. As I mentioned, unless somebody else comes up with an
alternative proposal, I'd like the document to target "Informational" at
opsec. I guess that at some point tcpm may want to work on some of the
stuff in the document on a piecemeal basis.



> as a purely independant submission
> it's simply documentary evidence of the uk cpni's effort's at
> documenting some percieved flaws in tcp and recomned mitigation strategy
> which is useful but not dramatically better than putting it on a website.

-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun  9 06:43:25 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FD13A6912; Tue,  9 Jun 2009 06:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.164
X-Spam-Level: 
X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.435,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reyBbxFSvylM; Tue,  9 Jun 2009 06:43:24 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id ACB553A659B; Tue,  9 Jun 2009 06:43:24 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n59DgSiA014546; Tue, 9 Jun 2009 06:42:29 -0700 (PDT)
Message-ID: <4A2E66C3.6040701@isi.edu>
Date: Tue, 09 Jun 2009 06:42:27 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar>	<49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar>	<88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>	<4A24626E.90805@gont.com.ar>	<4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar>
In-Reply-To: <4A2E1008.4060303@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Joel Jaeggli <joelja@bogus.com>, opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 09 Jun 2009 13:43:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
...
>> That said there's also some question as what sort of general
>> recommendations about hardening tcp would actually be consider
>> acceptable (in narrow use cases a lot more of them may well be).
>>
>> 	The diligent blacksmith knows that hardening a tool also
>> 	makes it more brittle...
> 
> This is a nice quote, but... I'd like examples. e.g., start discussing
> about which specific hardening proposal makes TCP more brittle.

1) any security mechanism that increases complexity - of actions, state,
or message exchanges - any of which increases the potential for
implementation error

2) any security mechanism that has false positives, i.e., that discards
messages deemed a security threat when they were sent for legitimate reasons

#1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure
and ICMP filtering

#2 includes anything with nonzero false positives, such as tcpsecure and
ICMP filtering

I.e., AFAICT, *everything* that makes TCP more secure also makes it
brittle, by definition (ditto for metal hardening, FWIW). The key issue
is "when/where is the benefit worth the cost".

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkouZsMACgkQE5f5cImnZruBvACeIsbA4PwpE4xyp22+fGzH/5j2
9DYAoOCTLsrjZU7QcfCXsYq5TERlxcYY
=ycUl
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun  9 12:36:27 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6966A3A6D92; Tue,  9 Jun 2009 12:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYdiwOeAJAyb; Tue,  9 Jun 2009 12:36:26 -0700 (PDT)
Received: from mail-qy0-f111.google.com (mail-qy0-f111.google.com [209.85.221.111]) by core3.amsl.com (Postfix) with ESMTP id 4690A3A69E7; Tue,  9 Jun 2009 12:36:26 -0700 (PDT)
Received: by qyk9 with SMTP id 9so15608qyk.29 for <multiple recipients>; Tue, 09 Jun 2009 12:36:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=NJI+QIbrhFAwiVLpynQOjRx9LwceLecje5X6C5SY1tQ=; b=b7UardYZaLtBEji2MbmiA18fvRZAnmko/xlBcSY06NhjyM03iF4lsFI6opzY+elkqp otdSEFmtTkIDdmZ0lS5LQHKFfbsPJwCe//62WmlrXGqrDIcvHIlu0I+p89iSSBsUMKNS oqty53ZbclfNZgSZfswrYWs+nSIoDnAqfmEGA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=NMsA4sucpbglw/2ltxdTIj7ETqPqcEuMTTxPMTDWQgfokLRVT5969fY3n9H7+4e0/y pWuLM/ztkKI+Sok7U3kimRmlb33RYO/UrziE3a/Oitj4vKRFp90owE4pb7w898vSPJ0f 4z7j4XWKWqQOlnqSZw+ebNSKAMFjZ3nPY+55Q=
Received: by 10.220.100.5 with SMTP id w5mr679252vcn.62.1244576189828; Tue, 09 Jun 2009 12:36:29 -0700 (PDT)
Received: from ?190.48.216.129? ([190.48.216.129]) by mx.google.com with ESMTPS id 8sm90027ywg.53.2009.06.09.12.36.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 12:36:28 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A2EB9B7.80907@gont.com.ar>
Date: Tue, 09 Jun 2009 16:36:23 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar>	<49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar>	<88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>	<4A24626E.90805@gont.com.ar>	<4A26E173.6040802@bogus.com> <4A2E1008.4060303@gont.com.ar> <4A2E66C3.6040701@isi.edu>
In-Reply-To: <4A2E66C3.6040701@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Joel Jaeggli <joelja@bogus.com>, opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 09 Jun 2009 19:36:27 -0000

Joe Touch wrote:

>>> 	The diligent blacksmith knows that hardening a tool also
>>> 	makes it more brittle...
>> This is a nice quote, but... I'd like examples. e.g., start discussing
>> about which specific hardening proposal makes TCP more brittle.
> 
> 1) any security mechanism that increases complexity - of actions, state,
> or message exchanges - any of which increases the potential for
> implementation error

Agreed.



> 2) any security mechanism that has false positives, i.e., that discards
> messages deemed a security threat when they were sent for legitimate reasons

Why would this make e.g., TCP more brittle?

In any case, the actual response to such packets may vary (e.g., in the
case of ICMP hard errors, discard vs. process as soft errors). I believe
that no matter what the recommended response is, it is important to
discuss these issues, and try to get consensus on what's the right thing
to do in each case.


> #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure
> and ICMP filtering

ICMP filtering actually decreases complexity.



> I.e., AFAICT, *everything* that makes TCP more secure also makes it
> brittle, by definition (ditto for metal hardening, FWIW). The key issue
> is "when/where is the benefit worth the cost".

As I said before, I'd like to have concrete examples from the tcp
security i-d that are deemed to make TCP more brittle.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun  9 13:07:22 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2293A6847; Tue,  9 Jun 2009 13:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK3bRp46oSKg; Tue,  9 Jun 2009 13:07:22 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 980123A6841; Tue,  9 Jun 2009 13:07:10 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n59K6bob014863; Tue, 9 Jun 2009 13:06:38 -0700 (PDT)
Message-ID: <4A2EC0CD.3020505@isi.edu>
Date: Tue, 09 Jun 2009 13:06:37 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318F5E8@NDJSSCC01.ndc.nasa.g	ov><49E36AB9.40507@isi.edu>	<49E384E9.1050106@gont.com.ar><49E3878C.9080200@isi.edu>	<49E39119.1060902@gont.com.ar>	<B01905DA0C7CDC478F42870679DF0F1004BC4176D0@qtdenexmbm24.AD.QINTRA.COM>	<49E3A88F.9060301@gont.com.ar>	<49E3ABC0.1050601@isi.edu>	<49E3B9BF.1060901@gont.com.ar>	<49E3BED9.1030701@isi.edu>	<C9E987CC-0213-4C67-BA0A-11C736772EE7@nokia.com>	<49E4D257.40504@gont.com.ar>	<49E4E233.9040609@earthlink.net>	<EC5F7E6A-0393-41CC-B4DF-BCD134FF4EF5@nokia.com>	<49E5F36D.7020808@earthlink.net>	<A9D3331F-FDE6-4500-8650-3F94B0A78C2E@nokia.com>	<49EE1873.1090907@gont.com.ar>	<88ACD16A-1137-4E55-871F-8F0C992D7A63@nokia.com>	<4A24626E.90805@gont.com.ar>	<4A26E173.6040802@bogus.com>	<4A2E1008.4060303@gont.com.ar> <4A2E66C3.6040701@isi.edu> <4A2EB9B7.80907@gont.com.ar>
In-Reply-To: <4A2EB9B7.80907@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Joel Jaeggli <joelja@bogus.com>, opsec@ietf.org, tcpm@ietf.org
Subject: Re: [tcpm] [OPSEC]  draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 09 Jun 2009 20:07:23 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 	The diligent blacksmith knows that hardening a tool also
>>>> 	makes it more brittle...
>>> This is a nice quote, but... I'd like examples. e.g., start discussing
>>> about which specific hardening proposal makes TCP more brittle.
>> 1) any security mechanism that increases complexity - of actions, state,
>> or message exchanges - any of which increases the potential for
>> implementation error
> 
> Agreed.
> 
> 
> 
>> 2) any security mechanism that has false positives, i.e., that discards
>> messages deemed a security threat when they were sent for legitimate reasons
> 
> Why would this make e.g., TCP more brittle?

It makes a TCP that used to work not work anymore.

> In any case, the actual response to such packets may vary (e.g., in the
> case of ICMP hard errors, discard vs. process as soft errors). I believe
> that no matter what the recommended response is, it is important to
> discuss these issues, and try to get consensus on what's the right thing
> to do in each case.

Agreed. In a document that aimes to describe just what has been
implemented, there's no goal of gaining community consensus, though.
There is still utility, however, in providing the alternate viewpoint on
the potential impacts of implementations.

>> #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure
>> and ICMP filtering
> 
> ICMP filtering actually decreases complexity.

It requires more code to check that an ICMP is in-window than to not
check. Nearly everything requires more code, at least.

>> I.e., AFAICT, *everything* that makes TCP more secure also makes it
>> brittle, by definition (ditto for metal hardening, FWIW). The key issue
>> is "when/where is the benefit worth the cost".
> 
> As I said before, I'd like to have concrete examples from the tcp
> security i-d that are deemed to make TCP more brittle.

I did above in both cases.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKLsDME5f5cImnZrsRAlGWAKCzYpIm7avI7zCezK/qr6+YOmLzogCg+hQe
miDFj33au36GsANaWpxiM4w=
=6lOt
-----END PGP SIGNATURE-----

From wesley.m.eddy@nasa.gov  Wed Jun 10 21:25:05 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2C73A6839 for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.381
X-Spam-Level: 
X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhJyk4UNz2k3 for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:25:03 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 91C7B3A680A for <tcpm@ietf.org>; Wed, 10 Jun 2009 21:25:03 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id A336A328043; Wed, 10 Jun 2009 23:25:10 -0500 (CDT)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5B4PAA4020883; Wed, 10 Jun 2009 23:25:10 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 10 Jun 2009 23:25:10 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Date: Wed, 10 Jun 2009 23:25:15 -0500
Thread-Topic: comments on draft-ietf-tcpm-icmp-attacks-05
Thread-Index: AcnqTJ5N/OQHUFfvTA+OQMGvgkY7Qg==
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-10_14:2009-06-01, 2009-06-10, 2009-06-10 signatures=0
Cc: Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 04:25:06 -0000

As a WG participant (not co-chair), here are some
comments I have after reading the latest version
of the ICMP attacks draft:

1) (editorial) In Section 2.1, don't capitalize
"Architecture", as it makes "Internet Architecture"
look like some kind of specific proper noun, which
it definitely isn't.

2) (question) In Section 2.1, we have:
"When an intermediate router detects a network
problem while trying to forward an IP packet,
it will usually send an ICMP ..."  Do we
want "will usually" or "has the option to", or
something similar?  I'm not aware of the actual
statistics on this.

3) (editorial) In Section 3, first sentence,
"internet header" -> "IP header" ?

4) (technical) For the last paragraph in section
3, we focus on the lack of IKE usage as a reason
why IPsec can't generally be used to authenticate
ICMP messages, but I think the bigger problem is
that even if we all ran IPsec, we'd need to have
routers using certificates with paths compatible
for all other hosts on the network ... not too
feasible from what I can tell.  I think this is
more difficult than either the deployment or the
embedded devices issue that the draft mentions.

5) (general) Section 5.1, last paragraph, it
seems like we should be mentioning TCP-AO as
well here, though I don't think it changes any
part of the claim.

6) (editorial) Section 5.2, typo "preferebable"

7) (editorial) Section 6.2, "On the other hand,
TCP implements its own congestion control
mechanisms ..." ... I don't think this is
really an "on the other hand", I think it's
more of a "Furthermore".

8) (general) In Section 6.2, I think we can be
stronger and say that the 1122 requirement to
react to source quench is no longer pertinent,
as the Internet has moved well beyond needing
this.

9) (general) Wow, section 7 takes a much closer
look at PMTUD than I ever expected to find here;
roughly half the document sits in this topic
alone.  Is this *really* an attack that we're
that worried about in a general case? =20

The modifications in this part of the document
seem too complex for what they buy, to me.  It
seems like in places where there's concern about
it, we can just say to ignore these ICMPs and use
the PLPMTUD (4821) instead.  I can understand
that what's in the draft has been implemented,
but how valuable is it really when we already
have a Proposed Standard in PLPMTUD that can
totally answer to this concern by just ignoring
the ICMPs in question?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From wesley.m.eddy@nasa.gov  Wed Jun 10 21:32:46 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18F03A6858 for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level: 
X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO3icUQnd5IM for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:32:45 -0700 (PDT)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id 6EEA83A680A for <tcpm@ietf.org>; Wed, 10 Jun 2009 21:32:45 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id A3AD62D81E3; Wed, 10 Jun 2009 23:32:52 -0500 (CDT)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5B4Wq3c000638; Wed, 10 Jun 2009 23:32:52 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 10 Jun 2009 23:32:52 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>, "tcpm@ietf.org" <tcpm@ietf.org>
Date: Wed, 10 Jun 2009 23:32:57 -0500
Thread-Topic: comments on draft-ietf-tcpm-icmp-attacks-05
Thread-Index: AcnqTJ5N/OQHUFfvTA+OQMGvgkY7QgAAJlzg
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-10_14:2009-06-01, 2009-06-10, 2009-06-10 signatures=0
Cc: Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 04:32:46 -0000

As both co-chair and TCPM participant, I'm not really
comfortable with Appendix B of this document which
reads a lot like an advertisement.  Even though I
know it's well-intentioned, it seems like we'd set
a bad precedent if we got into the habit of putting
sponsor-plugs into the appendices of our documents.
I don't think we lose anything by leaving that
appendix out completely.

What does the WG think?



To speed analysis, the text in question is:

Appendix B. Advice and guidance to vendors


   Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
   think they may be affected by the issues described in this document.
   As the lead coordination center for these issues, CPNI is well placed
   to give advice and guidance as required.

   CPNI works extensively with government departments and agencies,
   commercial organizations and the academic community to research
   vulnerabilities and potential threats to IT systems especially where
   they may have an impact on Critical National Infrastructure's (CNI).

   Other ways to contact CPNI, plus CPNI's PGP public key, are available
   at http://www.cpni.gov.uk .

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From wesley.m.eddy@nasa.gov  Wed Jun 10 21:45:48 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A6C3A6D2B for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.49
X-Spam-Level: 
X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fCV8J-R4gZJ for <tcpm@core3.amsl.com>; Wed, 10 Jun 2009 21:45:46 -0700 (PDT)
Received: from ndjsnpf03.ndc.nasa.gov (ndjsnpf03.ndc.nasa.gov [198.117.1.123]) by core3.amsl.com (Postfix) with ESMTP id B8D6B3A6D1E for <tcpm@ietf.org>; Wed, 10 Jun 2009 21:45:46 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf03.ndc.nasa.gov (Postfix) with ESMTP id A45362D861E; Wed, 10 Jun 2009 23:45:53 -0500 (CDT)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5B4jrss005933; Wed, 10 Jun 2009 23:45:53 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Wed, 10 Jun 2009 23:45:53 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>, "tcpm@ietf.org" <tcpm@ietf.org>
Date: Wed, 10 Jun 2009 23:45:59 -0500
Thread-Topic: comments on draft-ietf-tcpm-icmp-attacks-05
Thread-Index: AcnqTJ5N/OQHUFfvTA+OQMGvgkY7QgAAZwrg
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-10_14:2009-06-01, 2009-06-10, 2009-06-10 signatures=0
Cc: Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 04:45:48 -0000

As both a WG-participant and co-chair, I think that the
Appendix A explanations of which ICMPs need to be paid
attention to because some of them say things that I'm
not sure are totally supported by prior RFCs.  For
instance, I'm not certain that setting the DF bit is
only possible for hosts that support PMTUD ... is there
a reference for that?  Further, it discusses ambiguity
in 1122, that we should be clarifying in the main text
rather than an appendix, I think ... what does the rest
of the WG think?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------



From fernando.gont.netbook.win@gmail.com  Thu Jun 11 01:22:50 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE883A6C5E for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 01:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Level: 
X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.535,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMp3wZE7Egqe for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 01:22:49 -0700 (PDT)
Received: from mail-qy0-f116.google.com (mail-qy0-f116.google.com [209.85.221.116]) by core3.amsl.com (Postfix) with ESMTP id 732353A6BCE for <tcpm@ietf.org>; Thu, 11 Jun 2009 01:22:49 -0700 (PDT)
Received: by qyk14 with SMTP id 14so23571qyk.29 for <tcpm@ietf.org>; Thu, 11 Jun 2009 01:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=5k4C9RdNOyTYeif+mS1UOwWaQEAlyFLPsbjRbLxiJUo=; b=bHas6bicsakfjyXHGMqrcZ8ZxjRN+HuYoxgtUDXuLa5CtV6cOPKQOlG48ibU0u428L G5ct48W/uNmKpoKyKEuWG+YeqDRM84x/1867/9Iawe+823MBN4/dgKmjVMgHHgKVspQT QS4HmC5R+ukXChtLNwoyx1FcadXNxaN+Ybogk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=mR9noGlAasL63ofa88szXAq/iMrRh0Eop1aeNhWGjBiU/7ge0d/At4f7NMLtsnFyfI gZ8Mdbm4rvYtGPP7d5k0H6JDkW5IeNf53fi/IGpXX8g6qpLSTUEYNkDJhc2ZFzT9mQrV bw5ZFOrTVMJgzfPXFKQ2uTl4NmDyUL9eccqag=
Received: by 10.224.37.7 with SMTP id v7mr2884807qad.35.1244708574490; Thu, 11 Jun 2009 01:22:54 -0700 (PDT)
Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 7sm1291265qwf.49.2009.06.11.01.22.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 01:22:53 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A30BED6.3050308@gont.com.ar>
Date: Thu, 11 Jun 2009 05:22:46 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 08:22:50 -0000

Hello, Wesley,

Thanks so much for your feedback. Comments-inline...


> 1) (editorial) In Section 2.1, don't capitalize
> "Architecture", as it makes "Internet Architecture"
> look like some kind of specific proper noun, which
> it definitely isn't.

I think this was capitalized in Dave's Clark paper. But have no problem
with the proposed change.



> 2) (question) In Section 2.1, we have:
> "When an intermediate router detects a network
> problem while trying to forward an IP packet,
> it will usually send an ICMP ..."  Do we
> want "will usually" or "has the option to", or
> something similar?  I'm not aware of the actual
> statistics on this.

The router will send an ICMP error message, unless rate-limiting
prevents it. That's my understanding. And this is what RFC 1812 states.



> 3) (editorial) In Section 3, first sentence,
> "internet header" -> "IP header" ?

Will do. (Although the ICMP spec uses the term "internet header" rather
than "IP header").




> 4) (technical) For the last paragraph in section
> 3, we focus on the lack of IKE usage as a reason
> why IPsec can't generally be used to authenticate
> ICMP messages, but I think the bigger problem is
> that even if we all ran IPsec, we'd need to have
> routers using certificates with paths compatible
> for all other hosts on the network ... 

Sorry. You meant that all the routers in the path should be using
certificates?


> not too
> feasible from what I can tell.  I think this is
> more difficult than either the deployment or the
> embedded devices issue that the draft mentions.

Agreed.



> 5) (general) Section 5.1, last paragraph, it
> seems like we should be mentioning TCP-AO as
> well here, though I don't think it changes any
> part of the claim.

Agreed. Maybe this is also an indication that TCP-AO *should* change
something in this respect!



> 6) (editorial) Section 5.2, typo "preferebable"

Will do.



> 7) (editorial) Section 6.2, "On the other hand,
> TCP implements its own congestion control
> mechanisms ..." ... I don't think this is
> really an "on the other hand", I think it's
> more of a "Furthermore".

Will do. ("english as a second language" here. :-( )



> 8) (general) In Section 6.2, I think we can be
> stronger and say that the 1122 requirement to
> react to source quench is no longer pertinent,
> as the Internet has moved well beyond needing
> this.

I fully agree with you. However, at some point in the past there was all
these discussions that the document was "going against the standards",
and that it was "too strong", being an "Informational" document. Hence
it's not as strong as I would have liked it to be.

That said, the internet has moved beyond reseting established
connections in response to hard errors, too. :-)



> 9) (general) Wow, section 7 takes a much closer
> look at PMTUD than I ever expected to find here;
> roughly half the document sits in this topic
> alone.  

Yes. And it could have been worse. Because for the other two
vulnerabilities, it all boils down to "ignore source quenches" and
"process hard errors as soft errors if they are received for connections
in any of the synchronized states". But you cannot ignore "frag needed"
messages.


> Is this *really* an attack that we're
> that worried about in a general case?  

Yes. See the "Acknowledgement" section of the I-D -- it was reviewed by
people from Free', Net', and OpenBSD, Solaris and opensolaris, Cisco,
Extremenetworks, and others. Yes, that's not the world... but I'd argue
that a good sample.

Without the TCP seq check, is trivial (and with an advertised MTU of 0
it even crashed some implementations). With the TCP SEQ check, things
are not so bad... but the windows keep increasing.

That said, the document is informational, and documents what has been
done in the industry. And the stuff in Section 7 is implemented in a
number of systems and deployed already in the Internet.



> The modifications in this part of the document
> seem too complex for what they buy, to me.  

I did the patch myself for OpenBSD in a few hours (and it was probably
my first commit to the tree). Conceptually speaking, it's even simpler:
Before you know data has successfully been transferred to the remote
endpoint, just validate the ICMP error messages by checking the TCP SEQ.
Once you have successfully transferred data, check for progress on the
connection before honoring the ICMP error messages).



> It
> seems like in places where there's concern about
> it, we can just say to ignore these ICMPs and use
> the PLPMTUD (4821) instead.  I can understand
> that what's in the draft has been implemented,
> but how valuable is it really when we already
> have a Proposed Standard in PLPMTUD that can
> totally answer to this concern by just ignoring
> the ICMPs in question?

I have already been told by a number of developers that they would not
implement the ICMP-free version of PLPMTUD, because of its convergence
time. They are more willing to implement it for icmp blackhole detection.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando.gont.netbook.win@gmail.com  Thu Jun 11 01:30:15 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DCB3A6853 for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 01:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level: 
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM2L02lhJnGK for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 01:30:14 -0700 (PDT)
Received: from mail-qy0-f116.google.com (mail-qy0-f116.google.com [209.85.221.116]) by core3.amsl.com (Postfix) with ESMTP id 34CFA3A6803 for <tcpm@ietf.org>; Thu, 11 Jun 2009 01:30:14 -0700 (PDT)
Received: by qyk14 with SMTP id 14so23780qyk.29 for <tcpm@ietf.org>; Thu, 11 Jun 2009 01:30:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=LYtbSzvp5TY5U0kPBY+QIWlL5HaUdMGkWy7e2dwHpWg=; b=sTRgEQaZK3z3SyvDYxEPN+BFlEabefF6eqAeKppPL87lS6GFcuKNV1+cJJqfZE+uA5 MOhsYzhxFPz4kmLoEAkvFy1WN5zqaUH6rsYxc2D3l7N6cmHCetHO/rFrbiabuErAptfM /RIz7yj9Ss0XuYM1H/LuKnaoeQCpdZLyLwTfg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=SJ/1ct1Hk3GwXLsLdLz6U3u7gMYIrcjWh17mwOR4aF5Nkkq38Lik6LnirpUqbr66TZ EbqgenASSuWwLInIZx805XuNukablpeC1Z3Td8bB4H7zvRQgreLJ+D4fMFkj3LvNcPVd QppRB+7rqFwqWg+OuCPx2jfIJyp1Jmk+rvfCI=
Received: by 10.224.74.84 with SMTP id t20mr2859023qaj.328.1244709019418; Thu, 11 Jun 2009 01:30:19 -0700 (PDT)
Received: from ?192.168.0.151? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 7sm1800296qwb.46.2009.06.11.01.30.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Jun 2009 01:30:18 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A30C093.5060408@gont.com.ar>
Date: Thu, 11 Jun 2009 05:30:11 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 08:30:15 -0000

Hello, Wes,

Comments in-line....

> As both a WG-participant and co-chair, I think that the
> Appendix A explanations of which ICMPs need to be paid
> attention to because some of them say things that I'm
> not sure are totally supported by prior RFCs.  

Any specific issues?


> For
> instance, I'm not certain that setting the DF bit is
> only possible for hosts that support PMTUD ... is there
> a reference for that?  

What's the reason for setting the DF flag for IP packets carrying TCP
segments if you don't implement PMTUD?

Actually, if you don't implement PMTUD, "frag needed" becomes a hard
error. So setting the DF flag would be sort of dumb, as in the event one
of your segments needs to be fragmented, you'd received an ICMP "frag
needed" message, which would reset your connection.



> Further, it discusses ambiguity
> in 1122, that we should be clarifying in the main text
> rather than an appendix, I think ... what does the rest
> of the WG think?

The appendix was at some point part of the main text. I moved the text
into an appendix probably on request of somebody, but not because I
thought the text should be there. So I have no problem moving the
entirre appendix (or part of it) back into the main part of the document.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From gf@erg.abdn.ac.uk  Thu Jun 11 03:58:30 2009
Return-Path: <gf@erg.abdn.ac.uk>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BF228C1BB for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 03:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rTu+ufmy-FH for <tcpm@core3.amsl.com>; Thu, 11 Jun 2009 03:58:29 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id F0FFD28C193 for <tcpm@ietf.org>; Thu, 11 Jun 2009 03:58:28 -0700 (PDT)
Received: from 24-237-wf.tnc2009.rediris.es (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n5BAwTlU008456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 11 Jun 2009 11:58:30 +0100 (BST)
Message-ID: <4A30E355.1040704@erg.abdn.ac.uk>
Date: Thu, 11 Jun 2009 12:58:29 +0200
From: Gorry Fairhurst <gf@erg.abdn.ac.uk>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: David Borman <dab@weston.borman.com>, tcpm@ietf.org
References: <4A12C9C9.9060404@gont.com.ar> <FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>
In-Reply-To: <FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gf@erg.abdn.ac.uk
Cc: tcpm-chairs@tools.ietf.org
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 11 Jun 2009 10:58:30 -0000

I supported this in the meeting, and still do.

I think a statement that this not recommended for new applications (3) 
is good, combined with (4).

Best wishes,

Gorry

David Borman wrote:
> I think I forgot to follow up on this, sorry!
>
> So, with my WG co-chair hat on:
>
> The agreement at the San Francisco IETF meeting on the Urgent Pointer 
> definition was:
>
> 1) Adopt this document as a WG item
>
> 2) Change the definition of the Urgent Pointer (defined in RFC 1122) 
> to match the definition on page 17 of RFC 793, which is what most 
> implementations use.
>
> 3) New applications should be discouraged from using the Urgent Pointer
>
> 4) TCP implementations still need to implement the Urgent Pointer for 
> existing applications that use it
>
> 5) All applications that do make use of the Urgent Pointer must use 
> the SO_OOBINLINE socket option to keep all of the data in sequence; 
> applications that don't use SO_OOBINLINE and continue to use the old, 
> broken BSD implementation that actually removes bytes of data from 
> data stream are out of scope for the IETF, since that is not part of 
> the TCP protocol.
>
> Please respond with whether you do or do not support adopting this as 
> a WG item, even if you were at the meeting, so that we have a record 
> on the mailing list.
>
>
> Now with my WG chair hat off:
>
> I support adopting this as a WG item.
>
>             -David Borman, TCPM WG co-chair
>
>
>
> On May 19, 2009, at 10:01 AM, Fernando Gont wrote:
>
>> Hello, folks,
>>
>> I'm planning to work on a revision of the urgent data I-D anytime soon.
>> I was wondering if there are any plans for proceeding with this I-D.
>>
>> There was some discussion on-list about TCP urgent data, and IIRC Dave
>> Borman had suggested (hat off) that this I-D be adopted as a WG item.
>>
>> Thoughts? Plans?
>>
>> Thanks!
>>
>> Kind regards,
>> -- 
>> Fernando Gont
>> e-mail: fernando@gont.com.ar || fgont@acm.org
>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>
>


From touch@ISI.EDU  Fri Jun 12 13:41:25 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D72D3A68EB for <tcpm@core3.amsl.com>; Fri, 12 Jun 2009 13:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCRpIdCmlzq5 for <tcpm@core3.amsl.com>; Fri, 12 Jun 2009 13:41:24 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 27FF63A68BC for <tcpm@ietf.org>; Fri, 12 Jun 2009 13:41:24 -0700 (PDT)
Received: from [75.213.50.109] (109.sub-75-213-50.myvzw.com [75.213.50.109]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5CKf4YI028383; Fri, 12 Jun 2009 13:41:07 -0700 (PDT)
Message-ID: <4A32BD5F.5030503@isi.edu>
Date: Fri, 12 Jun 2009 13:41:03 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <4A30BED6.3050308@gont.com.ar>
In-Reply-To: <4A30BED6.3050308@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 12 Jun 2009 20:41:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
...
>> 5) (general) Section 5.1, last paragraph, it
>> seems like we should be mentioning TCP-AO as
>> well here, though I don't think it changes any
>> part of the claim.
> 
> Agreed. Maybe this is also an indication that TCP-AO *should* change
> something in this respect!

TCP-AO already addresses ICMP attacks in the security considerations
section, and requires there to be a way to disable reaction to ICMPs.
Like IPsec, though, we don't make a-priori assessments as to whether
ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
is used.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoyvV8ACgkQE5f5cImnZruTxACeO2Q8KULcvKQOK07tBxmHiPNa
Gr0An1RGq74/6xx4XlQ1Sz3XcvGwGuEU
=aMxa
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Fri Jun 12 13:45:04 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C35313A68EB for <tcpm@core3.amsl.com>; Fri, 12 Jun 2009 13:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.775
X-Spam-Level: 
X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_00=-2.599, FRT_TODAY2=1.648]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSOddx2miDrT for <tcpm@core3.amsl.com>; Fri, 12 Jun 2009 13:45:03 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E267D3A68BC for <tcpm@ietf.org>; Fri, 12 Jun 2009 13:45:03 -0700 (PDT)
Received: from [75.213.50.109] (109.sub-75-213-50.myvzw.com [75.213.50.109]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5CKiwUJ029246; Fri, 12 Jun 2009 13:45:00 -0700 (PDT)
Message-ID: <4A32BE4A.1090903@isi.edu>
Date: Fri, 12 Jun 2009 13:44:58 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov> <4A30C093.5060408@gont.com.ar>
In-Reply-To: <4A30C093.5060408@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 12 Jun 2009 20:45:04 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
...
>> For
>> instance, I'm not certain that setting the DF bit is
>> only possible for hosts that support PMTUD ... is there
>> a reference for that?  
> 
> What's the reason for setting the DF flag for IP packets carrying TCP
> segments if you don't implement PMTUD?

There are systems that just don't want to implement reassembly, due to
the cost and potential for the attack at the receiver of receiving large
numbers of partial packets. small devices do this to save
compute/storage space - the Sony CLIE was one of these a few years ago,
even though PMTUD was common even at the time.

> Actually, if you don't implement PMTUD, "frag needed" becomes a hard
> error. So setting the DF flag would be sort of dumb, as in the event one
> of your segments needs to be fragmented, you'd received an ICMP "frag
> needed" message, which would reset your connection.

That's what happened when running TCP from a CLIE over a tunnel. Not
desirable from the user's view, but definitely intended.

>> Further, it discusses ambiguity
>> in 1122, that we should be clarifying in the main text
>> rather than an appendix, I think ... what does the rest
>> of the WG think?

This doc should not be clarifying anything in 1122 - that, IMO, would be
for a standards-track doc, not an informational.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoyvkoACgkQE5f5cImnZrvn6gCfTPEk9wRTfXTxFT5Lmj44lx21
k+MAoIhEwTg0vY+T0dojcGGD9u9GEsyH
=iPPb
-----END PGP SIGNATURE-----

From wesley.m.eddy@nasa.gov  Sat Jun 13 08:42:11 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C5028C0DF for <tcpm@core3.amsl.com>; Sat, 13 Jun 2009 08:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level: 
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4Aa9+QgS9fR for <tcpm@core3.amsl.com>; Sat, 13 Jun 2009 08:42:10 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 5C5B428C0DC for <tcpm@ietf.org>; Sat, 13 Jun 2009 08:42:10 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 087923280C7; Sat, 13 Jun 2009 10:42:19 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5DFgI7i025088; Sat, 13 Jun 2009 10:42:18 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Sat, 13 Jun 2009 10:42:19 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Fernando Gont <fernando@gont.com.ar>
Date: Sat, 13 Jun 2009 10:42:26 -0500
Thread-Topic: comments on draft-ietf-tcpm-icmp-attacks-05
Thread-Index: AcnqbtvMta3haP3uS+WiqVnJlgQglABzNapg
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB221796DDB4@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov> <4A30C093.5060408@gont.com.ar>
In-Reply-To: <4A30C093.5060408@gont.com.ar>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-13_02:2009-06-01, 2009-06-13, 2009-06-12 signatures=0
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 13 Jun 2009 15:42:11 -0000

>-----Original Message-----
>From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On
>Behalf Of Fernando Gont
>Sent: Thursday, June 11, 2009 4:30 AM
>Hello, Wes,
>
>> As both a WG-participant and co-chair, I think that the
>> Appendix A explanations of which ICMPs need to be paid
>> attention to because some of them say things that I'm
>> not sure are totally supported by prior RFCs.
>
>Any specific issues?


I'll go one-by-one through them and follow up with any in
addition to the one we already started talking about:


>> For
>> instance, I'm not certain that setting the DF bit is
>> only possible for hosts that support PMTUD ... is there
>> a reference for that?
>
>What's the reason for setting the DF flag for IP packets carrying TCP
>segments if you don't implement PMTUD?


I know of a number of embedded OS kernels and real-time systems
that either don't implement IP reassembly or disable it.  Some
of the stacks geared towards real-time will also set DF on the
packets that they send as the frag/reassembly is presumed to be
an impediment to guaranteeing their delay bounds.


>> Further, it discusses ambiguity
>> in 1122, that we should be clarifying in the main text
>> rather than an appendix, I think ... what does the rest
>> of the WG think?
>
>The appendix was at some point part of the main text. I moved the text
>into an appendix probably on request of somebody, but not because I
>thought the text should be there. So I have no problem moving the
>entirre appendix (or part of it) back into the main part of the
>document.


Oh, I didn't realize we'd already juggled it around :).
It makes sense to me to analyze the different message
types this way as motivation for the recommendations on
how to treat them, which is why I expected it to be in
the body, but if there was already consensus to have it
as an appendix, then that's fine too.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From fernando.gont.netbook.win@gmail.com  Sat Jun 13 17:32:41 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425923A6800 for <tcpm@core3.amsl.com>; Sat, 13 Jun 2009 17:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Vu0Ie04H5Io for <tcpm@core3.amsl.com>; Sat, 13 Jun 2009 17:32:40 -0700 (PDT)
Received: from mail-qy0-f125.google.com (mail-qy0-f125.google.com [209.85.221.125]) by core3.amsl.com (Postfix) with ESMTP id 3C6B83A6904 for <tcpm@ietf.org>; Sat, 13 Jun 2009 17:32:40 -0700 (PDT)
Received: by qyk31 with SMTP id 31so101635qyk.29 for <tcpm@ietf.org>; Sat, 13 Jun 2009 17:32:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=SvyLD8EmofJSA/YZufGEqkGzgplnO/5R6n680OODM6o=; b=oP9fYRqEaPVg29WrAcVxO/p0iV7l96v/dKtAOTlYwnA2BTLPjNVb23hPhAkhEYKxKJ mH1EXKHqq6b8oIXWy87yw9NFEzxMqa3JXSX5+w5p30TgueJDgQACI6Uu3WtRfCeS/oXc M0Ftwkicp75+x2oICGkIudtxp8t4UsSLphdFg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=E+mFzlJpe/FzsroEJxoNI2gER/jUr6nIJfKzddBLx3MK3/izAilE3fV6C/bwg3lJYx Cjn0SQ4akZh56xikF+Mxt0q3NWuh+OSuwBdIAy//jUC2T+2Ch7EEMfSZVyhGhGQDuSF4 DDgtl00nRf77amEKKabCQZoPHCJxdtG5b50u4=
Received: by 10.224.60.194 with SMTP id q2mr5859508qah.135.1244939566149; Sat, 13 Jun 2009 17:32:46 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 7sm1579315qwf.19.2009.06.13.17.32.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Jun 2009 17:32:45 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A344528.5060907@gont.com.ar>
Date: Sat, 13 Jun 2009 21:32:40 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov> <4A30C093.5060408@gont.com.ar> <C304DB494AC0C04C87C6A6E2FF5603DB221796DDB4@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796DDB4@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sun, 14 Jun 2009 00:32:41 -0000

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

>>> For
>>> instance, I'm not certain that setting the DF bit is
>>> only possible for hosts that support PMTUD ... is there
>>> a reference for that?
>> What's the reason for setting the DF flag for IP packets carrying TCP
>> segments if you don't implement PMTUD?
> 
> I know of a number of embedded OS kernels and real-time systems
> that either don't implement IP reassembly or disable it.  Some
> of the stacks geared towards real-time will also set DF on the
> packets that they send as the frag/reassembly is presumed to be
> an impediment to guaranteeing their delay bounds.

What do these systems do when they receive a "frag needed" ICMP error
message? If they adapt the segment size, they implement some form of PMTUD.
If frag was needed (As indicated in the ICMP error message), and they
keep sending at the same segment size, the connection would time-out
(not good). If they don't do any of these, and follow RFC1122 instead,
they should reset the connection (not good, either).



>> The appendix was at some point part of the main text. I moved the text
>> into an appendix probably on request of somebody, but not because I
>> thought the text should be there. So I have no problem moving the
>> entirre appendix (or part of it) back into the main part of the
>> document.
> 
> Oh, I didn't realize we'd already juggled it around :).
> It makes sense to me to analyze the different message
> types this way as motivation for the recommendations on
> how to treat them, which is why I expected it to be in
> the body, but if there was already consensus to have it
> as an appendix, then that's fine too.

No, I don't think there was consensus to move that stuff to an appendix.
It was probably the result of me honoring a suggestion I had received
from some folk.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fw@deneb.enyo.de  Sun Jun 14 06:35:03 2009
Return-Path: <fw@deneb.enyo.de>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9790228C0E1 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 06:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Level: 
X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.605,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NtzG4Lql1kA for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 06:35:03 -0700 (PDT)
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by core3.amsl.com (Postfix) with ESMTP id CC8CE28C0DD for <tcpm@ietf.org>; Sun, 14 Jun 2009 06:35:01 -0700 (PDT)
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MFprW-0001Zw-Dz; Sun, 14 Jun 2009 15:35:06 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from <fw@deneb.enyo.de>) id 1MFprW-0005OO-0f; Sun, 14 Jun 2009 15:35:06 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: "Eddy\, Wesley M. \(GRC-MS00\)\[Verizon\]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
Date: Sun, 14 Jun 2009 15:35:05 +0200
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov> (Wesley M. Eddy's message of "Wed, 10 Jun 2009 23:32:57 -0500")
Message-ID: <87ljnvey5y.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sun, 14 Jun 2009 13:35:03 -0000

* Wesley M. Eddy:

> As both co-chair and TCPM participant, I'm not really
> comfortable with Appendix B of this document which
> reads a lot like an advertisement.  Even though I
> know it's well-intentioned, it seems like we'd set
> a bad precedent if we got into the habit of putting
> sponsor-plugs into the appendices of our documents.
> I don't think we lose anything by leaving that
> appendix out completely.
>
> What does the WG think?

I think it should go.

(Disclaimer: I don't like the way UNIRAS/CPNI handled some
disclosures, but I think this isn't important in this context.)

From fw@deneb.enyo.de  Sun Jun 14 06:37:45 2009
Return-Path: <fw@deneb.enyo.de>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E4428C0E1 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 06:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.705
X-Spam-Level: 
X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.544,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWxv80vsAffi for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 06:37:44 -0700 (PDT)
Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by core3.amsl.com (Postfix) with ESMTP id 8C6B728C0DD for <tcpm@ietf.org>; Sun, 14 Jun 2009 06:37:44 -0700 (PDT)
Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1MFpu9-0001b7-Pt; Sun, 14 Jun 2009 15:37:49 +0200
Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from <fw@deneb.enyo.de>) id 1MFpu9-0005Os-4q; Sun, 14 Jun 2009 15:37:49 +0200
From: Florian Weimer <fw@deneb.enyo.de>
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov> <4A30C093.5060408@gont.com.ar>
Date: Sun, 14 Jun 2009 15:37:49 +0200
In-Reply-To: <4A30C093.5060408@gont.com.ar> (Fernando Gont's message of "Thu,  11 Jun 2009 05:30:11 -0300")
Message-ID: <87hbyjey1e.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sun, 14 Jun 2009 13:37:45 -0000

* Fernando Gont:

>> For instance, I'm not certain that setting the DF bit is only
>> possible for hosts that support PMTUD ... is there a reference for
>> that?
>
> What's the reason for setting the DF flag for IP packets carrying TCP
> segments if you don't implement PMTUD?

You don't have to put randomness into the IP ID field (at least in
theory; in practice, DF=1 packets get fragmented, too).

From touch@ISI.EDU  Sun Jun 14 07:57:12 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249E728C0F8 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 07:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level: 
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFz56v-3E6Lu for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 07:57:11 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 48FD828C0ED for <tcpm@ietf.org>; Sun, 14 Jun 2009 07:57:11 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5EEuqe3023977; Sun, 14 Jun 2009 07:56:53 -0700 (PDT)
Message-ID: <4A350FB3.1090008@isi.edu>
Date: Sun, 14 Jun 2009 07:56:51 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>	<4A30C093.5060408@gont.com.ar> <87hbyjey1e.fsf@mid.deneb.enyo.de>
In-Reply-To: <87hbyjey1e.fsf@mid.deneb.enyo.de>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sun, 14 Jun 2009 14:57:12 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Florian Weimer wrote:
> * Fernando Gont:
> 
>>> For instance, I'm not certain that setting the DF bit is only
>>> possible for hosts that support PMTUD ... is there a reference for
>>> that?
>> What's the reason for setting the DF flag for IP packets carrying TCP
>> segments if you don't implement PMTUD?
> 
> You don't have to put randomness into the IP ID field (at least in
> theory; in practice, DF=1 packets get fragmented, too).

Technically, you do regardless of whether the bit is set or not right
now. Hopefully that requirement will change, but only when we change the
standards.

See draft-touch-intarea-ipv4-unique-id-01

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko1D7MACgkQE5f5cImnZrv07wCeIxIAW7lXUAna3Acw0VVI/iBL
IHMAoJPNRmTktfTRtZRmZzrDm+uBL/Yz
=FkzW
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Sun Jun 14 08:02:00 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E27C28C0F7 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 08:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql-wT+-PCaLY for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 08:01:59 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2897A28C0ED for <tcpm@ietf.org>; Sun, 14 Jun 2009 08:01:59 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5EF1RLJ024898; Sun, 14 Jun 2009 08:01:29 -0700 (PDT)
Message-ID: <4A3510C7.4050105@isi.edu>
Date: Sun, 14 Jun 2009 08:01:27 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sun, 14 Jun 2009 15:02:00 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> As both co-chair and TCPM participant, I'm not really
> comfortable with Appendix B of this document which
> reads a lot like an advertisement.  Even though I
> know it's well-intentioned, it seems like we'd set
> a bad precedent if we got into the habit of putting
> sponsor-plugs into the appendices of our documents.
> I don't think we lose anything by leaving that
> appendix out completely.
> 
> What does the WG think?

I think it ought to be OK to say "this work supported by..." or other
disclaimers in the Ack's section.

The text in question is more than a plug; it's recommended action.
That's clearly out of scope for an informational doc; it would require
BCP status to have such guidance, and the WG would need to agree that
such guidance is appropriate.

In general, it's also far too specific -- i.e., such guidance is more
appropriately "contact the authorities and report...", and would then
give a list of appropriate entities, rather than endorsing or
recommending a single party.

Joe

> To speed analysis, the text in question is:
> 
> Appendix B. Advice and guidance to vendors
> 
> 
>    Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they
>    think they may be affected by the issues described in this document.
>    As the lead coordination center for these issues, CPNI is well placed
>    to give advice and guidance as required.
> 
>    CPNI works extensively with government departments and agencies,
>    commercial organizations and the academic community to research
>    vulnerabilities and potential threats to IT systems especially where
>    they may have an impact on Critical National Infrastructure's (CNI).
> 
>    Other ways to contact CPNI, plus CPNI's PGP public key, are available
>    at http://www.cpni.gov.uk .
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko1EMcACgkQE5f5cImnZrvVWgCgr3k3VWTCMSIo+3sZuVo4cIz+
9NgAoKO6hTQlr1+Aq1aXkqy7O+M/0iTQ
=ryEZ
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Sun Jun 14 19:16:50 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BB73A6C45 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0CflaXvrZqx for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:16:49 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id A639A3A6C3D for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:16:49 -0700 (PDT)
Received: by qyk36 with SMTP id 36so9442qyk.29 for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:16:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ceuxqFZVQNdo4AfcD6JxjgszX/hFtveQ3gtkrJxOUU4=; b=pOlXpWt3aGNml9vR+w1uVdhbonVvo5oo4WztMbIQH68MvuHu6gXgZ67+FAsjI/Lz5j 9S18IJoO5LtdobmPo+Ite9R2Iwo5VSZrshHyQvUnRAFPJXYttn/3bJblmN9FzV24Km7y A+c95myeGSuYke/hEYJtZQe6bBzHs1s6wgmgw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=M1Irji1QmpnC+d8bT2CwUV0Hn/SIu3umM8AKh5jh4AFtLKqR7b8ai/GpugBkSOj0s9 8mazJN1WNiamHngff8PaMQNe3gwnedNZoZ+nTy1kZr0rBCzqtU7AYai3h3X83Iyb0hB5 oEcG9yAn6pxdEMVApzp4rMxbfivet5HjKOT1s=
Received: by 10.224.80.193 with SMTP id u1mr6703978qak.353.1245032217567; Sun, 14 Jun 2009 19:16:57 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 6sm370916qwd.12.2009.06.14.19.16.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 19:16:56 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A35AF10.6000500@gont.com.ar>
Date: Sun, 14 Jun 2009 23:16:48 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu>
In-Reply-To: <4A32BD5F.5030503@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 02:16:50 -0000

Joe Touch wrote:

>>> 5) (general) Section 5.1, last paragraph, it
>>> seems like we should be mentioning TCP-AO as
>>> well here, though I don't think it changes any
>>> part of the claim.
>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>> something in this respect!
> 
> TCP-AO already addresses ICMP attacks in the security considerations
> section, and requires there to be a way to disable reaction to ICMPs.
> Like IPsec, though, we don't make a-priori assessments as to whether
> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
> is used.

IIRC, the motivation for the TCP MD5 option was to mitigate RST-based
reset attacks. Does it make any sense to have the option and still even
consider reacting to ICMP error messages?

Reaction to ICMP "frag needed" is probably a little more difficult to
assess (for obvious reasons), but reaction to ICMP hard errors is, IMO,
a no-brainer, and I believe should default to "SHOULD NOT abort
connections".

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando.gont.netbook.win@gmail.com  Sun Jun 14 19:23:57 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F5843A6985 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd+B5K2auGno for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:23:56 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 85D053A6A5D for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:23:56 -0700 (PDT)
Received: by qyk36 with SMTP id 36so9866qyk.29 for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=okxGKqbUU5h3ialLdwu6HOGgVVjQ+yr+7Mm7BD75Qvs=; b=UpVo1tYs2bf0kp10b5QTvriNe/EVF6PIQWHOUe2HdalqbCCHXCTAEdpP3xraylvIET oX/9L7YPV2nrMrW49DIh6O43WrAKlV3GIM5mXGvGcA2UzIw9HsaeHQNfSbE9Jok1cVP0 wC7w17u9+P5K/QOJOnY8QiPGr7frgUCL6pbwg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=x3EKtE/tq3/71lWuua8/gc9xI6Jo4bcta5cy7uxIcY/BF44MzXD/3uqm2FuwuLHB7w CZiqasIT0vLM8gf/LTAc/VnkDAtcYzS3Trz+5838Fg1zgBYk6UHlxl7LXcLVhGIlycrG e6h93+qsEfU6JN9hqEaLCwnGXWPVzTIEicVlg=
Received: by 10.224.36.202 with SMTP id u10mr6750469qad.83.1245032644586; Sun, 14 Jun 2009 19:24:04 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 26sm204114qwa.44.2009.06.14.19.24.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 19:24:03 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A35B0BC.5040302@gont.com.ar>
Date: Sun, 14 Jun 2009 23:23:56 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 02:23:57 -0000

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> As both co-chair and TCPM participant, I'm not really
> comfortable with Appendix B of this document which
> reads a lot like an advertisement.  Even though I
> know it's well-intentioned, it seems like we'd set
> a bad precedent if we got into the habit of putting
> sponsor-plugs into the appendices of our documents.
> I don't think we lose anything by leaving that
> appendix out completely.

Let me clarify this one a little bit: When I included this appendix, I
was not working for UK CPNI (formerly NISCC), and there were no plans of
doing so.

However, NISCC was carrying out the vendor coordination process wrt the
ICMP vulnerabilities. For instance, NISCC ended up publishing a
vulnerability advisory stating the vulnerability status of each of the
different vendors.

That was the reason for including that paragraph. -- as I mentioned,
neither NISCC nor CPNI sponsored any of my work on the ICMP attacks
draft (for instance, my affiliation for this I-D is with UTN/FRH, not
with CPNI).

That said, I have no problem with removing this appendix, and adding a
corresponding ack in the "Acknowledgements" section (i.e., different and
shorter text) to NISCC/CPNI for the vendor coordination process they
carried out.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando.gont.netbook.win@gmail.com  Sun Jun 14 19:28:29 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 610A43A6C67 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvaYJ3rmJHkM for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:28:28 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id 59B793A6985 for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:28:27 -0700 (PDT)
Received: by qyk36 with SMTP id 36so10067qyk.29 for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=aganO8stIQtPGhe4fm7T/t6mzIpLZ4CPzi9O3cnN+Ho=; b=BFDkffMu2EAnYImS6XaeFueNppnqGJx6VrwNjYTZFI2CI/BCCz1pG23qkZVUehB0f+ OGxc62ssmba4CwkYdmegQBREqgPOREHKoiETEy3ox/tRAf3a/9uJyOkgVJXEe2wuv+mH CWv5OE3XM6CveUFRGjPYeImJlDiVBGekfFmCU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=lqpv6d3eUop0iRQGgA8G3NROkbs6JyBXJTA6IKZKowceDspewJGocPdOIXwWhLIkpw txSPIMZ/qqb+AtO26HTJoFUR7Or/AeI+OR6xVsvF34Q8M4Z1HhnfryiH2t53cLx/1wib 38Wt9F1msjQQVNIXO5Z5n3XDcQFwB6MIkc1LI=
Received: by 10.224.11.136 with SMTP id t8mr6717163qat.205.1245032915493; Sun, 14 Jun 2009 19:28:35 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 7sm925543qwb.6.2009.06.14.19.28.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 19:28:34 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A35B1CA.70207@gont.com.ar>
Date: Sun, 14 Jun 2009 23:28:26 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>	<4A30C093.5060408@gont.com.ar> <87hbyjey1e.fsf@mid.deneb.enyo.de>
In-Reply-To: <87hbyjey1e.fsf@mid.deneb.enyo.de>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 02:28:29 -0000

Florian Weimer wrote:

>>> For instance, I'm not certain that setting the DF bit is only
>>> possible for hosts that support PMTUD ... is there a reference for
>>> that?
>> What's the reason for setting the DF flag for IP packets carrying TCP
>> segments if you don't implement PMTUD?
> 
> You don't have to put randomness into the IP ID field (at least in
> theory; in practice, DF=1 packets get fragmented, too).

Yes, in theory. For instance, IIRC Linux used to zero the IP ID field
when DF was set, but then backed-out this change.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Sun Jun 14 19:48:14 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008663A6C95 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eEDnCmnVoRy for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:48:13 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2EE773A6C7D for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:48:13 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5F2lsYX008377; Sun, 14 Jun 2009 19:47:56 -0700 (PDT)
Message-ID: <4A35B65A.9050404@isi.edu>
Date: Sun, 14 Jun 2009 19:47:54 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu> <4A35AF10.6000500@gont.com.ar>
In-Reply-To: <4A35AF10.6000500@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 02:48:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 5) (general) Section 5.1, last paragraph, it
>>>> seems like we should be mentioning TCP-AO as
>>>> well here, though I don't think it changes any
>>>> part of the claim.
>>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>>> something in this respect!
>> TCP-AO already addresses ICMP attacks in the security considerations
>> section, and requires there to be a way to disable reaction to ICMPs.
>> Like IPsec, though, we don't make a-priori assessments as to whether
>> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
>> is used.
> 
> IIRC, the motivation for the TCP MD5 option was to mitigate RST-based
> reset attacks. Does it make any sense to have the option and still even
> consider reacting to ICMP error messages?

See Sec 6.1.1 of RFC4301. There are legitimate uses for these messages,
and turning them off should be up to the user.

> Reaction to ICMP "frag needed" is probably a little more difficult to
> assess (for obvious reasons), but reaction to ICMP hard errors is, IMO,
> a no-brainer, and I believe should default to "SHOULD NOT abort
> connections".

IPsec does not make that leap, nor is there a good reason to do so here.
 Like IPsec, we require that this be configurable, but don't specify a
default.

This is already noted in the Security Considerations section.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko1tloACgkQE5f5cImnZrtnMgCgxsiBCpZL+FIHL03poEL4kDmf
e1MAnRmEKtXCQj8b4CqIN32Vr/RrMeYH
=JePm
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Sun Jun 14 19:59:19 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F35F3A68DE for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level: 
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TEz+Wdjkg1E for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 19:59:18 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 68DD43A6900 for <tcpm@ietf.org>; Sun, 14 Jun 2009 19:59:18 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5F2x1BP010078; Sun, 14 Jun 2009 19:59:03 -0700 (PDT)
Message-ID: <4A35B8F5.6020900@isi.edu>
Date: Sun, 14 Jun 2009 19:59:01 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<C304DB494AC0C04C87C6A6E2FF5603DB221796D53E@NDJSSCC01.ndc.nasa.gov>	<4A30C093.5060408@gont.com.ar>	<87hbyjey1e.fsf@mid.deneb.enyo.de> <4A35B1CA.70207@gont.com.ar>
In-Reply-To: <4A35B1CA.70207@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Florian Weimer <fw@deneb.enyo.de>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 02:59:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Florian Weimer wrote:
> 
>>>> For instance, I'm not certain that setting the DF bit is only
>>>> possible for hosts that support PMTUD ... is there a reference for
>>>> that?
>>> What's the reason for setting the DF flag for IP packets carrying TCP
>>> segments if you don't implement PMTUD?
>> You don't have to put randomness into the IP ID field (at least in
>> theory; in practice, DF=1 packets get fragmented, too).
> 
> Yes, in theory. For instance, IIRC Linux used to zero the IP ID field
> when DF was set, but then backed-out this change.

This was/is also incorrectly done by some cellphones, to save state and
processing.

The trouble is that the IP ID is also used to detect (and discard)
duplicate segments. This is described in the draft I already cited, and
the best place to discuss it is the INT area mailing list.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko1uPUACgkQE5f5cImnZrsylgCdGfELd2eAxvVPtC/1wWigl1lY
8qwAoPStmplBwumSEldah/X3QLhY4VlP
=IP6g
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Sun Jun 14 20:01:34 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AFD3A6ADB for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 20:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX91Nvl5n-y6 for <tcpm@core3.amsl.com>; Sun, 14 Jun 2009 20:01:34 -0700 (PDT)
Received: from mail-qy0-f130.google.com (mail-qy0-f130.google.com [209.85.221.130]) by core3.amsl.com (Postfix) with ESMTP id E435E3A6900 for <tcpm@ietf.org>; Sun, 14 Jun 2009 20:01:33 -0700 (PDT)
Received: by qyk36 with SMTP id 36so11779qyk.29 for <tcpm@ietf.org>; Sun, 14 Jun 2009 20:01:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ST9zGKNNDthTLnadfrWBezQV3pkE+hvt0rRNkivB5CM=; b=J9hAEQGOK9xXVXugR9slGKzHS5rX57Ilhld9+faFhEiGcbvO0aOXrl6yFnk79NSErg 2OdqTXEpiR9Amz6IbuPFSZUMDOHYCIVLJkh1duN9umxFmbqL79jUngCUUjTIHapa1lxQ FOyw0GXKxhK7gWJjpNxKI4M2thD+Y3StcAgxU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=YGML/JtzhOYtWuX+uB7Yhe+17wNwUl0dce7pIHvdfY7icEGCtlCg6U8viKx1enjEAa RiJmiYVc+ODynWcpmoWzqX7CqV5PF0+SWOfluw9VInfZwAilYX+jVQDVFsDEI9xZ4uWA ePDhdqH2LFzTSmmmm0Jdqlbbr4TTWSq1W8OoE=
Received: by 10.224.11.18 with SMTP id r18mr6769403qar.63.1245034901989; Sun, 14 Jun 2009 20:01:41 -0700 (PDT)
Received: from ?192.168.0.151? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 6sm652708qwd.42.2009.06.14.20.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 20:01:41 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A35B98D.9040103@gont.com.ar>
Date: Mon, 15 Jun 2009 00:01:33 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Florian Weimer <fw@deneb.enyo.de>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<C304DB494AC0C04C87C6A6E2FF5603DB221796D53D@NDJSSCC01.ndc.nasa.gov> <87ljnvey5y.fsf@mid.deneb.enyo.de>
In-Reply-To: <87ljnvey5y.fsf@mid.deneb.enyo.de>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 15 Jun 2009 03:01:34 -0000

Florian Weimer wrote:

> (Disclaimer: I don't like the way UNIRAS/CPNI handled some
> disclosures, but I think this isn't important in this context.)

FWIW, when it comes to these ICMP issues, I had reported them to both
NISCC and CERT/CC at the same time. And I sticked with NISCC/CPNI
because I got a much better response from them. IIRC, Paul Watson (TCP
reset attacks) has a very similar story.

If there are any specific issues you didn't like how UNIRAS/CPNI
handled, feel free to comment them off-list, and I will relay them to
CPNI. They are always open for suggestions and improvement.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando.gont.netbook.win@gmail.com  Tue Jun 16 05:59:29 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA3F3A6A76 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 05:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGEEQRhABZeQ for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 05:59:29 -0700 (PDT)
Received: from mail-yx0-f115.google.com (mail-yx0-f115.google.com [209.85.210.115]) by core3.amsl.com (Postfix) with ESMTP id E65AE3A6882 for <tcpm@ietf.org>; Tue, 16 Jun 2009 05:59:28 -0700 (PDT)
Received: by yxe13 with SMTP id 13so12295yxe.29 for <tcpm@ietf.org>; Tue, 16 Jun 2009 05:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=L3xwLgm4jHZ9PLpuGXy3KKvpiTw//dO2NaOi66TPX04=; b=QNnaEmotkM7WL7gFT3VnpJiTHfwsLZsc42cqoaHfxlPhOI1jqTzaJg+h/l+0um3Ri5 qIscP0oRhFr7+MA9DnvNUE9BIfC5in8Z5hz3VyzaKYyB4B9+ntHOMEs17H8XnQJaw+Cy QYhfE1916SByeZGvsbiR7t/XgvibBaeZXRE5A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=sgQJmYeh79xeTwvN4Idm+fTX4ZDyzCJFpxif7eM4DEqdLzWTapBcdt3DDGDfXo92fA QlpOIJow3wSnECjZebU+SPCy6/HAXqfI4rVNKsy3Y9CSLZuG6rR+5E8NsGfBMYLEX3gO KOvL1/4PmOQtcG2pXAhKem3aLkAmmzO1++OuI=
Received: by 10.90.86.10 with SMTP id j10mr3552012agb.6.1245157130315; Tue, 16 Jun 2009 05:58:50 -0700 (PDT)
Received: from ?172.16.1.132? (host97.190-139-184.telecom.net.ar [190.139.184.97]) by mx.google.com with ESMTPS id 20sm1589994agd.38.2009.06.16.05.58.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 05:58:49 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A379700.3070808@gont.com.ar>
Date: Tue, 16 Jun 2009 09:58:40 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar> <4A32BD5F.5030503@isi.edu>
In-Reply-To: <4A32BD5F.5030503@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: [tcpm] TCP-AO and ICMP attacks (was Re: comments on draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 12:59:29 -0000

Joe Touch wrote:

>>> 5) (general) Section 5.1, last paragraph, it
>>> seems like we should be mentioning TCP-AO as
>>> well here, though I don't think it changes any
>>> part of the claim.
>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>> something in this respect!
> 
> TCP-AO already addresses ICMP attacks in the security considerations
> section, and requires there to be a way to disable reaction to ICMPs.
> Like IPsec, though, we don't make a-priori assessments as to whether
> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
> is used.

What's the point of enabling TCP-AO, if you are not going to disable (or
hard errors -> soft errors)?

I think that for the sake of the "principle of least surprise", ICMP
hard errors SHOULD NOT abort connections for which TCP AO has been enabled.

What to do with "frag needed" might vary. Although one could argue that
you SHOULD implement PLPMTUD.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From ekr@networkresonance.com  Tue Jun 16 06:17:49 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AD43A6AF4 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 06:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRCZKRXmN21H for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 06:17:48 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 55C313A69C5 for <tcpm@ietf.org>; Tue, 16 Jun 2009 06:17:48 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 75C481BC6EB; Tue, 16 Jun 2009 06:18:07 -0700 (PDT)
Date: Tue, 16 Jun 2009 06:18:06 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A2AB973.3030203@isi.edu>
References: <4A2AB973.3030203@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090616131807.75C481BC6EB@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 13:17:49 -0000

At Sat, 06 Jun 2009 11:46:11 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi, all,
> 
> One open issue remaining is how to express what was formerly a database
> with a particular structure (TAPD, previously TSAD) in ways that impact
> rekeying and possibly future master key management protocols. We decided
> at the last meeting in SFO to do as follows:
> 
> 	- require that each segment match only one key
> 		- segments for established connections must match
> 		only one connection key
> 		- segments for new connections (SYNs) must match
> 		only one master key
> 
> Connection keys never overlap; there would never be two connection keys
> with the same keyID and socket pair. The open issue focuses on master
> keys, which would more likely be specified with wildcards, masks, or
> ranges, esp. for remote port numbers, but also potentially for addresses
> or local port numbers. This issue is particularly relevant for rekeying
> - - adding new master keys that would result in new connection keys being
> derived for existing connections - and how an endpoint would be able to
> ensure uniqueness as above.
> 
> Do we need additional constraints to ensure that master key descriptions
> never overlap?
>
> As review, the previous description of keys as a database also implied,
> by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
> was:
> 
>     a socket pair descriptor
>         which may include wildcards or masks
> 
>     one or more MKTs, each of which includes:
>         sendID
>         recvID
>         crypto info:
>             master key
>             MAC info
>             KDF info
> 
> The TAPD was defined so that a segment matched at most one socket pair
> descriptor, and that MKTs within that descriptor had distinct sendIDs
> and recvIDs.
> 
> If we remove that data structure, it would most obviously be replaced
> with MKTs with their own socket descriptors, i.e.:
> 
>     MKT
>         socket pair descriptor (may include wildcards/masks)
>         sendID
>         recvID
>         crypto info
> 
> The question that remains is whether MKTs that match a segment all have
> identical socket pair descriptors, even down to their
> wildcards/ranges/masks (which was previously required). If
> not, then how do we ensure that MKTs don't interfere?

I don't understand why this is a problem. The invariant that
the system needs to enforce is that for any given packet 
there be at most one valid MKT with a given key-id, right?
There are a number of ways to enforce this, including:

1. Having some kind of database.
2. Tying MKTs to sockets directly at the time of instantiation
   (including half-open sockets).


> If we throw our hands up and say this is "implementation detail", then
> IMO we could be hobbling any KMP, since there would be no common data
> for the KMP to coordinate.

I don't see this. Obviously, any KMP will need some model for
how it thinks about keys and any particular implementation of
a KMP will need to interact with the system on which it is
implemented in order to match that model to the system's
implementation, but I don't see how that's a problem. It's
not like we're defining a C API for the KMP implementations
to call.

-Ekr



From touch@ISI.EDU  Tue Jun 16 06:46:22 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B47363A6B7C for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 06:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level: 
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYhNTa52QFTW for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 06:46:21 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9954E28C163 for <tcpm@ietf.org>; Tue, 16 Jun 2009 06:46:21 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GDjcBT025982; Tue, 16 Jun 2009 06:45:40 -0700 (PDT)
Message-ID: <4A37A202.9020500@isi.edu>
Date: Tue, 16 Jun 2009 06:45:38 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com>
In-Reply-To: <20090616131807.75C481BC6EB@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 13:46:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Sat, 06 Jun 2009 11:46:11 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi, all,
>>
>> One open issue remaining is how to express what was formerly a database
>> with a particular structure (TAPD, previously TSAD) in ways that impact
>> rekeying and possibly future master key management protocols. We decided
>> at the last meeting in SFO to do as follows:
>>
>> 	- require that each segment match only one key
>> 		- segments for established connections must match
>> 		only one connection key
>> 		- segments for new connections (SYNs) must match
>> 		only one master key
>>
>> Connection keys never overlap; there would never be two connection keys
>> with the same keyID and socket pair. The open issue focuses on master
>> keys, which would more likely be specified with wildcards, masks, or
>> ranges, esp. for remote port numbers, but also potentially for addresses
>> or local port numbers. This issue is particularly relevant for rekeying
>> - - adding new master keys that would result in new connection keys being
>> derived for existing connections - and how an endpoint would be able to
>> ensure uniqueness as above.
>>
>> Do we need additional constraints to ensure that master key descriptions
>> never overlap?
>>
>> As review, the previous description of keys as a database also implied,
>> by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
>> was:
>>
>>     a socket pair descriptor
>>         which may include wildcards or masks
>>
>>     one or more MKTs, each of which includes:
>>         sendID
>>         recvID
>>         crypto info:
>>             master key
>>             MAC info
>>             KDF info
>>
>> The TAPD was defined so that a segment matched at most one socket pair
>> descriptor, and that MKTs within that descriptor had distinct sendIDs
>> and recvIDs.
>>
>> If we remove that data structure, it would most obviously be replaced
>> with MKTs with their own socket descriptors, i.e.:
>>
>>     MKT
>>         socket pair descriptor (may include wildcards/masks)
>>         sendID
>>         recvID
>>         crypto info
>>
>> The question that remains is whether MKTs that match a segment all have
>> identical socket pair descriptors, even down to their
>> wildcards/ranges/masks (which was previously required). If
>> not, then how do we ensure that MKTs don't interfere?
> 
> I don't understand why this is a problem. The invariant that
> the system needs to enforce is that for any given packet 
> there be at most one valid MKT with a given key-id, right?

KeyID doesn't come into play for outgoing packets, so we can ignore that.

However, the invariant is twofold:

	a) for a given packet, only one MKT applies

	b) for two endpoints with multiple MKTs,
	the *same* MKT applies.

The second invariant requires that either:

	a) no two MKTs have patterns that overlap

	b) MKTs are ordered identically on the two endpoints

If two endpoints solve this differently, a KMP could try to install the
same keys on the two ends and fail, either because one side would refuse
a new key (as overlapping), or because the two sides vary in how they
order the keys.

> There are a number of ways to enforce this, including:
> 
> 1. Having some kind of database.
> 2. Tying MKTs to sockets directly at the time of instantiation
>    (including half-open sockets).

We need to ensure that both sides pick the same MKT. That needs to
happen at connection establishment (could be during socket
instantiation), but ALSO needs to happen for re-keying, FWIW. That
doesn't change the nature of the problem.

>> If we throw our hands up and say this is "implementation detail", then
>> IMO we could be hobbling any KMP, since there would be no common data
>> for the KMP to coordinate.
> 
> I don't see this. Obviously, any KMP will need some model for
> how it thinks about keys and any particular implementation of
> a KMP will need to interact with the system on which it is
> implemented in order to match that model to the system's
> implementation, but I don't see how that's a problem. It's
> not like we're defining a C API for the KMP implementations
> to call.

If we don't specify some level of commonality, we can't expect to ever
define such an API.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3ogIACgkQE5f5cImnZrtDoACgqfBUxsXk52jQsNa4AiDeXdOm
KCIAoLphIibqh3KVm2cm6QIsZTOn2bvS
=JuFx
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Tue Jun 16 07:01:08 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9663A6B13 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 07:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jgin5gBUFxCC for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 07:01:07 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C451E3A6845 for <tcpm@ietf.org>; Tue, 16 Jun 2009 07:01:07 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GDxiMl029288; Tue, 16 Jun 2009 06:59:46 -0700 (PDT)
Message-ID: <4A37A551.60800@isi.edu>
Date: Tue, 16 Jun 2009 06:59:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar>
In-Reply-To: <4A379700.3070808@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 14:01:08 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>> 5) (general) Section 5.1, last paragraph, it
>>>> seems like we should be mentioning TCP-AO as
>>>> well here, though I don't think it changes any
>>>> part of the claim.
>>> Agreed. Maybe this is also an indication that TCP-AO *should* change
>>> something in this respect!
>> TCP-AO already addresses ICMP attacks in the security considerations
>> section, and requires there to be a way to disable reaction to ICMPs.
>> Like IPsec, though, we don't make a-priori assessments as to whether
>> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
>> is used.
> 
> What's the point of enabling TCP-AO, if you are not going to disable (or
> hard errors -> soft errors)?

See the text in RFC4301.

> I think that for the sake of the "principle of least surprise", ICMP
> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.

Please explain why you think that TCP-AO needs more strict advice in
this regard than IPsec.

> What to do with "frag needed" might vary. Although one could argue that
> you SHOULD implement PLPMTUD.

- ---

We could add that TCP-AO, like IPsec (text copied from 4301):

   ...A compliant TCP-AO
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic.  This control MUST be at the granularity of ICMP type and
   MAY be at the granularity of ICMP type and code.  Additionally, an
   implementation SHOULD incorporate mechanisms and parameters for
   dealing with such traffic.  For example, there could be the ability
   to establish a minimum PMTU for traffic (on a per destination basis),
   to prevent receipt of an unauthenticated ICMP from setting the PMTU
   to a trivial size.

- ---

We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
particular recommendations of implementation. We would need to be
careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
deployment.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko3pVAACgkQE5f5cImnZruIhwCfccxoolqykof8xWtZ2Ud9cIZM
YB0AoMZ/1jeTrmKxvo2UPoy8KlGGmX0b
=Ermg
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun 16 10:31:47 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F8D3A6D83 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 10:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nytL4jNM2hJX for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 10:31:46 -0700 (PDT)
Received: from mail-qy0-f119.google.com (mail-qy0-f119.google.com [209.85.221.119]) by core3.amsl.com (Postfix) with ESMTP id 88DAE3A68BC for <tcpm@ietf.org>; Tue, 16 Jun 2009 10:31:46 -0700 (PDT)
Received: by qyk17 with SMTP id 17so34302qyk.29 for <tcpm@ietf.org>; Tue, 16 Jun 2009 10:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=Wr16ihG+RHNMca7kgL4z7sE7Tb9cDKHMLnTE1L1uCHA=; b=MlcbSJWxdr1WrvzpxUsy6UODc6Yw2bafIVQwpadEP+tTuEq4Yne/rNbXENVJqAH3Uh Ze/oTgxsjexphI271FfSsw3T0pbHV1YIflhJ5Sk53HqYlWG4Ezdd/Xyq9/aBAEZ2nC0u +Sr2X+RSRJW5kQzN8PoebJuFOYAHc20xGTioE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=wT+PDdl+QFu/NMmjkKaYUfEBiwgwlZqaI9G2aYI00lVoaA1yXG+KAaO7O47TU+ZCfA lQ7wKkhUqklXfCeBnp1NQgizBoBiOfPLICi+kzq5iXIRr2VJ5r1wMFTSxMsPz/4R+68Q JxoRXpB0+yoBj+UVEXUzlWIToXPgoAbJvslQE=
Received: by 10.220.85.83 with SMTP id n19mr6121403vcl.33.1245173508551; Tue, 16 Jun 2009 10:31:48 -0700 (PDT)
Received: from ?172.16.1.132? (host97.190-139-184.telecom.net.ar [190.139.184.97]) by mx.google.com with ESMTPS id 6sm125761ywc.31.2009.06.16.10.31.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 10:31:47 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A37D6FC.4040005@gont.com.ar>
Date: Tue, 16 Jun 2009 14:31:40 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu>
In-Reply-To: <4A37A551.60800@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 17:31:48 -0000

Joe Touch wrote:

>> I think that for the sake of the "principle of least surprise", ICMP
>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.
> 
> Please explain why you think that TCP-AO needs more strict advice in
> this regard than IPsec.

Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
to get into the details of how a specific transport protocol (TCP) would
react to specific ICMP error messages.

In the case of TCP-AO, it's TCP specific, and thus I believe it should
provide stricter advice wrt how TCP should react to ICMP error messages
when they are received for connections that employ TCP-AO.



>> What to do with "frag needed" might vary. Although one could argue that
>> you SHOULD implement PLPMTUD.
> 
> ---
> 
> We could add that TCP-AO, like IPsec (text copied from 4301):
> 
>    ...A compliant TCP-AO
>    implementation MUST permit a local administrator to configure an
>    IPsec implementation to accept or reject unauthenticated ICMP
>    traffic.  This control MUST be at the granularity of ICMP type and
>    MAY be at the granularity of ICMP type and code.  Additionally, an
>    implementation SHOULD incorporate mechanisms and parameters for
>    dealing with such traffic.  For example, there could be the ability
>    to establish a minimum PMTU for traffic (on a per destination basis),
>    to prevent receipt of an unauthenticated ICMP from setting the PMTU
>    to a trivial size.

Makes sense to me. Although, again, I believe there should be (safe)
defaults for this.


> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
> particular recommendations of implementation. We would need to be
> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
> deployment.

I believe it could/should be suggested that PLPMTUD be implemented
without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
leaves it open as to whether PMTUD should only be implemented for
dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 16 11:29:56 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AD0C3A6D7A for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 11:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9NIzwuyufX2 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 11:29:55 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 75FFA3A6B73 for <tcpm@ietf.org>; Tue, 16 Jun 2009 11:29:55 -0700 (PDT)
Received: from [128.9.184.173] ([128.9.184.173]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GITepJ011825; Tue, 16 Jun 2009 11:29:41 -0700 (PDT)
Message-ID: <4A37E494.60904@isi.edu>
Date: Tue, 16 Jun 2009 11:29:40 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar>
In-Reply-To: <4A37D6FC.4040005@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 18:29:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> I think that for the sake of the "principle of least surprise", ICMP
>>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.
>> Please explain why you think that TCP-AO needs more strict advice in
>> this regard than IPsec.
> 
> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
> to get into the details of how a specific transport protocol (TCP) would
> react to specific ICMP error messages.

It does, though, in detail.

> In the case of TCP-AO, it's TCP specific, and thus I believe it should
> provide stricter advice wrt how TCP should react to ICMP error messages
> when they are received for connections that employ TCP-AO.

It's probably useful to split out the discussion of ICMP to a separate
section. However, the advice therein seems like it should still not
exceed what is in 4301 for the same reason for the same transport
protocol - there are pros and cons of either leaving open or closing
ICMP handling.

This document is not a place where the difference between hard and soft
ICMPs and TCP opening vs. established should be resolved, since it has
not been resolved for TCP without authentication, and authentication
does not apply to the ICMP messages.

>>> What to do with "frag needed" might vary. Although one could argue that
>>> you SHOULD implement PLPMTUD.
>> ---
>>
>> We could add that TCP-AO, like IPsec (text copied from 4301):
>>
>>    ...A compliant TCP-AO
>>    implementation MUST permit a local administrator to configure an
>>    IPsec implementation to accept or reject unauthenticated ICMP
>>    traffic.  This control MUST be at the granularity of ICMP type and
>>    MAY be at the granularity of ICMP type and code.  Additionally, an
>>    implementation SHOULD incorporate mechanisms and parameters for
>>    dealing with such traffic.  For example, there could be the ability
>>    to establish a minimum PMTU for traffic (on a per destination basis),
>>    to prevent receipt of an unauthenticated ICMP from setting the PMTU
>>    to a trivial size.
> 
> Makes sense to me. Although, again, I believe there should be (safe)
> defaults for this.

Defaults have generally been removed from the document for various reasons.

>> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
>> particular recommendations of implementation. We would need to be
>> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
>> deployment.
> 
> I believe it could/should be suggested that PLPMTUD be implemented
> without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
> leaves it open as to whether PMTUD should only be implemented for
> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).

There are a few possibilities:

	- use DF=0
	- use DF=1 with PMTUD
		this requires ICMP frag-needed be passed
		which opens a vulnerability on that ICMP type
		however, the attack of additional frag-neededs
		could reduce efficiency but won't shut down TCP
	- use DF=1 with PLPMTUD
		this allows ICMP frag-needed to be dropped

The security benefits of PLPMTUD are more significant when ICMPs are
dropped more than when they are spoofed, but it can be noted.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko341sACgkQE5f5cImnZruR3gCgvJVChK96Gf8moejptPAu4RP7
1CgAnipyWxdfj+pzb4MN7RSv7ON3HmIx
=ynAC
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun 16 12:09:57 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA50C3A6BA4 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Level: 
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk0A+vnq5eKI for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 12:09:57 -0700 (PDT)
Received: from mail-gx0-f168.google.com (mail-gx0-f168.google.com [209.85.217.168]) by core3.amsl.com (Postfix) with ESMTP id D1AAD3A6951 for <tcpm@ietf.org>; Tue, 16 Jun 2009 12:09:56 -0700 (PDT)
Received: by gxk12 with SMTP id 12so648497gxk.13 for <tcpm@ietf.org>; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=wUSWbA4bkITQlzm/0d/xFp1XWCWeXaq1cLrF4/xSNk8=; b=fWmvgOyUJWp9R28WMzdrF6C/vi8HcZDy4a1IKL426XFLdn31YlcF1O6+LWtWbYvvUu 5STrO7t/bEw9W8FmX35uuTxhSzgVkzr/w2n/+plf7rc9/h/fZnizsxHMfTiWxK7AOlF7 4gcuq9blyr+HjQArbYCBSrwBRQYaUnQm8aS+8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=L3zb+GvcffIvIqCmaWXp30+wg+WUtzmJ3nwT3gI27NIvv9fxhi+UUlBmoreJty+DeT B+/Txe6vDYDkbWgqqJCXe/5pw/Azx6QiibBlwO4D6Hamy7SIIkIRnqcMQSCGrbPO65AA 92kkIVJjFswZQUuLTypJqXSlkb5m4R4t5v8Q4=
Received: by 10.90.26.3 with SMTP id 3mr7510451agz.27.1245179380572; Tue, 16 Jun 2009 12:09:40 -0700 (PDT)
Received: from ?190.48.201.80? ([190.48.201.80]) by mx.google.com with ESMTPS id 30sm239364agc.29.2009.06.16.12.09.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 12:09:39 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A37EDEC.1030908@gont.com.ar>
Date: Tue, 16 Jun 2009 16:09:32 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu>
In-Reply-To: <4A37E494.60904@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 19:09:58 -0000

Joe Touch wrote:

>>>> I think that for the sake of the "principle of least surprise", ICMP
>>>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.
>>> Please explain why you think that TCP-AO needs more strict advice in
>>> this regard than IPsec.
>> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
>> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
>> to get into the details of how a specific transport protocol (TCP) would
>> react to specific ICMP error messages.
> 
> It does, though, in detail.

Can you quote the text you are referring to, or provide a citation to
the specific Section you are referring to?



>> In the case of TCP-AO, it's TCP specific, and thus I believe it should
>> provide stricter advice wrt how TCP should react to ICMP error messages
>> when they are received for connections that employ TCP-AO.
> 
> It's probably useful to split out the discussion of ICMP to a separate
> section. However, the advice therein seems like it should still not
> exceed what is in 4301 for the same reason for the same transport
> protocol - there are pros and cons of either leaving open or closing
> ICMP handling.

As I mentioned, IPsec is by far more general. And thus it sort of makes
sense to avoid being specific about any protocol that it could possibly
encapsulate.

TCP-AO is TCP-specific. And IMHO it would thus make sense for the
document to be as specific/detailed as necessary.

I guess you could come up with some scenario in which it makes sense to
process ICMP messages for connections that employ TCP-AO. However,
principle of least surprise: one of the main drivers for TCP MD5 was to
mitigate connection-reset attacks. Thus, by default, you should close
the avenue of ICMP-based attacks, too. IMO, that is the safe default.



> This document is not a place where the difference between hard and soft
> ICMPs and TCP opening vs. established should be resolved, since it has
> not been resolved for TCP without authentication, and authentication
> does not apply to the ICMP messages.

Agreed. Easier: ignore ICMP error messages, or "do not abort connections
in response to ICMP error messages".



>>> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
>>> particular recommendations of implementation. We would need to be
>>> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
>>> deployment.
>> I believe it could/should be suggested that PLPMTUD be implemented
>> without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
>> leaves it open as to whether PMTUD should only be implemented for
>> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).
> 
> There are a few possibilities:
> 
> 	- use DF=0

Could be an option. However, considering that the IP ID field is 16-bits
long, I don't think that relying on IP fragmentation should not be
considered a viable option nowadays.



> 	- use DF=1 with PMTUD
> 		this requires ICMP frag-needed be passed
> 		which opens a vulnerability on that ICMP type
> 		however, the attack of additional frag-neededs
> 		could reduce efficiency but won't shut down TCP
> 	- use DF=1 with PLPMTUD
> 		this allows ICMP frag-needed to be dropped
> 
> The security benefits of PLPMTUD are more significant when ICMPs are
> dropped more than when they are spoofed, but it can be noted.

FWIW, if you implement the PMTUD counter-measure described in the ICMP
attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
security drawback of the traditional PMTUD (check for progress on the
connection before honoring the ICMP error message).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 16 14:03:31 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8867B3A6B78 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 14:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO2gbd2DHxmS for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 14:03:30 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 3F64B3A697E for <tcpm@ietf.org>; Tue, 16 Jun 2009 14:03:26 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GKwtRC018874; Tue, 16 Jun 2009 13:58:57 -0700 (PDT)
Message-ID: <4A38078F.2040703@isi.edu>
Date: Tue, 16 Jun 2009 13:58:55 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar>
In-Reply-To: <4A37EDEC.1030908@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 21:03:31 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>>> I think that for the sake of the "principle of least surprise", ICMP
>>>>> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.
>>>> Please explain why you think that TCP-AO needs more strict advice in
>>>> this regard than IPsec.
>>> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
>>> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
>>> to get into the details of how a specific transport protocol (TCP) would
>>> react to specific ICMP error messages.
>> It does, though, in detail.
> 
> Can you quote the text you are referring to, or provide a citation to
> the specific Section you are referring to?

Section 6.

It discusses PMTU and unreachables, neither of which have much impact on
protocols that don't establish connections. UDP passes ICMPs up, and
generates them when the port isn't listening, but otherwise does not
interact with ICMP.

>>> In the case of TCP-AO, it's TCP specific, and thus I believe it should
>>> provide stricter advice wrt how TCP should react to ICMP error messages
>>> when they are received for connections that employ TCP-AO.
>> It's probably useful to split out the discussion of ICMP to a separate
>> section. However, the advice therein seems like it should still not
>> exceed what is in 4301 for the same reason for the same transport
>> protocol - there are pros and cons of either leaving open or closing
>> ICMP handling.
> 
> As I mentioned, IPsec is by far more general. And thus it sort of makes
> sense to avoid being specific about any protocol that it could possibly
> encapsulate.

As I said above, IPsec is fairly specific about the handling of ICMPs
and reasons thereof. Those reasons apply primarily to TCP - including
when to both ignore ICMPs and when they should not be ignored.

> TCP-AO is TCP-specific. And IMHO it would thus make sense for the
> document to be as specific/detailed as necessary.
> 
> I guess you could come up with some scenario in which it makes sense to
> process ICMP messages for connections that employ TCP-AO. However,
> principle of least surprise: one of the main drivers for TCP MD5 was to
> mitigate connection-reset attacks. Thus, by default, you should close
> the avenue of ICMP-based attacks, too. IMO, that is the safe default.

Principle of least surprise also means not making a TCP-AO connection
need to wait for a full timeout even when an endpoint cannot be reached,
whether during a connection or during establishment. It also means not
turning a functioning PMTUD mechanism into a black hole.

As 4301 notes, there are good reasons for either way of configuring an
endpoint - endpoints it is intended to protect from replays and
connection interruption as well.

>> This document is not a place where the difference between hard and soft
>> ICMPs and TCP opening vs. established should be resolved, since it has
>> not been resolved for TCP without authentication, and authentication
>> does not apply to the ICMP messages.
> 
> Agreed. Easier: ignore ICMP error messages, or "do not abort connections
> in response to ICMP error messages".

Ignore disables valid PMTUD and valid connection termination
indications. Do not abort ignores the latter. Again, there is no reason
to *default* to this case.

I believe letting the user configure whether specific ICMPs are passed
or ignored covers the needed functionality.

>>>> We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
>>>> particular recommendations of implementation. We would need to be
>>>> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
>>>> deployment.
>>> I believe it could/should be suggested that PLPMTUD be implemented
>>> without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
>>> leaves it open as to whether PMTUD should only be implemented for
>>> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).
>> There are a few possibilities:
>>
>> 	- use DF=0
> 
> Could be an option. However, considering that the IP ID field is 16-bits
> long, I don't think that relying on IP fragmentation should not be
> considered a viable option nowadays.

It is both viable and currently in widespread use. Discussion of that
field should happen on the INTAREA list, not here, but as I noted the
proposed update to 791 makes that ID field useful so long as DF=0 or the
packet has already been fragmented, and the ID is unique over some
multiple of the expected reordering - not just unique within 2MSL as is
the current requirement.

>> 	- use DF=1 with PMTUD
>> 		this requires ICMP frag-needed be passed
>> 		which opens a vulnerability on that ICMP type
>> 		however, the attack of additional frag-neededs
>> 		could reduce efficiency but won't shut down TCP
>> 	- use DF=1 with PLPMTUD
>> 		this allows ICMP frag-needed to be dropped
>>
>> The security benefits of PLPMTUD are more significant when ICMPs are
>> dropped more than when they are spoofed, but it can be noted.
> 
> FWIW, if you implement the PMTUD counter-measure described in the ICMP
> attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
> security drawback of the traditional PMTUD (check for progress on the
> connection before honoring the ICMP error message).

That's an *if*. We're not modifying TCP functionality as part of TCP-AO;
we're extending it to support security. Changes of the nature you
propose may be useful in conjunction once standardized, but until we
make that case for TCP we can't add it to TCP-AO, IMO.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKOAePE5f5cImnZrsRAn0tAKCN+2xduqYoJ4TzBOwN9FZcECqFggCg7gn8
Y5YE3pjk/rAEGeVrwRBCU8s=
=EtH6
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun 16 15:13:51 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9F828C1C3 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 15:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.367
X-Spam-Level: 
X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD3zsJ8-ZyxX for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 15:13:50 -0700 (PDT)
Received: from mail-gx0-f168.google.com (mail-gx0-f168.google.com [209.85.217.168]) by core3.amsl.com (Postfix) with ESMTP id E0BCC28C1C2 for <tcpm@ietf.org>; Tue, 16 Jun 2009 15:13:49 -0700 (PDT)
Received: by gxk12 with SMTP id 12so660369gxk.13 for <tcpm@ietf.org>; Tue, 16 Jun 2009 15:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ZOircO/88cM9HrELZCOKepGN2eyK2ZusnxC5Ixv2Bps=; b=Ng7J9fQqj8UzQRk8sxsmmnXyPTzBR8nr3mfm2C4cVD81BajuA58vBFpOvR3v2J3BZJ HXi1YhJ6QmZGw8UfxH9YfZAFkb9+TSNk9dFkdCpj4B6oSCxdL7Sw5HYK5CLk6YWIiNKq hITWnlA9zpt5t3xMvmXRzEqiz103RCFuN438Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=VSgoSQQyjzHlQiCZ+xIJaDQ+PggDEtncyTrJQC05+dhNl7eBJWfB29JL7q7I3SGvQn J8RJEIab+Kp7bjpggEtBmRpSwR41T//elW/YCfvtURXGmRH+3uOn1+bA7EHWynefsObJ 054n29alBP3IPAy89Y+a7MLRC8sF8JHa4WBvg=
Received: by 10.151.139.7 with SMTP id r7mr16578336ybn.109.1245190437561; Tue, 16 Jun 2009 15:13:57 -0700 (PDT)
Received: from ?190.48.201.80? ([190.48.201.80]) by mx.google.com with ESMTPS id 6sm164039ywp.54.2009.06.16.15.13.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 15:13:56 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A38191D.4010604@gont.com.ar>
Date: Tue, 16 Jun 2009 19:13:49 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu>
In-Reply-To: <4A38078F.2040703@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 22:13:51 -0000

Joe Touch wrote:

>>>> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
>>>> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
>>>> to get into the details of how a specific transport protocol (TCP) would
>>>> react to specific ICMP error messages.
>>> It does, though, in detail.
>> Can you quote the text you are referring to, or provide a citation to
>> the specific Section you are referring to?
> 
> Section 6.
> 
> It discusses PMTU and unreachables, neither of which have much impact on
> protocols that don't establish connections. UDP passes ICMPs up, and
> generates them when the port isn't listening, but otherwise does not
> interact with ICMP.

That's your assessment. And while I may agree with it, that's not what
the spec says. The only ICMP unreachable about which the spec talks with
some level of detail is "frag needed". For instance, it never mentions
the possibility of ICMP unreachables of being used for connection reset
attacks.


>> As I mentioned, IPsec is by far more general. And thus it sort of makes
>> sense to avoid being specific about any protocol that it could possibly
>> encapsulate.
> 
> As I said above, IPsec is fairly specific about the handling of ICMPs
> and reasons thereof. Those reasons apply primarily to TCP - including
> when to both ignore ICMPs and when they should not be ignored.

Joe, I've just read Section 6, and there's no such a thing. Please quote
text from that section which assesses ICMP hard errors, and prove me wrong.



>> I guess you could come up with some scenario in which it makes sense to
>> process ICMP messages for connections that employ TCP-AO. However,
>> principle of least surprise: one of the main drivers for TCP MD5 was to
>> mitigate connection-reset attacks. Thus, by default, you should close
>> the avenue of ICMP-based attacks, too. IMO, that is the safe default.
> 
> Principle of least surprise also means not making a TCP-AO connection
> need to wait for a full timeout even when an endpoint cannot be reached,
> whether during a connection or during establishment. 

We have debated RFC 5461 for years (literally), and you know care about
long delays in connection establishment attempts? That said, if you were
able to establish the connection in the first place, chances are that
you will receive soft errors, not hard errors. Therefore you wouldn't be
aborting the connection, anyway. For connection establishment, you may
be right... but RFC 5461 seemed controversial for connections that
didn't employ authentication, and you now consider it acceptable for
"authenticated" connections?

That said, TCP-AO/MD5 are meant for security, not performance. If you
enable it, you expect security, not performance. Having TCP-AO and then
being spec-wise vulnerable (by default) to trivial ICMP attacks would be
non-sensical.



> It also means not
> turning a functioning PMTUD mechanism into a black hole.

Agreed. That's why I said "frag needed" are a different issue.



>>> This document is not a place where the difference between hard and soft
>>> ICMPs and TCP opening vs. established should be resolved, since it has
>>> not been resolved for TCP without authentication, and authentication
>>> does not apply to the ICMP messages.
>> Agreed. Easier: ignore ICMP error messages, or "do not abort connections
>> in response to ICMP error messages".
> 
> Ignore disables valid PMTUD and valid connection termination
> indications. 

I was meaning any ICMP error messages other than "frag needed" in this case.



> Do not abort ignores the latter. Again, there is no reason
> to *default* to this case.

Yes. I enable TCP-AO to protect my connections against reset attacks.
Why would I bother doing it if you don't close the even-easier ICMP
vector????



> I believe letting the user configure whether specific ICMPs are passed
> or ignored covers the needed functionality.

You expect the user to know too much. Pick a safe default, and then let
the knowledgeable user override that default (if needed).



>>> There are a few possibilities:
>>>
>>> 	- use DF=0
>> Could be an option. However, considering that the IP ID field is 16-bits
>> long, I don't think that relying on IP fragmentation should not be
>> considered a viable option nowadays.
> 
> It is both viable and currently in widespread use. Discussion of that
> field should happen on the INTAREA list, not here, but as I noted the
> proposed update to 791 makes that ID field useful so long as DF=0 or the
> packet has already been fragmented, and the ID is unique over some
> multiple of the expected reordering - not just unique within 2MSL as is
> the current requirement.

I had read your proposal in the past, but do not recall the details
right now. However, the problems of fragmentation has been beaten to
death. (e.g., the Matthis/Heffner RFC).


>>> The security benefits of PLPMTUD are more significant when ICMPs are
>>> dropped more than when they are spoofed, but it can be noted.
>> FWIW, if you implement the PMTUD counter-measure described in the ICMP
>> attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
>> security drawback of the traditional PMTUD (check for progress on the
>> connection before honoring the ICMP error message).
> 
> That's an *if*. We're not modifying TCP functionality as part of TCP-AO;
> we're extending it to support security. Changes of the nature you
> propose may be useful in conjunction once standardized, but until we
> make that case for TCP we can't add it to TCP-AO, IMO.

Ignoring ICMP errors is sort of the same thing: you're not complying
with the specs. At that point (i.e., once you have decided not to comply
with the standard), whether you simply ignore the ICMP errors or you
ignore them based on connection progress, is a minor detail.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 16 16:01:47 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9705628C0EF for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAElKPLyqW9b for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:01:46 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 420833A6C6B for <tcpm@ietf.org>; Tue, 16 Jun 2009 16:01:46 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5GN1Sqh021796; Tue, 16 Jun 2009 16:01:30 -0700 (PDT)
Message-ID: <4A382448.7080705@isi.edu>
Date: Tue, 16 Jun 2009 16:01:28 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu> <4A38191D.4010604@gont.com.ar>
In-Reply-To: <4A38191D.4010604@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 23:01:47 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>>>> Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
>>>>> not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
>>>>> to get into the details of how a specific transport protocol (TCP) would
>>>>> react to specific ICMP error messages.
>>>> It does, though, in detail.
>>> Can you quote the text you are referring to, or provide a citation to
>>> the specific Section you are referring to?
>> Section 6.
>>
>> It discusses PMTU and unreachables, neither of which have much impact on
>> protocols that don't establish connections. UDP passes ICMPs up, and
>> generates them when the port isn't listening, but otherwise does not
>> interact with ICMP.
> 
> That's your assessment. And while I may agree with it, that's not what
> the spec says. The only ICMP unreachable about which the spec talks with
> some level of detail is "frag needed". For instance, it never mentions
> the possibility of ICMP unreachables of being used for connection reset
> attacks.

6.  ICMP Processing

   ...There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.

then further...

6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
        Boundary

   Figure 3 in Section 5.2 shows a distinct ICMP processing module on
   the unprotected side of the IPsec boundary, for processing ICMP
   messages (error or otherwise) that are addressed to the IPsec device
   and that are not protected via AH or ESP.  An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.

How do you interpret denial or degradation w.r.t. destination unreachables?

 >>> As I mentioned, IPsec is by far more general. And thus it sort of makes
>>> sense to avoid being specific about any protocol that it could possibly
>>> encapsulate.
>> As I said above, IPsec is fairly specific about the handling of ICMPs
>> and reasons thereof. Those reasons apply primarily to TCP - including
>> when to both ignore ICMPs and when they should not be ignored.
> 
> Joe, I've just read Section 6, and there's no such a thing. Please quote
> text from that section which assesses ICMP hard errors, and prove me wrong.


6.0 says that this section is exclusively about error messages of type
dest unreachable:

   ... There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.

Sec 6.1.1. says that these can result in denial of service:

   ...An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.  This suggests that, in general, it would be
   desirable to ignore such messages.

TCP and other connection oriented protocols are a primary user of such
error messages; UDP sends port unreachable, but otherwise does not
itself react to ICMPs.

   ...However, many ICMP messages will
   be received by hosts or security gateways from unauthenticated
   sources, e.g., routers in the public Internet.  Ignoring these ICMP
   messages can degrade service, e.g., because of a failure to process
   PMTU message and redirection messages.  Thus, there is also a
   motivation for accepting and acting upon unauthenticated ICMP
   messages.

TCP and other connection oriented protocols are the primary users of
PMTU messages.

>>> I guess you could come up with some scenario in which it makes sense to
>>> process ICMP messages for connections that employ TCP-AO. However,
>>> principle of least surprise: one of the main drivers for TCP MD5 was to
>>> mitigate connection-reset attacks. Thus, by default, you should close
>>> the avenue of ICMP-based attacks, too. IMO, that is the safe default.
>> Principle of least surprise also means not making a TCP-AO connection
>> need to wait for a full timeout even when an endpoint cannot be reached,
>> whether during a connection or during establishment. 
> 
> We have debated RFC 5461 for years (literally), and you know care about
> long delays in connection establishment attempts? That said, if you were
> able to establish the connection in the first place, chances are that
> you will receive soft errors, not hard errors. Therefore you wouldn't be
> aborting the connection, anyway. For connection establishment, you may
> be right... but RFC 5461 seemed controversial for connections that
> didn't employ authentication, and you now consider it acceptable for
> "authenticated" connections?

I am NOT in favor of changing TCPs reaction to ICMPs in TCP-AO, any more
than I was in RFC5461.

> That said, TCP-AO/MD5 are meant for security, not performance. If you
> enable it, you expect security, not performance. Having TCP-AO and then
> being spec-wise vulnerable (by default) to trivial ICMP attacks would be
> non-sensical.

IPsec has exactly the same tradeoff, yet fails to come to the same
conclusion. It is just as sensible to make the same recommendation here
as IPsec does - let the user decide.

>> It also means not
>> turning a functioning PMTUD mechanism into a black hole.
> 
> Agreed. That's why I said "frag needed" are a different issue.

The same thing happens when redirects are ignored - black hole.

>>>> This document is not a place where the difference between hard and soft
>>>> ICMPs and TCP opening vs. established should be resolved, since it has
>>>> not been resolved for TCP without authentication, and authentication
>>>> does not apply to the ICMP messages.
>>> Agreed. Easier: ignore ICMP error messages, or "do not abort connections
>>> in response to ICMP error messages".
>> Ignore disables valid PMTUD and valid connection termination
>> indications. 
> 
> I was meaning any ICMP error messages other than "frag needed" in this case.

See above; it's more than just frag needed.

>> Do not abort ignores the latter. Again, there is no reason
>> to *default* to this case.
> 
> Yes. I enable TCP-AO to protect my connections against reset attacks.
> Why would I bother doing it if you don't close the even-easier ICMP
> vector????

There are cases where, e.g., replays are possible but it is much more
difficult to generate packets. There are also cases where some IP
addresses can be spoofed but not others (e.g., where reverse path
validation is done).

Regardless, it's up to the user to decide. I'm not saying they would
never decide to block ICMPs, but I don't agree that we can disable ICMP
by default.

>> I believe letting the user configure whether specific ICMPs are passed
>> or ignored covers the needed functionality.
> 
> You expect the user to know too much. Pick a safe default, and then let
> the knowledgeable user override that default (if needed).

TCP-AO isn't enabled by default either. And systems that have
unpredictable behavior (e.g., won't work - not just won't be fast -
because valid ICMPs won't get through) get turned OFF.

I expect a user to either disable or enable ICMPs. An implementation can
do what it wants regarding defaults.

>>>> There are a few possibilities:
>>>>
>>>> 	- use DF=0
>>> Could be an option. However, considering that the IP ID field is 16-bits
>>> long, I don't think that relying on IP fragmentation should not be
>>> considered a viable option nowadays.
>> It is both viable and currently in widespread use. Discussion of that
>> field should happen on the INTAREA list, not here, but as I noted the
>> proposed update to 791 makes that ID field useful so long as DF=0 or the
>> packet has already been fragmented, and the ID is unique over some
>> multiple of the expected reordering - not just unique within 2MSL as is
>> the current requirement.
> 
> I had read your proposal in the past, but do not recall the details
> right now. However, the problems of fragmentation has been beaten to
> death. (e.g., the Matthis/Heffner RFC).

Matthis/Heffner describes some problems. My draft proposes a change to
the standard, and was written with Mathis FWIW. If you want to discuss
it further, again, please do so on the INTAREA list.

>>>> The security benefits of PLPMTUD are more significant when ICMPs are
>>>> dropped more than when they are spoofed, but it can be noted.
>>> FWIW, if you implement the PMTUD counter-measure described in the ICMP
>>> attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
>>> security drawback of the traditional PMTUD (check for progress on the
>>> connection before honoring the ICMP error message).
>> That's an *if*. We're not modifying TCP functionality as part of TCP-AO;
>> we're extending it to support security. Changes of the nature you
>> propose may be useful in conjunction once standardized, but until we
>> make that case for TCP we can't add it to TCP-AO, IMO.
> 
> Ignoring ICMP errors is sort of the same thing: you're not complying
> with the specs. At that point (i.e., once you have decided not to comply
> with the standard), whether you simply ignore the ICMP errors or you
> ignore them based on connection progress, is a minor detail.

The WG did not think so, which is why 5461 was limited to describing
what had been implemented and is Informational rather than making a
recommendation and being BCP or Standards Track (BTW, any idea who did
the implementation you were documenting?)

Joe

joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKOCRIE5f5cImnZrsRAilRAKD5xXlUT/tXXJH+NL6212IS315bCgCg1TDW
qt7HJY9HF0vr0q5o0ShcHlY=
=If3n
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun 16 16:26:03 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440FB28C123 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level: 
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=0.548,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GHGvuRj07sU for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 16:26:01 -0700 (PDT)
Received: from mail-yx0-f115.google.com (mail-yx0-f115.google.com [209.85.210.115]) by core3.amsl.com (Postfix) with ESMTP id E9F0E3A6C8C for <tcpm@ietf.org>; Tue, 16 Jun 2009 16:26:00 -0700 (PDT)
Received: by yxe13 with SMTP id 13so4400yxe.29 for <tcpm@ietf.org>; Tue, 16 Jun 2009 16:26:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=E7KBbyO9RaWshRcrEdiRwG1mcXAK9byjYsZWB5WSMpA=; b=oRrPpA3KrZVUwc0zVYrD616aFf9wT/bNQ8bpmpuWpUJ0fthy0UiwUOfk7QsKedacS/ y24zI1TVW4e5cOK3NCWgUNczuh/SbE9GYvQwuU+afBAlOF/jR4zJC8voAru7J3fCvXGi N+F+9OE1n04xBnCClY7FR5cOXm75KlwjDR8mg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=BMhYugtVrv2E5s574Hmg6A9jBQKeXCOGbaWGIwYA5CNf1+ebDnB4Fa7AMZFZVubD0j 4Op1qV93Ahbn8Y2IHiZQY5h2zWfuGITEShl3d2GoDM2H8D+F9ZFHc4FcLRmRSILLQmV1 Dei/FwieNRDPHzYEjswI0nS+jAeoZfICORV1s=
Received: by 10.90.100.11 with SMTP id x11mr7693879agb.71.1245194768599; Tue, 16 Jun 2009 16:26:08 -0700 (PDT)
Received: from ?190.48.255.49? ([190.48.255.49]) by mx.google.com with ESMTPS id 1sm566483agb.48.2009.06.16.16.26.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 16:26:07 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A382A08.1020302@gont.com.ar>
Date: Tue, 16 Jun 2009 20:26:00 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu> <4A38191D.4010604@gont.com.ar> <4A382448.7080705@isi.edu>
In-Reply-To: <4A382448.7080705@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 16 Jun 2009 23:26:03 -0000

Joe Touch wrote:

[talking about RFC 4301]
>>> It discusses PMTU and unreachables, neither of which have much impact on
>>> protocols that don't establish connections. UDP passes ICMPs up, and
>>> generates them when the port isn't listening, but otherwise does not
>>> interact with ICMP.
>> That's your assessment. And while I may agree with it, that's not what
>> the spec says. The only ICMP unreachable about which the spec talks with
>> some level of detail is "frag needed". For instance, it never mentions
>> the possibility of ICMP unreachables of being used for connection reset
>> attacks.
> 
> 6.  ICMP Processing
> 
>    ...There are two
>    categories of ICMP traffic: error messages (e.g., type = destination
>    unreachable) and non-error messages (e.g., type = echo).  This
>    section applies exclusively to error messages.
> 
> then further...
> 
> 6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
>         Boundary
> 
>    Figure 3 in Section 5.2 shows a distinct ICMP processing module on
>    the unprotected side of the IPsec boundary, for processing ICMP
>    messages (error or otherwise) that are addressed to the IPsec device
>    and that are not protected via AH or ESP.  An ICMP message of this
>    sort is unauthenticated, and its processing may result in denial or
>    degradation of service.
> 
> How do you interpret denial or degradation w.r.t. destination unreachables?

Again, that's your personal assessment, not what the spec says.
What service does TCP provide? - Data transfer. Is it degraded for not
reacting to ICMP errors? No. For instance, nobody resets established
connections in response to ICMP error messages. So if you consider that
a "degraded service", we all use scuh a degraded service.

And, btw, in this quoted para, it's "its *processing*" (i.e., *honoring*
the ICMPs) that may lead to denial or degradation of service.



> 6.0 says that this section is exclusively about error messages of type
> dest unreachable:
> 
>    ... There are two
>    categories of ICMP traffic: error messages (e.g., type = destination
>    unreachable) and non-error messages (e.g., type = echo).  This
>    section applies exclusively to error messages.
> 
> Sec 6.1.1. says that these can result in denial of service:
> 
>    ...An ICMP message of this
>    sort is unauthenticated, and its processing may result in denial or
>    degradation of service.  This suggests that, in general, it would be
>    desirable to ignore such messages.
> 
> TCP and other connection oriented protocols are a primary user of such
> error messages; UDP sends port unreachable, but otherwise does not
> itself react to ICMPs.

But the spec is not talking about the transport protocol reacting to
these messages, but about the processing of them. In the case of UDP,
that would be the processing of ICMP errors by the app layer.



>    ...However, many ICMP messages will
>    be received by hosts or security gateways from unauthenticated
>    sources, e.g., routers in the public Internet.  Ignoring these ICMP
>    messages can degrade service, e.g., because of a failure to process
>    PMTU message and redirection messages.  Thus, there is also a
>    motivation for accepting and acting upon unauthenticated ICMP
>    messages.
> 
> TCP and other connection oriented protocols are the primary users of
> PMTU messages.

In the case of UDP, the app would be the user of those messages.
Actually, in the case of TCP the app could also be a user of those
messages (RFC 1122 about relaying ICMP errors to apps).



>>>> I guess you could come up with some scenario in which it makes sense to
>>>> process ICMP messages for connections that employ TCP-AO. However,
>>>> principle of least surprise: one of the main drivers for TCP MD5 was to
>>>> mitigate connection-reset attacks. Thus, by default, you should close
>>>> the avenue of ICMP-based attacks, too. IMO, that is the safe default.
>>> Principle of least surprise also means not making a TCP-AO connection
>>> need to wait for a full timeout even when an endpoint cannot be reached,
>>> whether during a connection or during establishment. 
>> We have debated RFC 5461 for years (literally), and you know care about
>> long delays in connection establishment attempts? That said, if you were
>> able to establish the connection in the first place, chances are that
>> you will receive soft errors, not hard errors. Therefore you wouldn't be
>> aborting the connection, anyway. For connection establishment, you may
>> be right... but RFC 5461 seemed controversial for connections that
>> didn't employ authentication, and you now consider it acceptable for
>> "authenticated" connections?
> 
> I am NOT in favor of changing TCPs reaction to ICMPs in TCP-AO, any more
> than I was in RFC5461.

You are concerned that ignoring ICMPs may lead to long timeouts. What's
the difference?



>> That said, TCP-AO/MD5 are meant for security, not performance. If you
>> enable it, you expect security, not performance. Having TCP-AO and then
>> being spec-wise vulnerable (by default) to trivial ICMP attacks would be
>> non-sensical.
> 
> IPsec has exactly the same tradeoff, yet fails to come to the same
> conclusion. 

We're not here to rehash the past for the sake of it. The fact that some
spec does something doesn't mean that we have to repeat the same thing
in new work.

FWIW, from that perspective, you could have ignored the ICMP attacks
issue altogether, as RFC 2385 does not even talk about it. -- No need to
say that I'm happy that the TCP-AO I-D is different in this respect.



>>> It also means not
>>> turning a functioning PMTUD mechanism into a black hole.
>> Agreed. That's why I said "frag needed" are a different issue.
> 
> The same thing happens when redirects are ignored - black hole.

No. Redirects are an optimization. honoring redirects without something
like GTSM (which you cannot really enforce) would be dumb nowadays.



>>> Do not abort ignores the latter. Again, there is no reason
>>> to *default* to this case.
>> Yes. I enable TCP-AO to protect my connections against reset attacks.
>> Why would I bother doing it if you don't close the even-easier ICMP
>> vector????
> 
> There are cases where, e.g., replays are possible but it is much more
> difficult to generate packets. There are also cases where some IP
> addresses can be spoofed but not others (e.g., where reverse path
> validation is done).

>From the Intro of RFC 2385:

"   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets."

Again, I believe TCP-AO should default to ignoring ICMP hard errors, at
least for the established states.



> Regardless, it's up to the user to decide. I'm not saying they would
> never decide to block ICMPs, but I don't agree that we can disable ICMP
> by default.

Does the *user* really need to know about TCP internals such as how TCP
reacts to those error messages?



>>> I believe letting the user configure whether specific ICMPs are passed
>>> or ignored covers the needed functionality.
>> You expect the user to know too much. Pick a safe default, and then let
>> the knowledgeable user override that default (if needed).
> 
> TCP-AO isn't enabled by default either. And systems that have
> unpredictable behavior (e.g., won't work - not just won't be fast -
> because valid ICMPs won't get through) get turned OFF.
> 
> I expect a user to either disable or enable ICMPs. An implementation can
> do what it wants regarding defaults.

Do you really expect the user to go and play with the switches for each
message type/code? I don't, and wouldn't want the general TCP-AO user to
do so.


>>> It is both viable and currently in widespread use. Discussion of that
>>> field should happen on the INTAREA list, not here, but as I noted the
>>> proposed update to 791 makes that ID field useful so long as DF=0 or the
>>> packet has already been fragmented, and the ID is unique over some
>>> multiple of the expected reordering - not just unique within 2MSL as is
>>> the current requirement.
>> I had read your proposal in the past, but do not recall the details
>> right now. However, the problems of fragmentation has been beaten to
>> death. (e.g., the Matthis/Heffner RFC).
> 
> Matthis/Heffner describes some problems. My draft proposes a change to
> the standard, and was written with Mathis FWIW. If you want to discuss
> it further, again, please do so on the INTAREA list.

FWIW, I'm not against your proposal. Actually, IIRC, I was in general
agreement with it.



>> Ignoring ICMP errors is sort of the same thing: you're not complying
>> with the specs. At that point (i.e., once you have decided not to comply
>> with the standard), whether you simply ignore the ICMP errors or you
>> ignore them based on connection progress, is a minor detail.
> 
> The WG did not think so, 

I was talking about the PMTUD mitigation in the ICMP attacks I-D, and
not about RFC 5461.


> which is why 5461 was limited to describing
> what had been implemented and is Informational rather than making a
> recommendation and being BCP or Standards Track (BTW, any idea who did
> the implementation you were documenting?)

The soft errors implementation? I don't know which developer, but it was
implemented in Linux and a number of other systems, well before I
started working on RFC 5461.

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 16 17:14:53 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737693A696F for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 17:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH103tY8uI+b for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 17:14:52 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9E69B3A68AD for <tcpm@ietf.org>; Tue, 16 Jun 2009 17:14:52 -0700 (PDT)
Received: from [128.9.168.63] (bet.isi.edu [128.9.168.63]) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id n5H0Dj7o021799; Tue, 16 Jun 2009 17:13:46 -0700 (PDT)
Message-ID: <4A383539.3080403@isi.edu>
Date: Tue, 16 Jun 2009 17:13:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu> <4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu> <4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu> <4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu> <4A38191D.4010604@gont.com.ar> <4A382448.7080705@isi.edu> <4A382A08.1020302@gont.com.ar>
In-Reply-To: <4A382A08.1020302@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: n5H0Dj7o021799
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 00:14:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think we both agree that the text on ICMP handling should be moved out
of the security considerations section and put it its own section. The
question is what to put there.

You prefer defaults, and are recommending ICMP handling similar to that
in documents the WG has decided not to recommend for TCP not running AO.

I want to leave TCP-AO's handling of ICMPs the same as IPsec's - up to
the user.

Can others please weigh in?

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKODU5E5f5cImnZrsRAi6eAKDmiAcJtGlmECbmMU60CVkzAeSREQCdGBjE
hMsnjO6e2fhEoik8DiaA6kU=
=fqHB
-----END PGP SIGNATURE-----

From fernando.gont.netbook.win@gmail.com  Tue Jun 16 18:00:56 2009
Return-Path: <fernando.gont.netbook.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B903A6880 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 18:00:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.188
X-Spam-Level: 
X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyHBI7P160ns for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 18:00:56 -0700 (PDT)
Received: from mail-yx0-f131.google.com (mail-yx0-f131.google.com [209.85.210.131]) by core3.amsl.com (Postfix) with ESMTP id 03A3E3A6C5A for <tcpm@ietf.org>; Tue, 16 Jun 2009 18:00:55 -0700 (PDT)
Received: by yxe37 with SMTP id 37so412978yxe.15 for <tcpm@ietf.org>; Tue, 16 Jun 2009 18:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=1ot5MnJ9Xil8A6v6A+ATTpiGd8y5rdYhU01D/ST8Iq8=; b=vgumH/5u1Fni6EMCcM+B5TKjEs23nxYB1T1hOBC7davyaUlL5vjf0cc+Nkgbn/n+MQ +X4K4wTn18aYeRDykPLDmfsIhZEgfnr5nEM1dD4lYh2Ahouzym14vZ28jzxtbeESW42K UzWBiCApB6ks5u8FZBhg0c+umTStuEQYuicKM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=PhCPfJvo3dhzRUhRsLSw4VpKxTZ2VQn5e8OFuWqfryW957O5k6zokHeSdt18gLVxXK A4m+apvQo2+11iE+esxp3dvJTU/qyhA8884xtD9/lLlq183cY+Xfbq8W90Qvx5ubbXbx EaW9okw0J65IpgnKkjU2K4aROlrtzMe1TGo28=
Received: by 10.90.70.15 with SMTP id s15mr3839849aga.60.1245199694152; Tue, 16 Jun 2009 17:48:14 -0700 (PDT)
Received: from ?190.48.255.49? ([190.48.255.49]) by mx.google.com with ESMTPS id 38sm678134aga.41.2009.06.16.17.48.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 17:48:13 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4A383D44.4050103@gont.com.ar>
Date: Tue, 16 Jun 2009 21:48:04 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu>	<4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu>	<4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu>	<4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu>	<4A38191D.4010604@gont.com.ar> <4A382448.7080705@isi.edu>	<4A382A08.1020302@gont.com.ar> <4A383539.3080403@isi.edu>
In-Reply-To: <4A383539.3080403@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments	on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 01:00:56 -0000

Joe,

> I think we both agree that the text on ICMP handling should be moved out
> of the security considerations section and put it its own section.

Agreed.


> You prefer defaults, and are recommending ICMP handling similar to that
> in documents the WG has decided not to recommend for TCP not running AO.

Yes. Note that virtually all real implementations already do this for
connections that do not use TCP-AO. Nobody is going to change this for
non-TCP-AO, or even less abort TCP-AO connections in response to ICMP
error messages.



> I want to leave TCP-AO's handling of ICMPs the same as IPsec's - up to
> the user.

Just making my point clear: I think leaving unspecified what to do with
ICMP errore messages would be a bad decision. It might end up with
implementations honoring these error messages, which would mean that
TCP-AO would be (by default) useless for protecting TCP against
ICMP-based reset attacks.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 16 18:28:12 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A353A6DC1 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 18:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hKh5DXLgwcu for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 18:28:07 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17D033A6B55 for <tcpm@ietf.org>; Tue, 16 Jun 2009 18:28:00 -0700 (PDT)
Received: from [128.9.184.173] ([128.9.184.173]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5H1RsVB022677; Tue, 16 Jun 2009 18:27:56 -0700 (PDT)
Message-ID: <4A38469A.2070102@isi.edu>
Date: Tue, 16 Jun 2009 18:27:54 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221796D53C@NDJSSCC01.ndc.nasa.gov>	<4A30BED6.3050308@gont.com.ar>	<4A32BD5F.5030503@isi.edu>	<4A379700.3070808@gont.com.ar> <4A37A551.60800@isi.edu>	<4A37D6FC.4040005@gont.com.ar> <4A37E494.60904@isi.edu>	<4A37EDEC.1030908@gont.com.ar> <4A38078F.2040703@isi.edu>	<4A38191D.4010604@gont.com.ar> <4A382448.7080705@isi.edu>	<4A382A08.1020302@gont.com.ar> <4A383539.3080403@isi.edu> <4A383D44.4050103@gont.com.ar>
In-Reply-To: <4A383D44.4050103@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Fernando Gont <fernando.gont@gmail.com>
Subject: Re: [tcpm] TCP-AO and ICMP attacks (was Re: comments	on	draft-ietf-tcpm-icmp-attacks-05)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 01:28:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe,
> 
>> I think we both agree that the text on ICMP handling should be moved out
>> of the security considerations section and put it its own section.
> 
> Agreed.
> 
> 
>> You prefer defaults, and are recommending ICMP handling similar to that
>> in documents the WG has decided not to recommend for TCP not running AO.
> 
> Yes. Note that virtually all real implementations already do this for
> connections that do not use TCP-AO. Nobody is going to change this for
> non-TCP-AO, or even less abort TCP-AO connections in response to ICMP
> error messages.

This document is standards track, and is not intended to validate the
behavior of those implementations. It also doesn't invalidate them.

Note that I am NOT saying that the default is "ICMPs pass" - I said
NOTHING about a default, just like IPsec says nothing.

>> I want to leave TCP-AO's handling of ICMPs the same as IPsec's - up to
>> the user.
> 
> Just making my point clear: I think leaving unspecified what to do with
> ICMP errore messages would be a bad decision. It might end up with
> implementations honoring these error messages, which would mean that
> TCP-AO would be (by default) useless for protecting TCP against
> ICMP-based reset attacks.

TCP-AO does not have a default for connections without keys either.
IPsec does - they're blocked. If we're not having a default for new
connections, we shouldn't have a default for ICMP.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko4RpoACgkQE5f5cImnZrvAUgCfVtwiAvkuJ300eu7bc3XY6MJg
+8MAniF7ffrDTRa8TyLVb/k3lzX0caET
=B8Em
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Tue Jun 16 22:45:26 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17DC83A6C16 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 22:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn5mvoKyHcB4 for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 22:45:25 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 201133A6BA6 for <tcpm@ietf.org>; Tue, 16 Jun 2009 22:45:25 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A4E0C1BCA23; Tue, 16 Jun 2009 22:45:51 -0700 (PDT)
Date: Tue, 16 Jun 2009 22:45:51 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A37A202.9020500@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090617054551.A4E0C1BCA23@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 05:45:26 -0000

At Tue, 16 Jun 2009 06:45:38 -0700,
Joe Touch wrote:
> Eric Rescorla wrote:
> > At Sat, 06 Jun 2009 11:46:11 -0700,
> > Joe Touch wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi, all,
> >>
> >> One open issue remaining is how to express what was formerly a database
> >> with a particular structure (TAPD, previously TSAD) in ways that impact
> >> rekeying and possibly future master key management protocols. We decided
> >> at the last meeting in SFO to do as follows:
> >>
> >> 	- require that each segment match only one key
> >> 		- segments for established connections must match
> >> 		only one connection key
> >> 		- segments for new connections (SYNs) must match
> >> 		only one master key
> >>
> >> Connection keys never overlap; there would never be two connection keys
> >> with the same keyID and socket pair. The open issue focuses on master
> >> keys, which would more likely be specified with wildcards, masks, or
> >> ranges, esp. for remote port numbers, but also potentially for addresses
> >> or local port numbers. This issue is particularly relevant for rekeying
> >> - - adding new master keys that would result in new connection keys being
> >> derived for existing connections - and how an endpoint would be able to
> >> ensure uniqueness as above.
> >>
> >> Do we need additional constraints to ensure that master key descriptions
> >> never overlap?
> >>
> >> As review, the previous description of keys as a database also implied,
> >> by its structure, constraints on wildcards/masks/ranges. Each TAPD entry
> >> was:
> >>
> >>     a socket pair descriptor
> >>         which may include wildcards or masks
> >>
> >>     one or more MKTs, each of which includes:
> >>         sendID
> >>         recvID
> >>         crypto info:
> >>             master key
> >>             MAC info
> >>             KDF info
> >>
> >> The TAPD was defined so that a segment matched at most one socket pair
> >> descriptor, and that MKTs within that descriptor had distinct sendIDs
> >> and recvIDs.
> >>
> >> If we remove that data structure, it would most obviously be replaced
> >> with MKTs with their own socket descriptors, i.e.:
> >>
> >>     MKT
> >>         socket pair descriptor (may include wildcards/masks)
> >>         sendID
> >>         recvID
> >>         crypto info
> >>
> >> The question that remains is whether MKTs that match a segment all have
> >> identical socket pair descriptors, even down to their
> >> wildcards/ranges/masks (which was previously required). If
> >> not, then how do we ensure that MKTs don't interfere?
> > 
> > I don't understand why this is a problem. The invariant that
> > the system needs to enforce is that for any given packet 
> > there be at most one valid MKT with a given key-id, right?
> 
> KeyID doesn't come into play for outgoing packets, so we can ignore that.
> 
> However, the invariant is twofold:
> 
> 	a) for a given packet, only one MKT applies
> 
> 	b) for two endpoints with multiple MKTs,
> 	the *same* MKT applies.

I don't see that this is true. As I understand the current design
there's no reason that both sides can't use different MKTs
indefinitely.


> >> If we throw our hands up and say this is "implementation detail", then
> >> IMO we could be hobbling any KMP, since there would be no common data
> >> for the KMP to coordinate.
> > 
> > I don't see this. Obviously, any KMP will need some model for
> > how it thinks about keys and any particular implementation of
> > a KMP will need to interact with the system on which it is
> > implemented in order to match that model to the system's
> > implementation, but I don't see how that's a problem. It's
> > not like we're defining a C API for the KMP implementations
> > to call.
> 
> If we don't specify some level of commonality, we can't expect to ever
> define such an API.

I don't consider the design of such an API in IETF 
either necessary or desirable.

-Ekr

From touch@ISI.EDU  Tue Jun 16 23:25:18 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F073A6DCF for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 23:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-mEKjwIvGhM for <tcpm@core3.amsl.com>; Tue, 16 Jun 2009 23:25:17 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 32CBB3A6DDA for <tcpm@ietf.org>; Tue, 16 Jun 2009 23:25:17 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5H6Ot7D021061; Tue, 16 Jun 2009 23:24:57 -0700 (PDT)
Message-ID: <4A388C37.3030703@isi.edu>
Date: Tue, 16 Jun 2009 23:24:55 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com>
In-Reply-To: <20090617054551.A4E0C1BCA23@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 06:25:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> However, the invariant is twofold:
>>
>> 	a) for a given packet, only one MKT applies
>>
>> 	b) for two endpoints with multiple MKTs,
>> 	the *same* MKT applies.
> 
> I don't see that this is true. As I understand the current design
> there's no reason that both sides can't use different MKTs
> indefinitely.

Each side can use a different MKT to transmit. However, if side A uses
MKT X to transmit, then side B needs to know to use MKT X to receive. If
side A matches MKT X on transmit and side B matches MKT Y on receive,
then there's a problem for that connection.

So let's rephrase, recognizing that there are two MKTs at any given time
(one for transmit on each side, and the same pair for receive on the
opposite side).

b) for two endpoints, if a given packet matches MKT on one side during
transmit, it must match the corresponding MKT on the other side during
receive.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko4jDYACgkQE5f5cImnZrtN/ACg+auD2x3yiHy6owI5aeUCePf7
M0IAoKAniNQHEBTxl6LIoSrixtwS4G9m
=8v0e
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Wed Jun 17 07:09:05 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4153A6989 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 07:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlHiNgMYOmhx for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 07:09:05 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id E6B973A6813 for <tcpm@ietf.org>; Wed, 17 Jun 2009 07:09:04 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id A3AB61BCC72; Wed, 17 Jun 2009 07:09:39 -0700 (PDT)
Date: Wed, 17 Jun 2009 07:09:39 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A388C37.3030703@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090617140939.A3AB61BCC72@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 14:09:05 -0000

At Tue, 16 Jun 2009 23:24:55 -0700,
Joe Touch wrote:
> Eric Rescorla wrote:
> ...
> >> However, the invariant is twofold:
> >>
> >> 	a) for a given packet, only one MKT applies
> >>
> >> 	b) for two endpoints with multiple MKTs,
> >> 	the *same* MKT applies.
> > 
> > I don't see that this is true. As I understand the current design
> > there's no reason that both sides can't use different MKTs
> > indefinitely.
> 
> Each side can use a different MKT to transmit. However, if side A uses
> MKT X to transmit, then side B needs to know to use MKT X to receive. If
> side A matches MKT X on transmit and side B matches MKT Y on receive,
> then there's a problem for that connection.
> 
> So let's rephrase, recognizing that there are two MKTs at any given time
> (one for transmit on each side, and the same pair for receive on the
> opposite side).
> 
> b) for two endpoints, if a given packet matches MKT on one side during
> transmit, it must match the corresponding MKT on the other side during
> receive.

Right, but this doesn't require ordering or non-overlapping, as far as
I can tell.  It merely requires that at any time there only be one MKT
corresponding to any given socketpair/key-id.
       
-Ekr

From touch@ISI.EDU  Wed Jun 17 08:42:06 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1FDC28C28B for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 08:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbDCZCM-Eygh for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 08:42:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 85EDA3A6D65 for <tcpm@ietf.org>; Wed, 17 Jun 2009 08:42:00 -0700 (PDT)
Received: from [75.215.131.214] (214.sub-75-215-131.myvzw.com [75.215.131.214]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5HFfqGH003033; Wed, 17 Jun 2009 08:41:54 -0700 (PDT)
Message-ID: <4A390EC0.6070003@isi.edu>
Date: Wed, 17 Jun 2009 08:41:52 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com>
In-Reply-To: <20090617140939.A3AB61BCC72@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 15:42:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Tue, 16 Jun 2009 23:24:55 -0700,
> Joe Touch wrote:
>> Eric Rescorla wrote:
>> ...
>>>> However, the invariant is twofold:
>>>>
>>>> 	a) for a given packet, only one MKT applies
>>>>
>>>> 	b) for two endpoints with multiple MKTs,
>>>> 	the *same* MKT applies.
>>> I don't see that this is true. As I understand the current design
>>> there's no reason that both sides can't use different MKTs
>>> indefinitely.
>> Each side can use a different MKT to transmit. However, if side A uses
>> MKT X to transmit, then side B needs to know to use MKT X to receive. If
>> side A matches MKT X on transmit and side B matches MKT Y on receive,
>> then there's a problem for that connection.
>>
>> So let's rephrase, recognizing that there are two MKTs at any given time
>> (one for transmit on each side, and the same pair for receive on the
>> opposite side).
>>
>> b) for two endpoints, if a given packet matches MKT on one side during
>> transmit, it must match the corresponding MKT on the other side during
>> receive.
> 
> Right, but this doesn't require ordering or non-overlapping, as far as
> I can tell.  It merely requires that at any time there only be one MKT
> corresponding to any given socketpair/key-id.

That is only possible with either non-overlapping or ordering to resolve
overlaps. Note that the MKT has to be unique for incoming packets given
a socketpair/keyid. For outgoing SYNs, the MKT has to be unique within
just a socketpair, because the keyid hasn't been determined yet.

If we prevent overlaps altogether, we may impact utility. We won't be
able to have things like:

	A -> B use MKT X

	A -> * use MKT Y

	* -> * use MKT Z

In this case, A->B matches all three, but having a default 'catchall'
can be very useful, if not expected.

If we allow overlap resolution, then we need to ensure that both sides
resolve to the same result.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5Dr8ACgkQE5f5cImnZrvSwQCg5ptXoi+HwGLED8kuPVNZt23I
PHYAn0xmUSP1/wo7rfrzHptIXTxwzTgk
=2uVO
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Wed Jun 17 09:11:44 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B823A6C3C for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 09:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.291
X-Spam-Level: 
X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=1.308,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOsGYR9d6kjZ for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 09:11:43 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 0FED03A6AC1 for <tcpm@ietf.org>; Wed, 17 Jun 2009 09:11:43 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 5276C50822; Wed, 17 Jun 2009 09:15:18 -0700 (PDT)
Date: Wed, 17 Jun 2009 09:15:18 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A390EC0.6070003@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090617161518.5276C50822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 16:11:44 -0000

At Wed, 17 Jun 2009 08:41:52 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Tue, 16 Jun 2009 23:24:55 -0700,
> > Joe Touch wrote:
> >> Eric Rescorla wrote:
> >> ...
> >>>> However, the invariant is twofold:
> >>>>
> >>>> 	a) for a given packet, only one MKT applies
> >>>>
> >>>> 	b) for two endpoints with multiple MKTs,
> >>>> 	the *same* MKT applies.
> >>> I don't see that this is true. As I understand the current design
> >>> there's no reason that both sides can't use different MKTs
> >>> indefinitely.
> >> Each side can use a different MKT to transmit. However, if side A uses
> >> MKT X to transmit, then side B needs to know to use MKT X to receive. If
> >> side A matches MKT X on transmit and side B matches MKT Y on receive,
> >> then there's a problem for that connection.
> >>
> >> So let's rephrase, recognizing that there are two MKTs at any given time
> >> (one for transmit on each side, and the same pair for receive on the
> >> opposite side).
> >>
> >> b) for two endpoints, if a given packet matches MKT on one side during
> >> transmit, it must match the corresponding MKT on the other side during
> >> receive.
> > 
> > Right, but this doesn't require ordering or non-overlapping, as far as
> > I can tell.  It merely requires that at any time there only be one MKT
> > corresponding to any given socketpair/key-id.
> 
> That is only possible with either non-overlapping or ordering to resolve
> overlaps.

I don't see why this is true. Any time a new key is entered, you
find all other keys that overlap with it and verify that they
have distinct key-ids. If so, the entry fails. If that's what
you mean by "prohibit overlaps", yes, I think we should
prohibit overlaps. 

If what you mean is that two MKTs with different key-ids can't overlap
the same socket pair space, I don't see a problem with that.

-Ekr


From touch@ISI.EDU  Wed Jun 17 09:20:49 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BDF13A6E94 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 09:20:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_RMML_Stock1=0.21]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9UN7UMs1iHl for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 09:20:48 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 601463A6E92 for <tcpm@ietf.org>; Wed, 17 Jun 2009 09:20:48 -0700 (PDT)
Received: from [75.215.131.214] (214.sub-75-215-131.myvzw.com [75.215.131.214]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5HGK8wu013519; Wed, 17 Jun 2009 09:20:10 -0700 (PDT)
Message-ID: <4A3917B7.20301@isi.edu>
Date: Wed, 17 Jun 2009 09:20:07 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com>
In-Reply-To: <20090617161518.5276C50822@romeo.rtfm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 16:20:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Wed, 17 Jun 2009 08:41:52 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Eric Rescorla wrote:
>>> At Tue, 16 Jun 2009 23:24:55 -0700,
>>> Joe Touch wrote:
>>>> Eric Rescorla wrote:
>>>> ...
>>>>>> However, the invariant is twofold:
>>>>>>
>>>>>> 	a) for a given packet, only one MKT applies
>>>>>>
>>>>>> 	b) for two endpoints with multiple MKTs,
>>>>>> 	the *same* MKT applies.
>>>>> I don't see that this is true. As I understand the current design
>>>>> there's no reason that both sides can't use different MKTs
>>>>> indefinitely.
>>>> Each side can use a different MKT to transmit. However, if side A uses
>>>> MKT X to transmit, then side B needs to know to use MKT X to receive. If
>>>> side A matches MKT X on transmit and side B matches MKT Y on receive,
>>>> then there's a problem for that connection.
>>>>
>>>> So let's rephrase, recognizing that there are two MKTs at any given time
>>>> (one for transmit on each side, and the same pair for receive on the
>>>> opposite side).
>>>>
>>>> b) for two endpoints, if a given packet matches MKT on one side during
>>>> transmit, it must match the corresponding MKT on the other side during
>>>> receive.
>>> Right, but this doesn't require ordering or non-overlapping, as far as
>>> I can tell.  It merely requires that at any time there only be one MKT
>>> corresponding to any given socketpair/key-id.
>> That is only possible with either non-overlapping or ordering to resolve
>> overlaps.
> 
> I don't see why this is true. Any time a new key is entered, you
> find all other keys that overlap with it and verify that they
> have distinct key-ids.

That is a very expensive operation that I am hoping we can avoid.

> If so, the entry fails. If that's what
> you mean by "prohibit overlaps", yes, I think we should
> prohibit overlaps. 
> 
> If what you mean is that two MKTs with different key-ids can't overlap
> the same socket pair space, I don't see a problem with that.

That is a problem for outgoing SYNs. For those, either the connection
has to know a-priori which ID to use, or we need to make sure MKTs can't
overlap at all (ignoring keyIDs).

The former (connection knows the ID requires apps be rewritten to select
the ID before the SYN is sent. I hope we don't expect apps to be
rewritten to use TCP-AO on their connections.

The latter (MKTs don't overlap socket pairs at all) defeats the use of
less specific MKTs as a catchall, and more specific MKTs within that.
This means more constraints than just "one packet -> one MKT", e.g., it
may require that MKTs overlap only as subsets (which is efficient to check).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5F7cACgkQE5f5cImnZrt/TwCgn2HqoZXKaIDfx0rUfczW761f
0TcAn3zednN0N6haw6lCYvgTyQpL8uXe
=EI3H
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Wed Jun 17 16:24:44 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70EEF3A69B2 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 16:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.981,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKZisf6ewnE9 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 16:24:43 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 946EB3A689D for <tcpm@ietf.org>; Wed, 17 Jun 2009 16:24:43 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1C49D50822; Wed, 17 Jun 2009 16:28:13 -0700 (PDT)
Date: Wed, 17 Jun 2009 16:28:13 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3917B7.20301@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090617232813.1C49D50822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 17 Jun 2009 23:24:44 -0000

At Wed, 17 Jun 2009 09:20:07 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Wed, 17 Jun 2009 08:41:52 -0700,
> > Joe Touch wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >>
> >> Eric Rescorla wrote:
> >>> At Tue, 16 Jun 2009 23:24:55 -0700,
> >>> Joe Touch wrote:
> >>>> Eric Rescorla wrote:
> >>>> ...
> >>>>>> However, the invariant is twofold:
> >>>>>>
> >>>>>> 	a) for a given packet, only one MKT applies
> >>>>>>
> >>>>>> 	b) for two endpoints with multiple MKTs,
> >>>>>> 	the *same* MKT applies.
> >>>>> I don't see that this is true. As I understand the current design
> >>>>> there's no reason that both sides can't use different MKTs
> >>>>> indefinitely.
> >>>> Each side can use a different MKT to transmit. However, if side A uses
> >>>> MKT X to transmit, then side B needs to know to use MKT X to receive. If
> >>>> side A matches MKT X on transmit and side B matches MKT Y on receive,
> >>>> then there's a problem for that connection.
> >>>>
> >>>> So let's rephrase, recognizing that there are two MKTs at any given time
> >>>> (one for transmit on each side, and the same pair for receive on the
> >>>> opposite side).
> >>>>
> >>>> b) for two endpoints, if a given packet matches MKT on one side during
> >>>> transmit, it must match the corresponding MKT on the other side during
> >>>> receive.
> >>> Right, but this doesn't require ordering or non-overlapping, as far as
> >>> I can tell.  It merely requires that at any time there only be one MKT
> >>> corresponding to any given socketpair/key-id.
> >> That is only possible with either non-overlapping or ordering to resolve
> >> overlaps.
> > 
> > I don't see why this is true. Any time a new key is entered, you
> > find all other keys that overlap with it and verify that they
> > have distinct key-ids.
> 
> That is a very expensive operation that I am hoping we can avoid.

It's not a very expensive operation unless you have a truly
fantastic number of keys, which can only happen if you
have an automatic key management protocol which can 
be designed not to create this situation. 


> > If so, the entry fails. If that's what
> > you mean by "prohibit overlaps", yes, I think we should
> > prohibit overlaps. 
> > 
> > If what you mean is that two MKTs with different key-ids can't overlap
> > the same socket pair space, I don't see a problem with that.
> 
> That is a problem for outgoing SYNs. For those, either the connection
> has to know a-priori which ID to use, or we need to make sure MKTs can't
> overlap at all (ignoring keyIDs).

I'm sorry, but I don't see why. 

-Ekr

From touch@ISI.EDU  Wed Jun 17 21:52:19 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EA793A6EF1 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 21:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level: 
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+1egZ6+BLU0 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 21:52:18 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 714BC3A6BC6 for <tcpm@ietf.org>; Wed, 17 Jun 2009 21:52:18 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5I4qG8Y006095; Wed, 17 Jun 2009 21:52:18 -0700 (PDT)
Message-ID: <4A39C800.2030901@isi.edu>
Date: Wed, 17 Jun 2009 21:52:16 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com>
In-Reply-To: <20090617232813.1C49D50822@romeo.rtfm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 18 Jun 2009 04:52:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



>>> If so, the entry fails. If that's what
>>> you mean by "prohibit overlaps", yes, I think we should
>>> prohibit overlaps. 
>>>
>>> If what you mean is that two MKTs with different key-ids can't overlap
>>> the same socket pair space, I don't see a problem with that.
>> That is a problem for outgoing SYNs. For those, either the connection
>> has to know a-priori which ID to use, or we need to make sure MKTs can't
>> overlap at all (ignoring keyIDs).
> 
> I'm sorry, but I don't see why. 

So let's consider outgoing SYNs.

Consider a system with two MKTs:

	MKT alpha	from ANY:ANY to JOE:80	KEYID=4

	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5


So my web client wants to connect to JOE:80. The web client has not been
modified to indicate a desired KEYID; I doubt many apps will be so
modified. So I'll need to ensure that the socket pair of the SYN matches
only one MKT.

That means I can't have default keys, like beta.

So what I'm wondering is whether we:

	a) require MKTs to be unique per {socketpair,ID} tuple

	b) require MKTs to be unique per socketpair

We either need (b), or we need something else that says "first match"
and establishes an ordering to MKTs, or "best match", etc.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5yAAACgkQE5f5cImnZrulywCcC09/JIAnd4B+yCLc3nYVct/5
/s4An2qFtyt9tIZGo+hpepDuFeUk8zyo
=JmIZ
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Wed Jun 17 22:15:46 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65FF73A6B3D for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.205
X-Spam-Level: 
X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZu+S4yGdOTa for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:15:45 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 239143A6B15 for <tcpm@ietf.org>; Wed, 17 Jun 2009 22:15:45 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 719361BDC6B; Wed, 17 Jun 2009 22:16:22 -0700 (PDT)
Date: Wed, 17 Jun 2009 22:16:22 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A39C800.2030901@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090618051622.719361BDC6B@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 18 Jun 2009 05:15:46 -0000

At Wed, 17 Jun 2009 21:52:16 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> >>> If so, the entry fails. If that's what
> >>> you mean by "prohibit overlaps", yes, I think we should
> >>> prohibit overlaps. 
> >>>
> >>> If what you mean is that two MKTs with different key-ids can't overlap
> >>> the same socket pair space, I don't see a problem with that.
> >> That is a problem for outgoing SYNs. For those, either the connection
> >> has to know a-priori which ID to use, or we need to make sure MKTs can't
> >> overlap at all (ignoring keyIDs).
> > 
> > I'm sorry, but I don't see why. 
> 
> So let's consider outgoing SYNs.
> 
> Consider a system with two MKTs:
> 
> 	MKT alpha	from ANY:ANY to JOE:80	KEYID=4
> 
> 	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5
> 
> 
> So my web client wants to connect to JOE:80. The web client has not been
> modified to indicate a desired KEYID; I doubt many apps will be so
> modified. So I'll need to ensure that the socket pair of the SYN matches
> only one MKT.
>
> That means I can't have default keys, like beta.

Why on earth would you want to do this? The misquote Dr. Strangelove,
"the whole point of a cryptographic key is lost unless you keep it
a secret. Why would you tell the world?"

Since almost every other machine on the Internet isn't going to 
have key beta, you're going to get packets that aren't protected
with AO, in which case you'll have to discard them. Configuring
your system this way is mostly useful for breaking TCP.

-Ekr


From touch@ISI.EDU  Wed Jun 17 22:19:29 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57093A6B15 for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.885
X-Spam-Level: 
X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW1OrUTmQIpz for <tcpm@core3.amsl.com>; Wed, 17 Jun 2009 22:19:29 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0D8A33A6BF1 for <tcpm@ietf.org>; Wed, 17 Jun 2009 22:19:29 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5I5JVew011272; Wed, 17 Jun 2009 22:19:32 -0700 (PDT)
Message-ID: <4A39CE62.9050201@isi.edu>
Date: Wed, 17 Jun 2009 22:19:30 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com>
In-Reply-To: <20090618051622.719361BDC6B@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 18 Jun 2009 05:19:30 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Wed, 17 Jun 2009 21:52:16 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>>>>> If so, the entry fails. If that's what
>>>>> you mean by "prohibit overlaps", yes, I think we should
>>>>> prohibit overlaps. 
>>>>>
>>>>> If what you mean is that two MKTs with different key-ids can't overlap
>>>>> the same socket pair space, I don't see a problem with that.
>>>> That is a problem for outgoing SYNs. For those, either the connection
>>>> has to know a-priori which ID to use, or we need to make sure MKTs can't
>>>> overlap at all (ignoring keyIDs).
>>> I'm sorry, but I don't see why. 
>> So let's consider outgoing SYNs.
>>
>> Consider a system with two MKTs:
>>
>> 	MKT alpha	from ANY:ANY to JOE:80	KEYID=4
>>
>> 	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5
>>
>>
>> So my web client wants to connect to JOE:80. The web client has not been
>> modified to indicate a desired KEYID; I doubt many apps will be so
>> modified. So I'll need to ensure that the socket pair of the SYN matches
>> only one MKT.
>>
>> That means I can't have default keys, like beta.
> 
> Why on earth would you want to do this? The misquote Dr. Strangelove,
> "the whole point of a cryptographic key is lost unless you keep it
> a secret. Why would you tell the world?"
> 
> Since almost every other machine on the Internet isn't going to 
> have key beta, you're going to get packets that aren't protected
> with AO, in which case you'll have to discard them. Configuring
> your system this way is mostly useful for breaking TCP

It's a bit overgeneralized above, but clamp it down a bit more and it
might still make sense, e.g.:

	alpha		from ME:ANY to JOE:BGP KEYID=6
	beta		from ME:ANY to JOE:ANY KEYID=7

I.e., I may want to lock BGP with a different key than other connections
between the two, but OK to use a single key for the rest.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko5zmIACgkQE5f5cImnZrv6RACeO6qWdPaOSbNpxHvBWHnhIPOj
NIkAn0Ls9Ejgfe0apGSGuNJ4b53XD6Bq
=ldoM
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Thu Jun 18 06:56:41 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145983A68A4 for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 06:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.232
X-Spam-Level: 
X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[AWL=-0.986,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_23=0.6,  J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5K-cZ59qOSu for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 06:56:40 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 472943A6C4C for <tcpm@ietf.org>; Thu, 18 Jun 2009 06:56:40 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 164F31BDF06; Thu, 18 Jun 2009 06:57:21 -0700 (PDT)
Date: Thu, 18 Jun 2009 06:57:20 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A39CE62.9050201@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090618135721.164F31BDF06@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 18 Jun 2009 13:56:41 -0000

At Wed, 17 Jun 2009 22:19:30 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Wed, 17 Jun 2009 21:52:16 -0700,
> > Joe Touch wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >>
> >>>>> If so, the entry fails. If that's what
> >>>>> you mean by "prohibit overlaps", yes, I think we should
> >>>>> prohibit overlaps. 
> >>>>>
> >>>>> If what you mean is that two MKTs with different key-ids can't overlap
> >>>>> the same socket pair space, I don't see a problem with that.
> >>>> That is a problem for outgoing SYNs. For those, either the connection
> >>>> has to know a-priori which ID to use, or we need to make sure MKTs can't
> >>>> overlap at all (ignoring keyIDs).
> >>> I'm sorry, but I don't see why. 
> >> So let's consider outgoing SYNs.
> >>
> >> Consider a system with two MKTs:
> >>
> >> 	MKT alpha	from ANY:ANY to JOE:80	KEYID=4
> >>
> >> 	MKT beta	from ANY:ANY to ANY:ANY	KEYID=5
> >>
> >>
> >> So my web client wants to connect to JOE:80. The web client has not been
> >> modified to indicate a desired KEYID; I doubt many apps will be so
> >> modified. So I'll need to ensure that the socket pair of the SYN matches
> >> only one MKT.
> >>
> >> That means I can't have default keys, like beta.
> > 
> > Why on earth would you want to do this? The misquote Dr. Strangelove,
> > "the whole point of a cryptographic key is lost unless you keep it
> > a secret. Why would you tell the world?"
> > 
> > Since almost every other machine on the Internet isn't going to 
> > have key beta, you're going to get packets that aren't protected
> > with AO, in which case you'll have to discard them. Configuring
> > your system this way is mostly useful for breaking TCP
> 
> It's a bit overgeneralized above, but clamp it down a bit more and it
> might still make sense, e.g.:
> 
> 	alpha		from ME:ANY to JOE:BGP KEYID=6
> 	beta		from ME:ANY to JOE:ANY KEYID=7
> 
> I.e., I may want to lock BGP with a different key than other connections
> between the two, but OK to use a single key for the rest.

Why would you want to do this?

The configuration you propose would still leave you vulnerable to
packet injection by someone who knew key alpha. 

Going up a level, I'm skeptical of this entire line of argument.
The existing rationale for this technology (BGP DoS prevention)
doesn't really justify engineering for extensively complicated
key use policies.

-Ekr


From touch@ISI.EDU  Thu Jun 18 07:10:11 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD183A6B19 for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 07:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level: 
X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebWwdQZ7Nkwz for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 07:10:10 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4FE753A6B87 for <tcpm@ietf.org>; Thu, 18 Jun 2009 07:10:10 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5IE8Tng014915; Thu, 18 Jun 2009 07:08:31 -0700 (PDT)
Message-ID: <4A3A4A5D.2060504@isi.edu>
Date: Thu, 18 Jun 2009 07:08:29 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com>
In-Reply-To: <20090618135721.164F31BDF06@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 18 Jun 2009 14:10:11 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> It's a bit overgeneralized above, but clamp it down a bit more and it
>> might still make sense, e.g.:
>>
>> 	alpha		from ME:ANY to JOE:BGP KEYID=6
>> 	beta		from ME:ANY to JOE:ANY KEYID=7
>>
>> I.e., I may want to lock BGP with a different key than other connections
>> between the two, but OK to use a single key for the rest.
> 
> Why would you want to do this?
> 
> The configuration you propose would still leave you vulnerable to
> packet injection by someone who knew key alpha.
> 
> Going up a level, I'm skeptical of this entire line of argument.
> The existing rationale for this technology (BGP DoS prevention)
> doesn't really justify engineering for extensively complicated
> key use policies.

The policy above would be used to utilize a stronger key/algorithm for
BGP, and a weaker one for other exchanges - such as would be used to
protect the transport of other protocols used in tandem with BGP, e.g.,
SNMP or DNS (each over TCP).

I agree that non-overlap is necessary to avoid injection. The trouble is
that there are different ways to avoid non-overlap which we are
currently leaving as "implementation dependent". If we leave them open,
I am concerned that KMPs will not be able to ensure that two endpoints
will pick corresponding MKTs for a given segment.

If we all want to leave that open, that's fine. IMO probably means KMP
is DOA, but that may be where this is all headed anyway.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko6Sl0ACgkQE5f5cImnZruu2gCglB4p8e0DvWh5IiZPws48drPW
8KoAnjupcaSxBBQ5g5EgwJJMS1EV5f3P
=Hhb6
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Thu Jun 18 21:32:47 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2911B3A6839 for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 21:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.403
X-Spam-Level: 
X-Spam-Status: No, score=0.403 tagged_above=-999 required=5 tests=[AWL=-0.815,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_23=0.6,  J_CHICKENPOX_33=0.6, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9rVmn54Swhm for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 21:32:46 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3E1AA3A6826 for <tcpm@ietf.org>; Thu, 18 Jun 2009 21:32:46 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 6C06E1BE12E; Thu, 18 Jun 2009 21:33:28 -0700 (PDT)
Date: Thu, 18 Jun 2009 21:33:28 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3A4A5D.2060504@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090619043328.6C06E1BE12E@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 04:32:47 -0000

At Thu, 18 Jun 2009 07:08:29 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> >> It's a bit overgeneralized above, but clamp it down a bit more and it
> >> might still make sense, e.g.:
> >>
> >> 	alpha		from ME:ANY to JOE:BGP KEYID=6
> >> 	beta		from ME:ANY to JOE:ANY KEYID=7
> >>
> >> I.e., I may want to lock BGP with a different key than other connections
> >> between the two, but OK to use a single key for the rest.
> > 
> > Why would you want to do this?
> > 
> > The configuration you propose would still leave you vulnerable to
> > packet injection by someone who knew key alpha.
> > 
> > Going up a level, I'm skeptical of this entire line of argument.
> > The existing rationale for this technology (BGP DoS prevention)
> > doesn't really justify engineering for extensively complicated
> > key use policies.
> 
> The policy above would be used to utilize a stronger key/algorithm for
> BGP, and a weaker one for other exchanges - such as would be used to
> protect the transport of other protocols used in tandem with BGP, e.g.,
> SNMP or DNS (each over TCP).

Well, remember that this technology really only makes sense as 
an anti-DoS measure. Otherwise you might as well use TLS.
So, I'm not overly concerned with the idea that people want
to use it as a generic communication protection measure for
arbitrary TCP-based protocols *and* that they want to
use this clumsy a key management scheme.


> I agree that non-overlap is necessary to avoid injection. The trouble is
> that there are different ways to avoid non-overlap which we are
> currently leaving as "implementation dependent". If we leave them open,
> I am concerned that KMPs will not be able to ensure that two endpoints
> will pick corresponding MKTs for a given segment.

Really? I would imagine this is precisely the invariant that some
putative KMP would enforce.

-Ekr

From touch@ISI.EDU  Thu Jun 18 23:39:22 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDC6E3A6B95 for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 23:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.431
X-Spam-Level: 
X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XydJjoUais05 for <tcpm@core3.amsl.com>; Thu, 18 Jun 2009 23:39:22 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 042273A6B29 for <tcpm@ietf.org>; Thu, 18 Jun 2009 23:39:21 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5J6dC7F008856; Thu, 18 Jun 2009 23:39:14 -0700 (PDT)
Message-ID: <4A3B3290.9020906@isi.edu>
Date: Thu, 18 Jun 2009 23:39:12 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com>
In-Reply-To: <20090619043328.6C06E1BE12E@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 06:39:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> I agree that non-overlap is necessary to avoid injection. The trouble is
>> that there are different ways to avoid non-overlap which we are
>> currently leaving as "implementation dependent". If we leave them open,
>> I am concerned that KMPs will not be able to ensure that two endpoints
>> will pick corresponding MKTs for a given segment.
> 
> Really? I would imagine this is precisely the invariant that some
> putative KMP would enforce.

If that's where we put that logic, what happens when we don't have a
KMP? How do we know that both ends will do the same thing with a set of
manually entered keys?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko7MpAACgkQE5f5cImnZruMoACg33VFmTOd0+AUK91FCWif5VMq
Rp0Amwfm5lvzAizSho5HFDctksmPHhf+
=BYE0
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Fri Jun 19 06:20:47 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FF93A6AA7 for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 06:20:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Level: 
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAd8rx-lZ+T7 for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 06:20:47 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2BAFF3A6A57 for <tcpm@ietf.org>; Fri, 19 Jun 2009 06:20:47 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 0DF111BE198; Fri, 19 Jun 2009 06:21:35 -0700 (PDT)
Date: Fri, 19 Jun 2009 06:21:34 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3B3290.9020906@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090619132135.0DF111BE198@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 13:20:48 -0000

At Thu, 18 Jun 2009 23:39:12 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> >> I agree that non-overlap is necessary to avoid injection. The trouble is
> >> that there are different ways to avoid non-overlap which we are
> >> currently leaving as "implementation dependent". If we leave them open,
> >> I am concerned that KMPs will not be able to ensure that two endpoints
> >> will pick corresponding MKTs for a given segment.
> > 
> > Really? I would imagine this is precisely the invariant that some
> > putative KMP would enforce.
> 
> If that's where we put that logic, what happens when we don't have a
> KMP? How do we know that both ends will do the same thing with a set of
> manually entered keys?

It was my understanding that the consensus was that we were not 
going to design a system that attempted to prevent user error.

Given that typographical errors in key entry seem far more likely
than this kind of misconfiguration, if our intent is to prevent
user error, then we should be attacking that first.

-Ekr


From touch@ISI.EDU  Fri Jun 19 08:40:19 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F4C3A6B3A for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 08:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ASgCBCSDt53 for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 08:40:19 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 23AD63A6828 for <tcpm@ietf.org>; Fri, 19 Jun 2009 08:40:19 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5JFeQod009195; Fri, 19 Jun 2009 08:40:28 -0700 (PDT)
Message-ID: <4A3BB16A.1000508@isi.edu>
Date: Fri, 19 Jun 2009 08:40:26 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu>	<20090619043328.6C06E1BE12E@kilo.networkresonance.com>	<4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com>
In-Reply-To: <20090619132135.0DF111BE198@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 15:40:20 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> If that's where we put that logic, what happens when we don't have a
>> KMP? How do we know that both ends will do the same thing with a set of
>> manually entered keys?
> 
> It was my understanding that the consensus was that we were not 
> going to design a system that attempted to prevent user error.

Oh, absolutely, agreed.

This is the kind of error where two ends install the keys correctly, but
internally the two implementations resolve overlap in different ways, so
keying fails.

> Given that typographical errors in key entry seem far more likely
> than this kind of misconfiguration, if our intent is to prevent
> user error, then we should be attacking that first.

As above, this isn't a user error issue. This is a case where leaving
something to the implementer is what is causing the problem.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko7sWoACgkQE5f5cImnZrvbdQCfUqogtjHdO21vZZcwgHqVn7Ej
YTgAnRKD1M2lEJKOu1EJtLmP22RbJgfA
=a5hQ
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Fri Jun 19 09:12:40 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AE53A6B0D for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Level: 
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=1.197,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU6V35yj3SzK for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:12:39 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 7FDCD3A6832 for <tcpm@ietf.org>; Fri, 19 Jun 2009 09:12:39 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id EFC4850822; Fri, 19 Jun 2009 09:16:14 -0700 (PDT)
Date: Fri, 19 Jun 2009 09:16:14 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3BB16A.1000508@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090619161614.EFC4850822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 16:12:40 -0000

At Fri, 19 Jun 2009 08:40:26 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> >> If that's where we put that logic, what happens when we don't have a
> >> KMP? How do we know that both ends will do the same thing with a set of
> >> manually entered keys?
> > 
> > It was my understanding that the consensus was that we were not 
> > going to design a system that attempted to prevent user error.
> 
> Oh, absolutely, agreed.
> 
> This is the kind of error where two ends install the keys correctly, but
> internally the two implementations resolve overlap in different ways, so
> keying fails.
> 
> > Given that typographical errors in key entry seem far more likely
> > than this kind of misconfiguration, if our intent is to prevent
> > user error, then we should be attacking that first.
> 
> As above, this isn't a user error issue. This is a case where leaving
> something to the implementer is what is causing the problem.

Then I don't understand what you're talking about.

The user installs two MKTs, one of which covers all ports and
one of which covers port 521 (randomly chosen). Either of these
MKTs is valid and either end can use either one to secure
the connection independently. It doesn't matter what the
prioritization schemes are on either end.

If you're saying that the installation of a more specific MKT
should not only take priority over but actually disable a
less specific MKT for that port, then I think that's a pretty
clear bug.

-Ekr


From touch@ISI.EDU  Fri Jun 19 09:26:27 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5873A6A0B for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level: 
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R8-c5mKOgQW for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:26:26 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 662863A69BB for <tcpm@ietf.org>; Fri, 19 Jun 2009 09:26:26 -0700 (PDT)
Received: from [192.168.1.46] (pool-71-105-84-152.lsanca.dsl-w.verizon.net [71.105.84.152]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5JGQMVp020371; Fri, 19 Jun 2009 09:26:24 -0700 (PDT)
Message-ID: <4A3BBC2E.9040100@isi.edu>
Date: Fri, 19 Jun 2009 09:26:22 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu>	<20090619043328.6C06E1BE12E@kilo.networkresonance.com>	<4A3B3290.9020906@isi.edu>	<20090619132135.0DF111BE198@kilo.networkresonance.com>	<4A3BB16A.1000508@isi.edu> <20090619161614.EFC4850822@romeo.rtfm.com>
In-Reply-To: <20090619161614.EFC4850822@romeo.rtfm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 16:26:28 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
> At Fri, 19 Jun 2009 08:40:26 -0700,
> Joe Touch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Eric Rescorla wrote:
>> ...
>>>> If that's where we put that logic, what happens when we don't have a
>>>> KMP? How do we know that both ends will do the same thing with a set of
>>>> manually entered keys?
>>> It was my understanding that the consensus was that we were not 
>>> going to design a system that attempted to prevent user error.
>> Oh, absolutely, agreed.
>>
>> This is the kind of error where two ends install the keys correctly, but
>> internally the two implementations resolve overlap in different ways, so
>> keying fails.
>>
>>> Given that typographical errors in key entry seem far more likely
>>> than this kind of misconfiguration, if our intent is to prevent
>>> user error, then we should be attacking that first.
>> As above, this isn't a user error issue. This is a case where leaving
>> something to the implementer is what is causing the problem.
> 
> Then I don't understand what you're talking about.
> 
> The user installs two MKTs, one of which covers all ports and
> one of which covers port 521 (randomly chosen). Either of these
> MKTs is valid and either end can use either one to secure
> the connection independently. It doesn't matter what the
> prioritization schemes are on either end.

If we just require that each segment maps to exactly one MKT, then one
end can do this by:

	- first entered, first picked

The other end can do this by:

	- longest match

So both sides are complying with "match only one MKT", but users can
easily install keys on both ends that would still not work.

> If you're saying that the installation of a more specific MKT
> should not only take priority over but actually disable a
> less specific MKT for that port, then I think that's a pretty
> clear bug.

I'm saying that the way in which we resolve overlapping MKTs matters.

a) disallow entry of overlapping MKTs

	this means that valid MKTs for a connection might not
	be able to be entered if there are more general
	keys entered

	this also incurs computation during key entry (manual
	or otherwise); is there a standard efficient alg. for
	determining overlap? Note that we could be talking about
	masks, ranges, etc.

b) allow overlapping MKTs

	this means we need to indicate the resolution mechanism
	i.e., longest match, ordered match, etc.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko7vC0ACgkQE5f5cImnZrsVWQCdEcynyPinkrPrUjI+UOxxoaD8
QLwAn2y+9mCmQ2yOO/QSC8ReglbQNx6J
=5OEU
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Fri Jun 19 09:44:06 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEC13A6812 for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level: 
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=1.088,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqBe9ayQ-+mU for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 09:44:05 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C4BC93A689B for <tcpm@ietf.org>; Fri, 19 Jun 2009 09:43:46 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2353850822; Fri, 19 Jun 2009 09:47:24 -0700 (PDT)
Date: Fri, 19 Jun 2009 09:47:24 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3BBC2E.9040100@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu> <20090619161614.EFC4850822@romeo.rtfm.com> <4A3BBC2E.9040100@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090619164724.2353850822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 16:44:06 -0000

At Fri, 19 Jun 2009 09:26:22 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> > At Fri, 19 Jun 2009 08:40:26 -0700,
> > Joe Touch wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >>
> >>
> >> Eric Rescorla wrote:
> >> ...
> >>>> If that's where we put that logic, what happens when we don't have a
> >>>> KMP? How do we know that both ends will do the same thing with a set of
> >>>> manually entered keys?
> >>> It was my understanding that the consensus was that we were not 
> >>> going to design a system that attempted to prevent user error.
> >> Oh, absolutely, agreed.
> >>
> >> This is the kind of error where two ends install the keys correctly, but
> >> internally the two implementations resolve overlap in different ways, so
> >> keying fails.
> >>
> >>> Given that typographical errors in key entry seem far more likely
> >>> than this kind of misconfiguration, if our intent is to prevent
> >>> user error, then we should be attacking that first.
> >> As above, this isn't a user error issue. This is a case where leaving
> >> something to the implementer is what is causing the problem.
> > 
> > Then I don't understand what you're talking about.
> > 
> > The user installs two MKTs, one of which covers all ports and
> > one of which covers port 521 (randomly chosen). Either of these
> > MKTs is valid and either end can use either one to secure
> > the connection independently. It doesn't matter what the
> > prioritization schemes are on either end.
> 
> If we just require that each segment maps to exactly one MKT, then one
> end can do this by:
> 
> 	- first entered, first picked
> 
> The other end can do this by:
> 
> 	- longest match
> 
> So both sides are complying with "match only one MKT", but users can
> easily install keys on both ends that would still not work.
>
> > If you're saying that the installation of a more specific MKT
> > should not only take priority over but actually disable a
> > less specific MKT for that port, then I think that's a pretty
> > clear bug.
> 
> I'm saying that the way in which we resolve overlapping MKTs matters.
> 
> a) disallow entry of overlapping MKTs
> 
> 	this means that valid MKTs for a connection might not
> 	be able to be entered if there are more general
> 	keys entered
> 
> 	this also incurs computation during key entry (manual
> 	or otherwise); is there a standard efficient alg. for
> 	determining overlap? Note that we could be talking about
> 	masks, ranges, etc.
> 
> b) allow overlapping MKTs
> 
> 	this means we need to indicate the resolution mechanism
> 	i.e., longest match, ordered match, etc.


OK, I fear we're talking past each other.

My claim is that the system must enforce the following invariant:

* There must be only one MKT defined that matches any given set
  of parameters: (s-ip, d-ip, s-port, s-port, key-id).

This includes wildcards and ranges.

Therefore there is never any ambiguity about which MKT a given
packet is associated with. The only ambiguity is which MKTs
an outgoing packet might be protected with, because of priority.
However, those MKTs will always have distinct key-ids so there
is no confusion.

I believe that that corresponds to your choice (a). However,
I don't see either of the issues you raise as problems:

- If you have a more general MKT that matches a connection,
  you can enter a new MKT that is more specific. It merely
  must have a new key-id. This is just a generalization of
  how you update keys with the same level of specificity.

- I'm not concerned about the computational cost at key 
  entry. Checking whether a new MKT has overlap with an
  existing MKT is a linear process in the number of 
  existing MKTs [*]. It's certainly not going to be a 
  problem with the number of keys you can plausibly manually
  enter. I agree that it would be nice if the KMP prevented
  this intentionally, rather than having a check at 
  installation time. 

In any case, I don't really see how we can get away from
doing this kind of checking. Let's say for the sake of
argument that we *never* allowed ranges. I.e., all 
MKTs had to be fully specified or be a wildcard. Even
then you'd need to do a table lookup to verify that
no two MKTs exactly matched each other including key-id.

-Ekr


[*] At worst. You can actually do much better using good
data structures.




    






From touch@ISI.EDU  Fri Jun 19 10:06:41 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6913A699C for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 10:06:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eOKy+YEgd39 for <tcpm@core3.amsl.com>; Fri, 19 Jun 2009 10:06:41 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id E23C13A6837 for <tcpm@ietf.org>; Fri, 19 Jun 2009 10:06:40 -0700 (PDT)
Received: from [75.213.185.135] (135.sub-75-213-185.myvzw.com [75.213.185.135]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5JH6c1e000689; Fri, 19 Jun 2009 10:06:42 -0700 (PDT)
Message-ID: <4A3BC59C.9090200@isi.edu>
Date: Fri, 19 Jun 2009 10:06:36 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu>	<20090619043328.6C06E1BE12E@kilo.networkresonance.com>	<4A3B3290.9020906@isi.edu>	<20090619132135.0DF111BE198@kilo.networkresonance.com>	<4A3BB16A.1000508@isi.edu>	<20090619161614.EFC4850822@romeo.rtfm.com>	<4A3BBC2E.9040100@isi.edu> <20090619164724.2353850822@romeo.rtfm.com>
In-Reply-To: <20090619164724.2353850822@romeo.rtfm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 19 Jun 2009 17:06:42 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
> OK, I fear we're talking past each other.
> 
> My claim is that the system must enforce the following invariant:
> 
> * There must be only one MKT defined that matches any given set
>   of parameters: (s-ip, d-ip, s-port, s-port, key-id).
> 
> This includes wildcards and ranges.

That one is a lot easier, since you're including the key-id. That's
available only for either established connections (e.g., bound to the
socket after connection establishment for outgoing, or indicated in the
segment for incoming).

For the initial outgoing SYNs from legacy applications, we need the MKT
match to be unique per:

	(s-ip, d-ip, s-port, d-port)

This is the case that's causing the problem for two cases:

a) overlapping MKT patterns, as would be used for catch-alls vs. more
specific patterns (which we could prohibit, but I would like to try not to)

b) identical MKT patterns, as would be used when a a primary and backups
are added

The TSAD/TAPD had a notion of grouping MKTs together when patterns
overlapped, so that (b) would allow selection of a 'currently designated
primary' to be used for outgoing SYNs. Getting rid of that structure -
which you claimed was an implementation issue - is omitting structure in
the key groupings that allows (b), and also enables (a).

If we omit the TSAD/TAPD, how do we express the notion that a given key
is preferred for outgoing SYNs?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko7xZsACgkQE5f5cImnZrscrQCfYfhimRCWFDvpoFXfBrjTwaK6
HiwAn1EQpeYdIPdd6f+SCXG9cUkfDfnl
=jdMC
-----END PGP SIGNATURE-----

From ekr@networkresonance.com  Sat Jun 20 08:34:57 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB403A6C49 for <tcpm@core3.amsl.com>; Sat, 20 Jun 2009 08:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.293
X-Spam-Level: 
X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKU1mJVeqy9Z for <tcpm@core3.amsl.com>; Sat, 20 Jun 2009 08:34:56 -0700 (PDT)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 12E9C3A6BA1 for <tcpm@ietf.org>; Sat, 20 Jun 2009 08:34:54 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id C20C01C0154; Sat, 20 Jun 2009 08:35:48 -0700 (PDT)
Date: Sat, 20 Jun 2009 08:35:48 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A3BC59C.9090200@isi.edu>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu> <20090619161614.EFC4850822@romeo.rtfm.com> <4A3BBC2E.9040100@isi.edu> <20090619164724.2353850822@romeo.rtfm.com> <4A3BC59C.9090200@isi.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090620153548.C20C01C0154@kilo.networkresonance.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 20 Jun 2009 15:34:57 -0000

At Fri, 19 Jun 2009 10:06:36 -0700,
Joe Touch wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Eric Rescorla wrote:
> ...
> > OK, I fear we're talking past each other.
> > 
> > My claim is that the system must enforce the following invariant:
> > 
> > * There must be only one MKT defined that matches any given set
> >   of parameters: (s-ip, d-ip, s-port, s-port, key-id).
> > 
> > This includes wildcards and ranges.
> 
> That one is a lot easier, since you're including the key-id. That's
> available only for either established connections (e.g., bound to the
> socket after connection establishment for outgoing, or indicated in the
> segment for incoming).
> 
> For the initial outgoing SYNs from legacy applications, we need the MKT
> match to be unique per:
> 
> 	(s-ip, d-ip, s-port, d-port)
> 
> This is the case that's causing the problem for two cases:

You've said that before, but I don't understand why you think it's a
problem. If there are two valid MKTs for a given packet, each side can
pick whichever one they want independently and everything will work.

The match only needs to be unique in the sense that you can't protect
a single packet with two keys. It does not need to be unique and
deterministic in the sense that each side needs to be unambiguously
determine that the *same* key applies to each packet.


> The TSAD/TAPD had a notion of grouping MKTs together when patterns
> overlapped, so that (b) would allow selection of a 'currently designated
> primary' to be used for outgoing SYNs. Getting rid of that structure -
> which you claimed was an implementation issue - is omitting structure in
> the key groupings that allows (b), and also enables (a).
> 
> If we omit the TSAD/TAPD, how do we express the notion that a given key
> is preferred for outgoing SYNs?

We don't. The implementations do it however they want (and I can think of
a number of plausible implementations) . As long as a valid key is selected,
things will work.

-Ekr

From wesley.m.eddy@nasa.gov  Mon Jun 22 09:16:03 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86BCF3A6A08 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 09:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level: 
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtJMAznIxWpu for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 09:16:02 -0700 (PDT)
Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [198.117.1.121]) by core3.amsl.com (Postfix) with ESMTP id 8CC023A6933 for <tcpm@ietf.org>; Mon, 22 Jun 2009 09:16:02 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id CF323328719; Mon, 22 Jun 2009 11:16:15 -0500 (CDT)
Received: from ndjshub02.ndc.nasa.gov (ndjshub02.ndc.nasa.gov [198.117.4.161]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5MGGFTZ022901; Mon, 22 Jun 2009 11:16:15 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub02.ndc.nasa.gov ([198.117.4.161]) with mapi; Mon, 22 Jun 2009 11:16:15 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Date: Mon, 22 Jun 2009 11:16:14 -0500
Thread-Topic: WGLC on draft-ietf-tcpm-early-rexmt-01
Thread-Index: Acm9GA415Wd77/J2SpqUcp662SX2dQW39jMgB9aoKzA=
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB69DC@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB221318FBB5@NDJSSCC01.ndc.nasa.gov> <C304DB494AC0C04C87C6A6E2FF5603DB2214AF2743@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2214AF2743@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-22_13:2009-06-01, 2009-06-22, 2009-06-22 signatures=0
Cc: Blanton <jblanton@cs.ohiou.edu>, "k.avrachenkov@sophia.inria.fr" <k.avrachenkov@sophia.inria.fr>, "Josh@core3.amsl.com" <Josh@core3.amsl.com>, "mallman@icir.org" <mallman@icir.org>
Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 16:16:03 -0000

As WG participant, here are my comments; all either editorial or
fairly minor:

(1) In the Introduction, paragraph 2, we have latex-style
    double single-quotes instead of normal double quotes

(2) "When using small congestion windows"
    should more correctly be
    "When the congestion window is small".

(3) "Small windows can occur" ->
    "Small congestion windows can occur"

(4) "Consider a congestion window (cwnd)"
    The document only uses "cwnd" in one other place, in the
    Related Work, so probably doesn't need to define an abbreviation
    for congestion window here.

(5) Need to either define SMSS in this document or cite where we
    pull the definition of the acronym from.  Section 2 possibly
    should have a sentence that says we're going to reuse the
    set of terminology from the 2581bis draft or something like
    that so we don't have to worry about explaining all the state
    variables here.

(6) "good to bad retransmits" ->
    "needed to unneeded retransmissions" ???

(7) check IDNITS :)

In general, the document is very well-written and clear in its
motivation and the description of its mechanisms.  Appendix A is
a useful addition.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>Eddy, Wesley M. (GRC-MS00)[Verizon]
>Sent: Wednesday, May 13, 2009 2:37 PM
>To: tcpm@ietf.org
>Cc: k.avrachenkov@sophia.inria.fr; Josh@core3.amsl.com;
>mallman@icir.org; Blanton
>Subject: Re: [tcpm] WGLC on draft-ietf-tcpm-early-rexmt-01
>
>TCP Maintainers & Minor Extenders: The WGLC came and went on the
>Early Retransmit draft without a single comment.  If it really is
>perfect, then someone should speak up and say so :).
>
>As the chairs, we don't have a good feeling about forwarding this
>draft up for publication without any discussion in the WG, so we
>are proposing to hold it here until at least a handful of people
>submit comments on it.
>
>Please review and provide WGLC feedback on this draft so that it
>can make progress:
>http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
>
>---------------------------
>Wes Eddy
>Network & Systems Architect
>Verizon FNS / NASA GRC
>Office: (216) 433-6682
>---------------------------
>
>
>>-----Original Message-----
>>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>>Eddy, Wesley M. (GRC-RCN0)[Verizon]
>>Sent: Tuesday, April 14, 2009 11:46 AM
>>To: tcpm@ietf.org
>>Cc: k.avrachenkov@sophia.inria.fr; Josh Blanton; mallman@icir.org
>>Subject: [tcpm] WGLC on draft-ietf
>>
>>We'd like to start a 2-week TCPM working group last call on the
>>early retransmit draft:
>>http://tools.ietf.org/html/draft-ietf-tcpm-early-rexmt-01
>>I don't think the document itself says it, but our charter has
>>this for an Experimental target.
>>
>>WGLC comments would be appreciated by April 30.
>>
>>The document has been cooking for a long time in TSVWG before
>>TCPM took it, and the authors think it's pretty mature based
>>on the progress on it there and in TCPM since it was taken
>>up by TCPM at IETF 69.
>>
>>---------------------------
>>Wes Eddy
>>Network & Systems Architect
>>Verizon FNS / NASA GRC
>>Office: (216) 433-6682
>>---------------------------
>>
>>_______________________________________________
>>tcpm mailing list
>>tcpm@ietf.org
>>https://www.ietf.org/mailman/listinfo/tcpm
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm

From wesley.m.eddy@nasa.gov  Mon Jun 22 09:50:25 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096FC3A6B6F for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 09:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.559
X-Spam-Level: 
X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssZ+M2qJThGk for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 09:50:24 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id F35063A6838 for <tcpm@ietf.org>; Mon, 22 Jun 2009 09:50:23 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 05F122602A5 for <tcpm@ietf.org>; Mon, 22 Jun 2009 11:50:38 -0500 (CDT)
Received: from ndjshub06.ndc.nasa.gov (ndjshub06.ndc.nasa.gov [198.117.4.165]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5MGocZP008297 for <tcpm@ietf.org>; Mon, 22 Jun 2009 11:50:38 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub06.ndc.nasa.gov ([198.117.4.165]) with mapi; Mon, 22 Jun 2009 11:50:38 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Date: Mon, 22 Jun 2009 11:50:38 -0500
Thread-Topic: draft IETF 75 agenda
Thread-Index: AcnzWZHPjzMY3U+7Ra6tRDuxC99KVg==
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A35@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-22_13:2009-06-01, 2009-06-22, 2009-06-22 signatures=0
Subject: [tcpm] draft IETF 75 agenda
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 16:50:25 -0000

FYI, a DRAFT agenda for IETF 75 is published:
http://www.ietf.org/meetings/75/75-Draft-Agenda.pdf

Note that TCPM is currently put on the agenda for Friday
afternoon, though this seems really undesirable, so I have
a suggestion in that we be moved to the Monday 1520-1720
slot where there are no other TSV meeting scheduled ... I
think this would be a lot better given the typical skeleton
crew left by Friday afternoons ...

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From wesley.m.eddy@nasa.gov  Mon Jun 22 10:20:39 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB693A6AE2 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 10:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.563
X-Spam-Level: 
X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.036,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zid-RwIXwufN for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 10:20:38 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 4C6493A696A for <tcpm@ietf.org>; Mon, 22 Jun 2009 10:20:38 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 6AF7B2602CB; Mon, 22 Jun 2009 12:20:53 -0500 (CDT)
Received: from ndjshub01.ndc.nasa.gov (ndjshub01.ndc.nasa.gov [198.117.4.160]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5MHKraB022269; Mon, 22 Jun 2009 12:20:53 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub01.ndc.nasa.gov ([198.117.4.160]) with mapi; Mon, 22 Jun 2009 12:20:53 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Eric Rescorla <ekr@networkresonance.com>, Joe Touch <touch@ISI.EDU>
Date: Mon, 22 Jun 2009 12:16:16 -0500
Thread-Topic: [tcpm] question about TCP-AO and rekeying
Thread-Index: AcnxvLnNxwVwXWKCRWCyH/1kGhwUhABnxf2g
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu>	<20090619161614.EFC4850822@romeo.rtfm.com> <4A3BBC2E.9040100@isi.edu>	<20090619164724.2353850822@romeo.rtfm.com> <4A3BC59C.9090200@isi.edu> <20090620153548.C20C01C0154@kilo.networkresonance.com>
In-Reply-To: <20090620153548.C20C01C0154@kilo.networkresonance.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-22_13:2009-06-01, 2009-06-22, 2009-06-22 signatures=0
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 17:20:39 -0000

Since this thread has turned into ping-pong between Joe and
Eric, I'll break that pattern by putting in my assessment as
a WG participant ...

I think Eric's explanation that if multiple MKTs can be
matched to the outgoing SYN, then we can pick from them in
an implementation-dependent way, as long as we pick one key,
makes sense.  Yes, we can add complexity to disambiguate
how that selection is made as part of our spec (TSAD/TAPD),
but after reading the thread, I don't see clear value in that.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------



From ekr@networkresonance.com  Mon Jun 22 11:05:30 2009
Return-Path: <ekr@networkresonance.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAC5B28C256 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 11:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.578
X-Spam-Level: 
X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=1.021,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80LekTB1bVt8 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 11:05:29 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D7EEC3A6B0F for <tcpm@ietf.org>; Mon, 22 Jun 2009 11:05:29 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E2F7C50822; Mon, 22 Jun 2009 11:09:09 -0700 (PDT)
Date: Mon, 22 Jun 2009 11:09:09 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
References: <4A2AB973.3030203@isi.edu> <20090616131807.75C481BC6EB@kilo.networkresonance.com> <4A37A202.9020500@isi.edu> <20090617054551.A4E0C1BCA23@kilo.networkresonance.com> <4A388C37.3030703@isi.edu> <20090617140939.A3AB61BCC72@kilo.networkresonance.com> <4A390EC0.6070003@isi.edu> <20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu> <20090617232813.1C49D50822@romeo.rtfm.com> <4A39C800.2030901@isi.edu> <20090618051622.719361BDC6B@kilo.networkresonance.com> <4A39CE62.9050201@isi.edu> <20090618135721.164F31BDF06@kilo.networkresonance.com> <4A3A4A5D.2060504@isi.edu> <20090619043328.6C06E1BE12E@kilo.networkresonance.com> <4A3B3290.9020906@isi.edu> <20090619132135.0DF111BE198@kilo.networkresonance.com> <4A3BB16A.1000508@isi.edu> <20090619161614.EFC4850822@romeo.rtfm.com> <4A3BBC2E.9040100@isi.edu> <20090619164724.2353850822@romeo.rtfm.com> <4A3BC59C.9090200@isi.edu> <20090620153548.C20C01C0154@kilo.networkresonance.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20090622180909.E2F7C50822@romeo.rtfm.com>
Cc: tcpm Extensions WG <tcpm@ietf.org>, Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 18:05:30 -0000

At Mon, 22 Jun 2009 12:16:16 -0500,
Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> 
> Since this thread has turned into ping-pong between Joe and
> Eric, I'll break that pattern by putting in my assessment as
> a WG participant ...
> 
> I think Eric's explanation that if multiple MKTs can be
> matched to the outgoing SYN, then we can pick from them in
> an implementation-dependent way, as long as we pick one key,
> makes sense.  Yes, we can add complexity to disambiguate
> how that selection is made as part of our spec (TSAD/TAPD),
> but after reading the thread, I don't see clear value in that.

I note that if we don't like this, then the problem isn't 
particular to overlap. Even if we only allowed exact matches
and prohibited overlap, we still have the question of how
to deal with two keys that have been inserted for the same
connection. For instance, say we have some connection
which is operating on key A.

Then Alice injects B and C in that order. Bob injects C and B
in that order. I thought we'd agreed that that was OK and that
we were happy to end up with a setting in which we had C in
one direction and B in the other. If not, we need some 
more sophisticated ordering rule.

-Ekr




From touch@ISI.EDU  Mon Jun 22 14:18:19 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E293A6BA1 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2SYeaBjejWq for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:18:18 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C93FC3A6C3E for <tcpm@ietf.org>; Mon, 22 Jun 2009 14:18:18 -0700 (PDT)
Received: from [70.211.98.110] (110.sub-70-211-98.myvzw.com [70.211.98.110]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5MLI0e8023526; Mon, 22 Jun 2009 14:18:02 -0700 (PDT)
Message-ID: <4A3FF507.7050909@isi.edu>
Date: Mon, 22 Jun 2009 14:17:59 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <4A2AB973.3030203@isi.edu>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com> <4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu>	<20090619043328.6C06E1BE12E@kilo.networkresonance.com>	<4A3B3290.9020906@isi.edu>	<20090619132135.0DF111BE198@kilo.networkresonance.com>	<4A3BB16A.1000508@isi.edu>	<20090619161614.EFC4850822@romeo.rtfm.com>	<4A3BBC2E.9040100@isi.edu>	<20090619164724.2353850822@romeo.rtfm.com>	<4A3BC59C.9090200@isi.edu> <20090620153548.C20C01C0154@kilo.networkresonance.com> <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217AB6A79@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 21:18:19 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> Since this thread has turned into ping-pong between Joe and
> Eric, I'll break that pattern by putting in my assessment as
> a WG participant ...
> 
> I think Eric's explanation that if multiple MKTs can be
> matched to the outgoing SYN, then we can pick from them in
> an implementation-dependent way, as long as we pick one key,
> makes sense.  Yes, we can add complexity to disambiguate
> how that selection is made as part of our spec (TSAD/TAPD),
> but after reading the thread, I don't see clear value in that.

That's fine - as per my other post that's in my outbox queue.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/9QcACgkQE5f5cImnZrur/QCeM9mbq4r+sgepKPjhs+Oy/2b2
Io0An0QLkR7WenY3SIiiwz2w89iCo5zQ
=LVEX
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Mon Jun 22 14:20:07 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3A93A6840 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS70qi6QMTOZ for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:20:07 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id EFCEC3A68B1 for <tcpm@ietf.org>; Mon, 22 Jun 2009 14:20:06 -0700 (PDT)
Received: from [70.211.98.110] (110.sub-70-211-98.myvzw.com [70.211.98.110]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5MLJtZm023870; Mon, 22 Jun 2009 14:19:57 -0700 (PDT)
Message-ID: <4A3FC670.3040704@isi.edu>
Date: Mon, 22 Jun 2009 10:59:12 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <4A2AB973.3030203@isi.edu>	<20090616131807.75C481BC6EB@kilo.networkresonance.com>	<4A37A202.9020500@isi.edu>	<20090617054551.A4E0C1BCA23@kilo.networkresonance.com>	<4A388C37.3030703@isi.edu>	<20090617140939.A3AB61BCC72@kilo.networkresonance.com>	<4A390EC0.6070003@isi.edu>	<20090617161518.5276C50822@romeo.rtfm.com>	<4A3917B7.20301@isi.edu>	<20090617232813.1C49D50822@romeo.rtfm.com>	<4A39C800.2030901@isi.edu>	<20090618051622.719361BDC6B@kilo.networkresonance.com>	<4A39CE62.9050201@isi.edu>	<20090618135721.164F31BDF06@kilo.networkresonance.com>	<4A3A4A5D.2060504@isi.edu>	<20090619043328.6C06E1BE12E@kilo.networkresonance.com>	<4A3B3290.9020906@isi.edu>	<20090619132135.0DF111BE198@kilo.networkresonance.com>	<4A3BB16A.1000508@isi.edu>	<20090619161614.EFC4850822@romeo.rtfm.com>	<4A3BBC2E.9040100@isi.edu>	<20090619164724.2353850822@romeo.rtfm.com>	<4A3BC59C.9090200@isi.edu> <20090620153548.C20C01C0154@kilo.networkresonance.com>
In-Reply-To: <20090620153548.C20C01C0154@kilo.networkresonance.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] question about TCP-AO and rekeying
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 21:20:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Eric Rescorla wrote:
...
>> If we omit the TSAD/TAPD, how do we express the notion that a given key
>> is preferred for outgoing SYNs?
> 
> We don't. The implementations do it however they want (and I can think of
> a number of plausible implementations) . As long as a valid key is selected,
> things will work.

OK. I'll update the doc based on the descriptions of this exchange shortly.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/xm8ACgkQE5f5cImnZruqvQCfUF6JmH5GfhOp/brAgMbPU+S0
wMUAn3rpO4kFYdUqiGfLVtYduJpzcWLD
=mIkG
-----END PGP SIGNATURE-----


From touch@ISI.EDU  Mon Jun 22 14:20:16 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B341E3A6B94 for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.566
X-Spam-Level: 
X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XttC6ZRFx3pT for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 14:20:15 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id DD06F3A69D4 for <tcpm@ietf.org>; Mon, 22 Jun 2009 14:20:15 -0700 (PDT)
Received: from [70.211.98.110] (110.sub-70-211-98.myvzw.com [70.211.98.110]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5MLJlE4023849; Mon, 22 Jun 2009 14:19:49 -0700 (PDT)
Message-ID: <4A3FC1C2.7060407@isi.edu>
Date: Mon, 22 Jun 2009 10:39:14 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Gorry Fairhurst <gf@erg.abdn.ac.uk>
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com> <4A30E355.1040704@erg.abdn.ac.uk>
In-Reply-To: <4A30E355.1040704@erg.abdn.ac.uk>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm-chairs@tools.ietf.org, David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 22 Jun 2009 21:20:16 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm wondering about #2. It's worth noting that implementations don't
follow the specs, but I'm getting increasingly concerned about
continuing to publish docs that say "implementations don't follow spec"
without actually either saying "and the spec is hereby changed" or "and
implementations are noncompliant and should be fixed".

While I agree that both #3 and #4 are the most important
recommendations, I propose that the WG should decide how to address whether:

	1) decide whether to update 1122 and clarify 793 (as
	standards track)
	or to reiterate 1122 and indicate existing implementations
	noncompliant

	I don't really care which of these is picked; given
	#3 and #4, it wouldn't really matter much, but I do
	feel strongly that the WG should NOT ignore this aspect.

	2) decide whether the doc is standards track (if changing
	1122) or BCP

	IMO, BCP is required based on #3 and #4 (i.e., it's not
	about whether existing impls. are incorrect, so much
	as advice on how to proceed or the future). If 1122
	is changed, then the doc needs to be standards track,
	which covers the "BCP" advice in 3 and 4 anyway.

Joe


Gorry Fairhurst wrote:
> I supported this in the meeting, and still do.
> 
> I think a statement that this not recommended for new applications (3)
> is good, combined with (4).
> 
> Best wishes,
> 
> Gorry
> 
> David Borman wrote:
>> I think I forgot to follow up on this, sorry!
>>
>> So, with my WG co-chair hat on:
>>
>> The agreement at the San Francisco IETF meeting on the Urgent Pointer
>> definition was:
>>
>> 1) Adopt this document as a WG item
>>
>> 2) Change the definition of the Urgent Pointer (defined in RFC 1122)
>> to match the definition on page 17 of RFC 793, which is what most
>> implementations use.
>>
>> 3) New applications should be discouraged from using the Urgent Pointer
>>
>> 4) TCP implementations still need to implement the Urgent Pointer for
>> existing applications that use it
>>
>> 5) All applications that do make use of the Urgent Pointer must use
>> the SO_OOBINLINE socket option to keep all of the data in sequence;
>> applications that don't use SO_OOBINLINE and continue to use the old,
>> broken BSD implementation that actually removes bytes of data from
>> data stream are out of scope for the IETF, since that is not part of
>> the TCP protocol.
>>
>> Please respond with whether you do or do not support adopting this as
>> a WG item, even if you were at the meeting, so that we have a record
>> on the mailing list.
>>
>>
>> Now with my WG chair hat off:
>>
>> I support adopting this as a WG item.
>>
>>             -David Borman, TCPM WG co-chair
>>
>>
>>
>> On May 19, 2009, at 10:01 AM, Fernando Gont wrote:
>>
>>> Hello, folks,
>>>
>>> I'm planning to work on a revision of the urgent data I-D anytime soon.
>>> I was wondering if there are any plans for proceeding with this I-D.
>>>
>>> There was some discussion on-list about TCP urgent data, and IIRC Dave
>>> Borman had suggested (hat off) that this I-D be adopted as a WG item.
>>>
>>> Thoughts? Plans?
>>>
>>> Thanks!
>>>
>>> Kind regards,
>>> -- 
>>> Fernando Gont
>>> e-mail: fernando@gont.com.ar || fgont@acm.org
>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>>
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/wcIACgkQE5f5cImnZruB6QCeNm660Aa7LTdeFknidCvslG18
xwwAnjnoDMRcW353Oi4PuVznssHshS+i
=OHXZ
-----END PGP SIGNATURE-----


From touch@ISI.EDU  Mon Jun 22 20:24:07 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 128B63A6B5C for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 20:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-m3inbXLRyh for <tcpm@core3.amsl.com>; Mon, 22 Jun 2009 20:24:06 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0042B3A69BA for <tcpm@ietf.org>; Mon, 22 Jun 2009 20:23:45 -0700 (PDT)
Received: from [75.222.253.162] (162.sub-75-222-253.myvzw.com [75.222.253.162]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5N3MrTb008163; Mon, 22 Jun 2009 20:22:55 -0700 (PDT)
Message-ID: <4A404A83.8030100@isi.edu>
Date: Mon, 22 Jun 2009 20:22:43 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando.gont.laptop.win@gmail.com>
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>	<4A30E355.1040704@erg.abdn.ac.uk> <4A3FC1C2.7060407@isi.edu> <4A4020D5.30104@gont.com.ar>
In-Reply-To: <4A4020D5.30104@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm-chairs@tools.ietf.org, David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 23 Jun 2009 03:24:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>> I'm wondering about #2. It's worth noting that implementations don't
>> follow the specs, but I'm getting increasingly concerned about
>> continuing to publish docs that say "implementations don't follow spec"
>> without actually either saying "and the spec is hereby changed" or "and
>> implementations are noncompliant and should be fixed".
> 
> Joe, you had agreed with #2 at the meeting we had in Minneapolis. What
> changed since then?
>
> P.S.: As there is no practical difference between "points to the last
> byte of urgent data" vs. "points to the byte following the last byte of
> urgent data", and since all implementations do the later, it does make
> sense to change the specs. You had agreed with this reasoning at MPLS.
> -- I'm now puzzled.

I didn't see in Gorry's note anything about saying we were changing the
specs. As I said, I don't really care whether we change the specs or
declare the implementation incorrect in general. If we've already agreed
that this will be a standards track update to 1122, that's fine (I just
didn't see it mentioned in Gorry's note).

In general, we should always *try* to take a stand when implementations
differ from the standard. This looks like a case where that's possible,
so I was just noting that we should do so.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpASoMACgkQE5f5cImnZrt3UwCgvnSomiCSCXERCtF5BavhcDEG
KIMAnRzVnyNIK6o6XmBtqRQGsfDyrX3x
=mFkN
-----END PGP SIGNATURE-----

From dab@weston.borman.com  Tue Jun 23 07:11:42 2009
Return-Path: <dab@weston.borman.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4762928C145 for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 07:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMreccnVkzVX for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 07:11:41 -0700 (PDT)
Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 536CE28C0F6 for <tcpm@ietf.org>; Tue, 23 Jun 2009 07:11:41 -0700 (PDT)
Received: from [172.25.44.12] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id n5NEBllm029093; Tue, 23 Jun 2009 09:11:49 -0500 (CDT)
Message-Id: <3A66908A-BFA3-4504-B5D7-73491CBEB6F5@weston.borman.com>
From: David Borman <dab@weston.borman.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4A404A83.8030100@isi.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 23 Jun 2009 09:11:46 -0500
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>	<4A30E355.1040704@erg.abdn.ac.uk> <4A3FC1C2.7060407@isi.edu> <4A4020D5.30104@gont.com.ar> <4A404A83.8030100@isi.edu>
X-Mailer: Apple Mail (2.935.3)
Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, Fernando Gont <fernando.gont.laptop.win@gmail.com>
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 23 Jun 2009 14:11:42 -0000

Yes, the intention is to  change the definition.  It was my note, and  
I thought that's what I said:

> 2) Change the definition of the Urgent Pointer (defined in RFC 1122)  
> to match the definition on page 17 of RFC 793, which is what most  
> implementations use.

So, no ambiguity intended, we change the spec to match the  
implementations.

			-David Borman


On Jun 22, 2009, at 10:22 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Fernando Gont wrote:
>> Joe Touch wrote:
>>
>>> I'm wondering about #2. It's worth noting that implementations don't
>>> follow the specs, but I'm getting increasingly concerned about
>>> continuing to publish docs that say "implementations don't follow  
>>> spec"
>>> without actually either saying "and the spec is hereby changed" or  
>>> "and
>>> implementations are noncompliant and should be fixed".
>>
>> Joe, you had agreed with #2 at the meeting we had in Minneapolis.  
>> What
>> changed since then?
>>
>> P.S.: As there is no practical difference between "points to the last
>> byte of urgent data" vs. "points to the byte following the last  
>> byte of
>> urgent data", and since all implementations do the later, it does  
>> make
>> sense to change the specs. You had agreed with this reasoning at  
>> MPLS.
>> -- I'm now puzzled.
>
> I didn't see in Gorry's note anything about saying we were changing  
> the
> specs. As I said, I don't really care whether we change the specs or
> declare the implementation incorrect in general. If we've already  
> agreed
> that this will be a standards track update to 1122, that's fine (I  
> just
> didn't see it mentioned in Gorry's note).
>
> In general, we should always *try* to take a stand when  
> implementations
> differ from the standard. This looks like a case where that's  
> possible,
> so I was just noting that we should do so.
>
> Joe


From fernando@gont.com.ar  Tue Jun 23 08:38:29 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3428728C2D1 for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 08:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level: 
X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=0.191,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvo8qHb1JL8D for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 08:38:28 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9F2C93A6AE4 for <tcpm@ietf.org>; Tue, 23 Jun 2009 08:38:25 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A77B16B8250 for <tcpm@ietf.org>; Tue, 23 Jun 2009 12:20:14 -0300 (ART)
Received: from [172.16.1.138] (host112.190-139-184.telecom.net.ar [190.139.184.112]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5NFJpLg012719; Tue, 23 Jun 2009 12:19:56 -0300
Message-ID: <4A40F29A.30105@gont.com.ar>
Date: Tue, 23 Jun 2009 12:19:54 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 23 Jun 2009 12:20:05 -0300 (ART)
Subject: [tcpm] [Fwd: Re: urgent data draft (draft-gont-tcpm-urgent-data-01.txt)]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 23 Jun 2009 15:38:29 -0000

FWIW, it seems this one didn't make to the tcpm list.

-------- Original Message --------
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
Date: Mon, 22 Jun 2009 23:24:53 -0100
From: Fernando Gont <fernando.gont.laptop.win@gmail.com>
To: Joe Touch <touch@ISI.EDU>
CC: Gorry Fairhurst <gf@erg.abdn.ac.uk>, tcpm-chairs@tools.ietf.org,
    David Borman <dab@weston.borman.com>, tcpm@ietf.org
References: <4A12C9C9.9060404@gont.com.ar>
<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>
<4A30E355.1040704@erg.abdn.ac.uk> <4A3FC1C2.7060407@isi.edu>

Joe Touch wrote:

> I'm wondering about #2. It's worth noting that implementations don't
> follow the specs, but I'm getting increasingly concerned about
> continuing to publish docs that say "implementations don't follow spec"
> without actually either saying "and the spec is hereby changed" or "and
> implementations are noncompliant and should be fixed".

Joe, you had agreed with #2 at the meeting we had in Minneapolis. What
changed since then?

P.S.: As there is no practical difference between "points to the last
byte of urgent data" vs. "points to the byte following the last byte of
urgent data", and since all implementations do the later, it does make
sense to change the specs. You had agreed with this reasoning at MPLS.
-- I'm now puzzled.

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando@gont.com.ar  Tue Jun 23 10:59:37 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6118B28C305 for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 10:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level: 
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgRF36BdiJ7r for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 10:59:36 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 445193A696C for <tcpm@ietf.org>; Tue, 23 Jun 2009 10:59:34 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id E201C6B6A10; Tue, 23 Jun 2009 14:59:51 -0300 (ART)
Received: from [172.16.1.138] (host112.190-139-184.telecom.net.ar [190.139.184.112]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5NHxZ3d027862; Tue, 23 Jun 2009 14:59:38 -0300
Message-ID: <4A41180C.700@gont.com.ar>
Date: Tue, 23 Jun 2009 14:59:40 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>	<4A30E355.1040704@erg.abdn.ac.uk>	<4A3FC1C2.7060407@isi.edu> <4A4020D5.30104@gont.com.ar> <4A404A83.8030100@isi.edu>
In-Reply-To: <4A404A83.8030100@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 23 Jun 2009 14:59:50 -0300 (ART)
Cc: tcpm-chairs@tools.ietf.org, David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 23 Jun 2009 17:59:37 -0000

Joe Touch wrote:

>> P.S.: As there is no practical difference between "points to the last
>> byte of urgent data" vs. "points to the byte following the last byte of
>> urgent data", and since all implementations do the later, it does make
>> sense to change the specs. You had agreed with this reasoning at MPLS.
>> -- I'm now puzzled.
> 
> I didn't see in Gorry's note anything about saying we were changing the
> specs. 

David Borman had sent a note
(http://www.ietf.org/mail-archive/web/tcpm/current/msg04548.html)
clarifying of each of the points draft-ietf-tcpm-urgent-data was making.
And that of changing the specs to match the implementations was in that
list.



> In general, we should always *try* to take a stand when implementations
> differ from the standard. This looks like a case where that's possible,
> so I was just noting that we should do so.

I'm still puzzled, Joe. In Minneapolis you had stated exactly the
contrary: that in this particular case, considering that the
implementations differ from the specs, and that there is no real
difference the UP pointing to the "last byte of urgent data" vs "the
byte following the last byte of urgent data", it did make sense to
change the specs to match the implementations.

It gets so hard to agree (or even argue) with you when you change your
opinion so frequently, and in such a radical way.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 23 19:06:05 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6143A6EFF for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 19:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3gZklHv9+56 for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 19:06:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 502163A6F07 for <tcpm@ietf.org>; Tue, 23 Jun 2009 19:06:03 -0700 (PDT)
Received: from [75.193.147.112] (112.sub-75-193-147.myvzw.com [75.193.147.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5O2523K021285; Tue, 23 Jun 2009 19:05:05 -0700 (PDT)
Message-ID: <4A4189CD.1090306@isi.edu>
Date: Tue, 23 Jun 2009 19:05:01 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>	<4A30E355.1040704@erg.abdn.ac.uk>	<4A3FC1C2.7060407@isi.edu> <4A4020D5.30104@gont.com.ar> <4A404A83.8030100@isi.edu> <4A41180C.700@gont.com.ar>
In-Reply-To: <4A41180C.700@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm-chairs@tools.ietf.org, David Borman <dab@weston.borman.com>, tcpm@ietf.org
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 24 Jun 2009 02:06:05 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fernando,

Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> P.S.: As there is no practical difference between "points to the last
>>> byte of urgent data" vs. "points to the byte following the last byte of
>>> urgent data", and since all implementations do the later, it does make
>>> sense to change the specs. You had agreed with this reasoning at MPLS.
>>> -- I'm now puzzled.
>>
>> I didn't see in Gorry's note anything about saying we were changing the
>> specs. 
> 
> David Borman had sent a note
> (http://www.ietf.org/mail-archive/web/tcpm/current/msg04548.html)
> clarifying of each of the points draft-ietf-tcpm-urgent-data was making.
> And that of changing the specs to match the implementations was in that
> list.

That email says "2) Change the definition of the Urgent Pointer (defined
in RFC 1122) to match the definition on page 17 of RFC 793, which is
what most implementations use. "

I was clarifying that this would be a standards-track change to the
specs; I didn't recall that language having been used in this discussion.

>> In general, we should always *try* to take a stand when implementations
>> differ from the standard. This looks like a case where that's possible,
>> so I was just noting that we should do so.
> 
> I'm still puzzled, Joe. In Minneapolis you had stated exactly the
> contrary: that in this particular case, considering that the
> implementations differ from the specs, and that there is no real
> difference the UP pointing to the "last byte of urgent data" vs "the
> byte following the last byte of urgent data", it did make sense to
> change the specs to match the implementations.

Implementations differing from requirements yields three options:

	a) document the difference as Informational, and nothing more

	b) document the implementation as non-compliant

	c) document the implementation as preferred as an
	update to the original requirement (standards track)

I was hoping we could engage the WG in having a discussion on these
three options in general.

> It gets so hard to agree (or even argue) with you when you change your
> opinion so frequently, and in such a radical way.

I have been - and remain - opposed to preferring an implementation to a
standard primarily on the basis of implementation. There have to be
other considerations, notably the impact to the protocol, impact to
users, etc. That means I prefer (b) in general, of the above.

In this particular case, I don't really care whether it's (b) or (c). If
I agreed to (c), it was only because I would also agree to (c).

In *general*, I think that (b) or (c) should be preferred to (a), but
also believe that most of the time that means (b). This is a case where
all known implementations differ from the standard AND where neither the
standard nor the known implementation methods have a particular benefit.
That's quite different from other cases you've brought to this WG.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpBic0ACgkQE5f5cImnZrv8LwCeN3sTndvEvMZEgerb4C68W5dq
VVcAn2N0zTdmhF1OWN8TXs9wwvGy9KGB
=8yG1
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Tue Jun 23 19:06:15 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B4B3A6F12 for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 19:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ7bJp2sON1n for <tcpm@core3.amsl.com>; Tue, 23 Jun 2009 19:06:15 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 189883A6EFF for <tcpm@ietf.org>; Tue, 23 Jun 2009 19:06:15 -0700 (PDT)
Received: from [75.193.147.112] (112.sub-75-193-147.myvzw.com [75.193.147.112]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5O25Wgl021552; Tue, 23 Jun 2009 19:05:35 -0700 (PDT)
Message-ID: <4A4189EB.9070304@isi.edu>
Date: Tue, 23 Jun 2009 19:05:31 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: David Borman <dab@weston.borman.com>
References: <4A12C9C9.9060404@gont.com.ar>	<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com>	<4A30E355.1040704@erg.abdn.ac.uk> <4A3FC1C2.7060407@isi.edu> <4A4020D5.30104@gont.com.ar> <4A404A83.8030100@isi.edu> <3A66908A-BFA3-4504-B5D7-73491CBEB6F5@weston.borman.com>
In-Reply-To: <3A66908A-BFA3-4504-B5D7-73491CBEB6F5@weston.borman.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm-chairs@tools.ietf.org, tcpm@ietf.org, Fernando Gont <fernando.gont.laptop.win@gmail.com>
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 24 Jun 2009 02:06:15 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks, that does clarify things.

Joe

David Borman wrote:
> Yes, the intention is to  change the definition.  It was my note, and I
> thought that's what I said:
> 
>> 2) Change the definition of the Urgent Pointer (defined in RFC 1122)
>> to match the definition on page 17 of RFC 793, which is what most
>> implementations use.
> 
> So, no ambiguity intended, we change the spec to match the implementations.
> 
>             -David Borman
> 
> 
> On Jun 22, 2009, at 10:22 PM, Joe Touch wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>>
>> Fernando Gont wrote:
>>> Joe Touch wrote:
>>>
>>>> I'm wondering about #2. It's worth noting that implementations don't
>>>> follow the specs, but I'm getting increasingly concerned about
>>>> continuing to publish docs that say "implementations don't follow spec"
>>>> without actually either saying "and the spec is hereby changed" or "and
>>>> implementations are noncompliant and should be fixed".
>>>
>>> Joe, you had agreed with #2 at the meeting we had in Minneapolis. What
>>> changed since then?
>>>
>>> P.S.: As there is no practical difference between "points to the last
>>> byte of urgent data" vs. "points to the byte following the last byte of
>>> urgent data", and since all implementations do the later, it does make
>>> sense to change the specs. You had agreed with this reasoning at MPLS.
>>> -- I'm now puzzled.
>>
>> I didn't see in Gorry's note anything about saying we were changing the
>> specs. As I said, I don't really care whether we change the specs or
>> declare the implementation incorrect in general. If we've already agreed
>> that this will be a standards track update to 1122, that's fine (I just
>> didn't see it mentioned in Gorry's note).
>>
>> In general, we should always *try* to take a stand when implementations
>> differ from the standard. This looks like a case where that's possible,
>> so I was just noting that we should do so.
>>
>> Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpBiesACgkQE5f5cImnZrtcWQCg08smUBFXIo1TJw1oBzdwI5Ks
BA0AnR0a10gY+RqssAo8GuFZ0axKtEvS
=wTA9
-----END PGP SIGNATURE-----

From wesley.m.eddy@nasa.gov  Wed Jun 24 12:25:27 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8C13A693D for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 12:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level: 
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCxMW-Hb9G9Y for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 12:25:25 -0700 (PDT)
Received: from ndmsnpf03.ndc.nasa.gov (ndmsnpf03.ndc.nasa.gov [198.117.0.123]) by core3.amsl.com (Postfix) with ESMTP id 746F93A67B4 for <tcpm@ietf.org>; Wed, 24 Jun 2009 12:25:25 -0700 (PDT)
Received: from ndjsppt03.ndc.nasa.gov (ndjsppt03.ndc.nasa.gov [198.117.1.102]) by ndmsnpf03.ndc.nasa.gov (Postfix) with ESMTP id A14CB2D8300 for <tcpm@ietf.org>; Wed, 24 Jun 2009 14:25:06 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt03.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5OJP6m3003502 for <tcpm@ietf.org>; Wed, 24 Jun 2009 14:25:06 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Wed, 24 Jun 2009 14:25:06 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: tcpm Extensions WG <tcpm@ietf.org>
Date: Wed, 24 Jun 2009 14:25:04 -0500
Thread-Topic: poll for adopting draft-gont-tcp-security
Thread-Index: Acn1AXnw9weJK+mlQSi8kYjj467UUA==
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-24_12:2009-06-01, 2009-06-24, 2009-06-24 signatures=0
Subject: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Wed, 24 Jun 2009 19:25:27 -0000

TCPMers, there was a thread a while ago about working on
draft-gont-tcp-security in this working group that didn't
conclusively give us a feeling one way or other:
http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html

Basically, my understanding is that there are at least a
handful of people in the WG that think it should be done
here as a WG item (more likely for Informational rather
than BCP), and there are also some expressed opinions on
why it shouldn't.

Given the raw size of the document, if the WG intends to
take this document on, then we need some people to clearly
commit to putting cycles into review and contributions to
the document.  Since it is quite large, and to my knowledge,
there hasn't been a specific technical review of the content
on this list, but just discussions about if the idea in
general is a good or bad thing, we still need to know if
people are willing to invest their time and energy in this.

Please let us know if there is traction for this in the
near term, and/or we can also discuss it in Stockholm.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------


From matt.mathis@gmail.com  Wed Jun 24 17:11:25 2009
Return-Path: <matt.mathis@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3791C3A6D99 for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 17:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfgsqnOCym6P for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 17:11:24 -0700 (PDT)
Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by core3.amsl.com (Postfix) with ESMTP id F36D03A6D96 for <tcpm@ietf.org>; Wed, 24 Jun 2009 17:11:23 -0700 (PDT)
Received: by yxe1 with SMTP id 1so1729254yxe.29 for <tcpm@ietf.org>; Wed, 24 Jun 2009 17:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fHCaSkUocJKYP8SPotEysLw43H9cvakEGgqxRXgt56I=; b=chz+I33goQ3eO9x6xyl36solBqSQ608DsQadq9cz8zs+6MhxJK4QhoeGzAf2A3eA0Y roqAPTyKrUz74KEVehkyNtEnNzqbnviKRFAxuj4mA1NeVsGSyX92VHpKKtkl0j+ZTLS8 IPrmQ+ZqXpD+0miW+wzweASVEZM2pw8MDimKA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Np1UM0gRxc1SjX8aEbYE6pXAhnC4ozIhdUte3z1T9zj6xzzwXj2Lr/qcTjySN9lOvh kjnUiRgVnR6DNXcMbGqZXG9/rlM9bZOUUgTGixabKGnUE8wzcq77cLRH587NXskD/IfD Xcg4ukTi0PPhJX5jJTzNlrHh8YXM1gUDe+hmk=
MIME-Version: 1.0
Sender: matt.mathis@gmail.com
Received: by 10.90.116.6 with SMTP id o6mr1539862agc.34.1245888687387; Wed, 24  Jun 2009 17:11:27 -0700 (PDT)
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>
Date: Wed, 24 Jun 2009 20:11:27 -0400
X-Google-Sender-Auth: ecbd8073ff1f6ff4
Message-ID: <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>
From: Matt Mathis <mathis@psc.edu>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>, tcpm Extensions WG <tcpm@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 25 Jun 2009 00:11:25 -0000

THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
that successfully killed ECN before ECN was even conceived.  The basic
point of view is that firewalls should discard all traffic bearing
features that are not explicitly permitted by todays standards.

I read all of 2 pages before I found something that, if significantly
deployed, would haunt some Internet users for a very very long time (p
43, SACK resource exhaustion).

I fear that we can not afford to do anything except go over this
document with a fine toothed comb and correct it.  Any other response
(such as trying to dismiss it) is likely to have the consequence that
is it adopted by some other standards organization, and that TCP will
become frozen forever at it's current state of brokenness.

And then all of us who think TCP might still be improved may as well
just go home and retire, because nothing that we want to try will be
permitted by standard conforming firewalls.

No I really don't want to work on this document, but I am not ready to
retire yet, so I guess I will.

Think of it a huge gray-matter tax imposed by one standards
organization on another.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.



On Wed, Jun 24, 2009 at 3:25 PM, Eddy, Wesley M.
(GRC-MS00)[Verizon]<wesley.m.eddy@nasa.gov> wrote:
> TCPMers, there was a thread a while ago about working on
> draft-gont-tcp-security in this working group that didn't
> conclusively give us a feeling one way or other:
> http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html
>
> Basically, my understanding is that there are at least a
> handful of people in the WG that think it should be done
> here as a WG item (more likely for Informational rather
> than BCP), and there are also some expressed opinions on
> why it shouldn't.
>
> Given the raw size of the document, if the WG intends to
> take this document on, then we need some people to clearly
> commit to putting cycles into review and contributions to
> the document. =A0Since it is quite large, and to my knowledge,
> there hasn't been a specific technical review of the content
> on this list, but just discussions about if the idea in
> general is a good or bad thing, we still need to know if
> people are willing to invest their time and energy in this.
>
> Please let us know if there is traction for this in the
> near term, and/or we can also discuss it in Stockholm.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>

From touch@ISI.EDU  Wed Jun 24 19:42:23 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528FB28C17B for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 19:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsdNOxecTW02 for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 19:42:22 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 6B37028C16F for <tcpm@ietf.org>; Wed, 24 Jun 2009 19:42:22 -0700 (PDT)
Received: from [75.220.132.83] (83.sub-75-220-132.myvzw.com [75.220.132.83]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5P2frx3020689; Wed, 24 Jun 2009 19:41:55 -0700 (PDT)
Message-ID: <4A42E3F1.6060002@isi.edu>
Date: Wed, 24 Jun 2009 19:41:53 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Thu, 25 Jun 2009 02:42:23 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Wes,

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
> TCPMers, there was a thread a while ago about working on
> draft-gont-tcp-security in this working group that didn't
> conclusively give us a feeling one way or other:
> http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html
> 
> Basically, my understanding is that there are at least a
> handful of people in the WG that think it should be done
> here as a WG item (more likely for Informational rather
> than BCP), and there are also some expressed opinions on
> why it shouldn't.
> 
> Given the raw size of the document, if the WG intends to
> take this document on, then we need some people to clearly
> commit to putting cycles into review and contributions to
> the document.  Since it is quite large, and to my knowledge,
> there hasn't been a specific technical review of the content
> on this list, but just discussions about if the idea in
> general is a good or bad thing, we still need to know if
> people are willing to invest their time and energy in this.

I have already provided specific technical feedback to Fernando on this
doc; I'll be glad to post them here if desired.

If the WG works on this *issue*, I would be glad to contribute cycles.
I.e., start with a blank page and put in only what the WG agrees to.

If the approach is to start with this doc and the burden of proof is on
the other contributors and the WG to take things out that we disgree
with, I fear that would be a very inefficient use of our time, and would
hesitate to participate until it had been vetted a few times by others.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpC4/EACgkQE5f5cImnZrsLJQCgkUyBxhHMRYI6o9THtYi7x9XF
C58AoNHQzqj00RPUqJl+5oF5ZmupEw9z
=sS7H
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Thu Jun 25 18:57:41 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4B63A693B for <tcpm@core3.amsl.com>; Thu, 25 Jun 2009 18:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zig5AiSj9jXp for <tcpm@core3.amsl.com>; Thu, 25 Jun 2009 18:57:39 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 4BDF63A697A for <tcpm@ietf.org>; Thu, 25 Jun 2009 18:57:38 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B277E6B6764; Thu, 25 Jun 2009 22:57:35 -0300 (ART)
Received: from [192.168.0.138] (148-82-231-201.fibertel.com.ar [201.231.82.148]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5Q1vDHm021449; Thu, 25 Jun 2009 22:57:14 -0300
Message-ID: <4A442B04.3050202@gont.com.ar>
Date: Thu, 25 Jun 2009 22:57:24 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Matt Mathis <mathis@psc.edu>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>
In-Reply-To: <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Thu, 25 Jun 2009 22:57:33 -0300 (ART)
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 26 Jun 2009 01:57:41 -0000

Hello, Matt,

I just wanted to make a few clarifications wrt the aforementioned document:

1) It wasn't written with the same mindset that killed ECN. Simple
counter-example: read the section on the "Reserved" bits, as I pointed
out on my post to the tcpm list.

2) UK CPNI is not a standards organization. It's a defense organization
from the UK (http://www.cpni.gov.uk). That of bringing the document to
the IETF was my personal idea (as I have been involved with the IETF for
the last 5 years or so), which CPNI accepted in the hopes of
contributing to the work the IETF does.

3) I have tried to get as many people review the document (or even look
at it) since a couple of years before the very first version of this
document was published. Some accepted, some didn't. e.g., I recall
asking both you and Joe about this document, but failed in my attempt.
Others agreed (as you may see in the Acknowledgements section). I think
that that means I wasn't just giving pedantic advice, and did try to get
that advice challenged.

4) The reason for bringing this document to the IETF is to further
discuss the issues that me and the reviewers have discussed. Chances are
that you may find something you don't agree with -- for instance, that's
the motivation of submitting this paper as an IETF I-D in the first
place. And it's okay and productive (I think) to further discuss any
issues anybody raises. That said, I don't think that makes it fair for
the document to be tagged as "extremely dangerous".

That said, your input would be really welcome.

Thanks!

Kind regards,
Fernando




Matt Mathis wrote:
> THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
> that successfully killed ECN before ECN was even conceived.  The basic
> point of view is that firewalls should discard all traffic bearing
> features that are not explicitly permitted by todays standards.
> 
> I read all of 2 pages before I found something that, if significantly
> deployed, would haunt some Internet users for a very very long time (p
> 43, SACK resource exhaustion).
> 
> I fear that we can not afford to do anything except go over this
> document with a fine toothed comb and correct it.  Any other response
> (such as trying to dismiss it) is likely to have the consequence that
> is it adopted by some other standards organization, and that TCP will
> become frozen forever at it's current state of brokenness.
> 
> And then all of us who think TCP might still be improved may as well
> just go home and retire, because nothing that we want to try will be
> permitted by standard conforming firewalls.
> 
> No I really don't want to work on this document, but I am not ready to
> retire yet, so I guess I will.
> 
> Think of it a huge gray-matter tax imposed by one standards
> organization on another.
> 
> Thanks,
> --MM--
> -------------------------------------------
> Matt Mathis      http://www.psc.edu/~mathis
> Work:412.268.3319   Home/Cell:412.654.7529
> -------------------------------------------
> Evil is defined by mortals who think they know
> "The Truth" and use force to apply it to others.
> 
> 
> 
> On Wed, Jun 24, 2009 at 3:25 PM, Eddy, Wesley M.
> (GRC-MS00)[Verizon]<wesley.m.eddy@nasa.gov> wrote:
>> TCPMers, there was a thread a while ago about working on
>> draft-gont-tcp-security in this working group that didn't
>> conclusively give us a feeling one way or other:
>> http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html
>>
>> Basically, my understanding is that there are at least a
>> handful of people in the WG that think it should be done
>> here as a WG item (more likely for Informational rather
>> than BCP), and there are also some expressed opinions on
>> why it shouldn't.
>>
>> Given the raw size of the document, if the WG intends to
>> take this document on, then we need some people to clearly
>> commit to putting cycles into review and contributions to
>> the document.  Since it is quite large, and to my knowledge,
>> there hasn't been a specific technical review of the content
>> on this list, but just discussions about if the idea in
>> general is a good or bad thing, we still need to know if
>> people are willing to invest their time and energy in this.
>>
>> Please let us know if there is traction for this in the
>> near term, and/or we can also discuss it in Stockholm.
>>
>> ---------------------------
>> Wes Eddy
>> Network & Systems Architect
>> Verizon FNS / NASA GRC
>> Office: (216) 433-6682
>> ---------------------------
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 

-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From rfc-editor@rfc-editor.org  Fri Jun 26 11:11:23 2009
Return-Path: <rfc-editor@rfc-editor.org>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1983A6C17; Fri, 26 Jun 2009 11:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.207
X-Spam-Level: 
X-Spam-Status: No, score=-17.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL8g+e5PKLHX; Fri, 26 Jun 2009 11:11:22 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 73A9E3A6C15; Fri, 26 Jun 2009 11:11:22 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70) id 8972A2DB42B; Fri, 26 Jun 2009 11:07:12 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20090626180712.8972A2DB42B@bosco.isi.edu>
Date: Fri, 26 Jun 2009 11:07:12 -0700 (PDT)
Cc: tcpm@ietf.org, rfc-editor@rfc-editor.org
Subject: [tcpm] RFC 5562 on Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Fri, 26 Jun 2009 18:11:23 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5562

        Title:      Adding Explicit Congestion Notification (ECN) 
                    Capability to TCP's SYN/ACK Packets 
        Author:     A. Kuzmanovic, A. Mondal,
                    S. Floyd, K. Ramakrishnan
        Status:     Experimental
        Date:       June 2009
        Mailbox:    akuzma@northwestern.edu, 
                    a-mondal@northwestern.edu, 
                    floyd@icir.org, kkrama@research.att.com
        Pages:      33
        Characters: 77110
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-tcpm-ecnsyn-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5562.txt

The proposal in this document is Experimental.  While it may be
deployed in the current Internet, it does not represent a consensus
that this is the best possible mechanism for the use of Explicit
Congestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC
3168 to allow TCP SYN/ACK packets to be ECN-Capable.  For TCP, RFC
3168 specifies setting an ECN-Capable codepoint on data packets, but
not on SYN and SYN/ACK packets.  However, because of the high cost to
the TCP transfer of having a SYN/ACK packet dropped, with the
resulting retransmission timeout, this document describes the use of
ECN for the SYN/ACK packet itself, when sent in response to a SYN
packet with the two ECN flags set in the TCP header, indicating a
willingness to use ECN.  Setting the initial TCP SYN/ACK packet as
ECN-Capable can be of great benefit to the TCP connection, avoiding
the severe penalty of a retransmission timeout for a connection that
has not yet started placing a load on the network.  The TCP responder
(the sender of the SYN/ACK packet) must reply to a report of an
ECN-marked SYN/ACK packet by resending a SYN/ACK packet that is not
ECN-Capable.  If the resent SYN/ACK packet is acknowledged, then the
TCP responder reduces its initial congestion window from two, three,
or four segments to one segment, thereby reducing the subsequent load
from that connection on the network.  If instead the SYN/ACK packet is
dropped, or for some other reason the TCP responder does not receive
an acknowledgement in the specified time, the TCP responder follows
TCP standards for a dropped SYN/ACK packet (setting the retransmission
timer).  This memo defines an Experimental Protocol for the Internet community.

This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute



From fernando.gont.laptop.win@gmail.com  Sat Jun 27 14:10:12 2009
Return-Path: <fernando.gont.laptop.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8A73A6ADC for <tcpm@core3.amsl.com>; Sat, 27 Jun 2009 14:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJTrkOv-m0V3 for <tcpm@core3.amsl.com>; Sat, 27 Jun 2009 14:10:11 -0700 (PDT)
Received: from mail-gx0-f164.google.com (mail-gx0-f164.google.com [209.85.217.164]) by core3.amsl.com (Postfix) with ESMTP id 13CB23A68CF for <tcpm@ietf.org>; Sat, 27 Jun 2009 14:10:11 -0700 (PDT)
Received: by gxk8 with SMTP id 8so147235gxk.13 for <tcpm@ietf.org>; Sat, 27 Jun 2009 14:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=j0nX8XU9K45MgvDqZOikQit8N2AfMiQtZKY9FV0PUz4=; b=m7a/z55ewKXXEbx0JCe0hT9IU2ZU4yebMezPnq3kKvsLbEPLeHzxqiEsHc2ZUEjvU7 I9gvxURJ7oR421+iAu+oNYqP0C5ljd4Pe2CfhOt+odd2hdKqnRGk1J/G1gLCgoyGDGOB WMuuDt5qJf0oWI0jZfdpZ3AFM2WG0O93WedyA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=XQEiCH4FC8FQM8Gby3MUd1HxlbbRyJWu83Y2e0JRegZVndFnEVjizobhVzXdBL5M4n umwymHDz8Z9TsLWQ3LU/qCtmthYzfkOIdUiDHKICgwFMMlmXLbvmvC6cbFXXoNolQPVc NBIvzGUfqGh+sIYbym39S/TqKgivBevbEb6xs=
Received: by 10.90.115.17 with SMTP id n17mr4510096agc.52.1246137026993; Sat, 27 Jun 2009 14:10:26 -0700 (PDT)
Received: from ?192.168.0.156? (129-130-17-190.fibertel.com.ar [190.17.130.129]) by mx.google.com with ESMTPS id 38sm3472498agd.9.2009.06.27.14.10.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 14:10:25 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.laptop.win@gmail.com>
Message-ID: <4A468AB6.3080409@gont.com.ar>
Date: Sat, 27 Jun 2009 20:10:14 -0100
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "'tcpm@ietf.org'" <tcpm@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [tcpm] [Fwd: Re: urgent data draft (draft-gont-tcpm-urgent-data-01.txt)]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 27 Jun 2009 21:12:51 -0000

FYI. It seems this one didn't make it to the list.

-------- Original Message --------
Subject: Re: [tcpm] urgent data draft (draft-gont-tcpm-urgent-data-01.txt)
Date: Wed, 24 Jun 2009 05:44:07 -0100
From: Fernando Gont <fernando@gont.com.ar>
To: Joe Touch <touch@ISI.EDU>
CC: tcpm-chairs@tools.ietf.org, David Borman <dab@weston.borman.com>, 
tcpm@ietf.org
References: <4A12C9C9.9060404@gont.com.ar> 
<FB06CDDD-8388-448B-8092-151E5533705F@weston.borman.com> 
<4A30E355.1040704@erg.abdn.ac.uk>	<4A3FC1C2.7060407@isi.edu> 
<4A4020D5.30104@gont.com.ar> <4A404A83.8030100@isi.edu> 
<4A41180C.700@gont.com.ar> <4A4189CD.1090306@isi.edu>

Joe Touch wrote:

> That email says "2) Change the definition of the Urgent Pointer (defined
> in RFC 1122) to match the definition on page 17 of RFC 793, which is
> what most implementations use. "
> 
> I was clarifying that this would be a standards-track change to the
> specs; I didn't recall that language having been used in this discussion.

The abstract of the I-D itself says:

"This document updates the relevant specifications such that
    they accommodate current practice in processing TCP urgent
    indications...."



> Implementations differing from requirements yields three options:
> 
> 	a) document the difference as Informational, and nothing more
> 
> 	b) document the implementation as non-compliant
> 
> 	c) document the implementation as preferred as an
> 	update to the original requirement (standards track)
> 
> I was hoping we could engage the WG in having a discussion on these
> three options in general.

We had already agreed to do "c". For instance, the document has been
adopted as a wg item, and is heading for std track.




>> It gets so hard to agree (or even argue) with you when you change your
>> opinion so frequently, and in such a radical way.
> 
> I have been - and remain - opposed to preferring an implementation to a
> standard primarily on the basis of implementation. There have to be
> other considerations, notably the impact to the protocol, impact to
> users, etc. That means I prefer (b) in general, of the above.

In this particular case, "c" is the safest thing to do. If you tried to
push "b" forward, you'd basically break the urgent mechanism (in those
scenarios in which it still works).



> In *general*, I think that (b) or (c) should be preferred to (a), but
> also believe that most of the time that means (b). This is a case where
> all known implementations differ from the standard AND where neither the
> standard nor the known implementation methods have a particular benefit.

Exactly. That's my point: this is an easy one... that's why I don't
understand why we don't focus on reviewing and improving the doc, so
that it doesn't take us years to ship it.

-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando.gont.laptop.win@gmail.com  Wed Jun 24 23:42:22 2009
Return-Path: <fernando.gont.laptop.win@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C486D3A6D6A for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 23:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc3hD6oaRSNy for <tcpm@core3.amsl.com>; Wed, 24 Jun 2009 23:42:21 -0700 (PDT)
Received: from mail-yx0-f129.google.com (mail-yx0-f129.google.com [209.85.210.129]) by core3.amsl.com (Postfix) with ESMTP id 9F1E43A6C0D for <tcpm@ietf.org>; Wed, 24 Jun 2009 23:42:21 -0700 (PDT)
Received: by yxe35 with SMTP id 35so113993yxe.29 for <tcpm@ietf.org>; Wed, 24 Jun 2009 23:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=B75JD/M4PFlvQVrBqCLealpmsJWXfhWz9nqBFWuRZzM=; b=xePWyRPGZVD8bSps6Gt/FnLfSt0ajd/wRXPxfhvwFDiME+SkvUQJkOW73zJjwjb1DD wJL39gLpXTVdCz8lwxlp4rfcYyaHrWhVPXrfnGHORONrCCqnAXLRLZbdMOU5e7LPAAjK Bvar6e0KmbQXPRWibs9UEVrlZB9zhAxdR1q70=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FtmJZ/6OsEYQ8nh7rpR3uOA0xW6sm+sgKigl/XifkDE0S4RYBLMpF1lj6/BIBlGQux CCFZ4cEYEhbLQLXz8CV4LGb5uJwgfpkC9NfKo1l8/I9jQkIMPpu2ijPEOjivcVExvoCK pI4le0nNzHRI7EubABYKhQYv0II4FKGEjA6PI=
Received: by 10.90.97.18 with SMTP id u18mr1812145agb.7.1245911027755; Wed, 24 Jun 2009 23:23:47 -0700 (PDT)
Received: from ?192.168.0.156? (148-82-231-201.fibertel.com.ar [201.231.82.148]) by mx.google.com with ESMTPS id 2sm3806433aga.58.2009.06.24.23.23.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 23:23:47 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.laptop.win@gmail.com>
Message-ID: <4A4317ED.1040905@gont.com.ar>
Date: Thu, 25 Jun 2009 05:23:41 -0100
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Matt Mathis <mathis@psc.edu>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>
In-Reply-To: <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Sat, 27 Jun 2009 21:13:33 -0000

Matt Mathis wrote:

> THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
> that successfully killed ECN before ECN was even conceived.  

Please read e.g., page 24 (Section 3.6.1) and let me know if this is the 
same mindset. Here's an excerpt of the aforementioned Section:

"  These four bits are reserved for future use, and must be zero.  As
    with virtually every field, the Reserved field could be used as a
    covert channel.  While there exist intermediate devices such as
    protocol scrubbers that clear these bits, and firewalls that drop/
    reject segments with any of these bits set, these devices should
    consider the impact of these policies on TCP interoperability.  For
    example, as TCP continues to evolve, all or part of the bits in the
    Reserved field could be used to implement some new functionality.  If
    some middle-box or end-system implementation were to drop a TCP
    segment merely because some of these bits are not set to zero,
    interoperability problems would arise.

    Therefore, we recommend implementations to simply ignore the Reserved
    field."



> The basic
> point of view is that firewalls should discard all traffic bearing
> features that are not explicitly permitted by todays standards.

This document provides advice for host implementations, not for firewalls.



> I read all of 2 pages before I found something that, if significantly
> deployed, would haunt some Internet users for a very very long time (p
> 43, SACK resource exhaustion).

I guess you are arguing against the proposed limit of 16 for the maximum 
number of sack holes? I understand you could argue that this value 
could/should be raised. However, IIRC I based my proposal on existing 
data on the number of holes.

FWIW, NetBSD and others already enforce limits for this. See
the "net.inet.tcp.sack.maxholes" sysctl (which defaults to 32) in
http://osdir.com/ml/netbsd.ports.x86-64/2006-05/txtdA8OHygdEK.txt

You may even be more interested in the 
"net.inet.tcp.sack.globalmaxholes", which defaults to 1024.

Other systems (e.g., FreeBSD) already enforce limits, too.

So... why instead of knocking the document down altogether, we discuss 
e.g., whether the proper limit should be something else?

I guess/hope you are not arguing against enforcing limits, but about the 
specific value proposed in the I-D. And the reason for submiting this 
I-D as a IETF I-D is exactly to discuss these issues and get consensus 
on e.g., what the proper/safe value should be for this limit.



> And then all of us who think TCP might still be improved may as well
> just go home and retire, because nothing that we want to try will be
> permitted by standard conforming firewalls.
> 
> No I really don't want to work on this document, but I am not ready to
> retire yet, so I guess I will.

Thanks.



> Think of it a huge gray-matter tax imposed by one standards
> organization on another.

I really don't understand this statement. The only standard organization 
involved in this is the IETF. UK CPNI is *NOT* a standards organization 
(please see http://www.cpni.gov.uk).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From matt.mathis@gmail.com  Mon Jun 29 10:12:38 2009
Return-Path: <matt.mathis@gmail.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068193A6B61 for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 10:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bfN4eCSo5Ow for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 10:12:36 -0700 (PDT)
Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 5FB513A68D4 for <tcpm@ietf.org>; Mon, 29 Jun 2009 10:12:36 -0700 (PDT)
Received: by ewy6 with SMTP id 6so5844306ewy.37 for <tcpm@ietf.org>; Mon, 29 Jun 2009 10:12:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=K+dH5Swac7jm1XNVTwfMX4sgXILHviRZza2HWMEtVNo=; b=TSQYMZYJtdUMVYNYfG3703u2mndtIwYikEJYih6h2w23Rzwsxe3Gx8uZM8k97ItAQD 1b4P5drbjXs0XchUy4nJBL9Dl1p2obNz4g2nJqy2kPBxYUc/rTBk+jAM17EI2HdTjj0w TWRQSzZDMjf8gBZPIs8zEEDOOba45WYYBQgw0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DFQUcg4vkAkjCVCF1TaSxIeS9Ky2KFMGRehedV3+7sbCUDk6qqP7T8HmcP0aZy8LCr Fg8mm5DWL5V7kmNtJ1P5bSYWcxwTvW7SGThLfLLMdwoso8j5ci2Gj3ueZ2iCx0HsisY0 Enue8bBdREEyefu87DLxE5lmaQFy0F39/dtjk=
Received: by 10.210.140.16 with SMTP id n16mr1809006ebd.54.1246295573578; Mon, 29 Jun 2009 10:12:53 -0700 (PDT)
Received: from mczippy.local (cpe-98-28-213-42.woh.res.rr.com [98.28.213.42]) by mx.google.com with ESMTPS id 7sm301248eyg.7.2009.06.29.10.12.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Jun 2009 10:12:52 -0700 (PDT)
Message-ID: <4A48F60A.7020602@gmail.com>
Date: Mon, 29 Jun 2009 13:12:42 -0400
From: Matt Mathis <matt.mathis@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar>
In-Reply-To: <4A4317ED.1040905@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 29 Jun 2009 17:12:38 -0000

Fernando Gont wrote:
> Matt Mathis wrote:
>
>> THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
>> that successfully killed ECN before ECN was even conceived.  
>
> Please read e.g., page 24 (Section 3.6.1) and let me know if this is 
> the same mindset. Here's an excerpt of the aforementioned Section:
>
> "  These four bits are reserved for future use, and must be zero.  As
>    with virtually every field,
--Snip--
Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
forbids ever extending SACK by adding a subtype, for example to 
negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
carried in additional bytes in the SACK-permitted option.  As far as I 
know every implementation today correctly parses the option length (e.g. 
skips forward by the relevant amount), but ignores the option data, so 
such a change would be backwards compatible with all existing 
implementations.

Even though this is not the target audience, the mere existence  of 
these  documents increases the chances that some over eager firewall 
implementer will add the check to some future pix-bis-bis, and our 
ability to extend SACK might be gone forever.

>> The basic
>> point of view is that firewalls should discard all traffic bearing
>> features that are not explicitly permitted by todays standards.
>
> This document provides advice for host implementations, not for 
> firewalls.
>
Sorry, I didn't read the introduction.   But I would not assume that 
host implementors  would be the only readers.
>
>> I read all of 2 pages before I found something that, if significantly
>> deployed, would haunt some Internet users for a very very long time (p
>> 43, SACK resource exhaustion).
>
> I guess you are arguing against the proposed limit of 16 for the 
> maximum number of sack holes? I understand you could argue that this 
> value could/should be raised. However, IIRC I based my proposal on 
> existing data on the number of holes.
>
> FWIW, NetBSD and others already enforce limits for this. See
> the "net.inet.tcp.sack.maxholes" sysctl (which defaults to 32) in
> http://osdir.com/ml/netbsd.ports.x86-64/2006-05/txtdA8OHygdEK.txt
>
> You may even be more interested in the 
> "net.inet.tcp.sack.globalmaxholes", which defaults to 1024.
>
> Other systems (e.g., FreeBSD) already enforce limits, too.
>
> So... why instead of knocking the document down altogether, we discuss 
> e.g., whether the proper limit should be something else?
>
> I guess/hope you are not arguing against enforcing limits, but about 
> the specific value proposed in the I-D. And the reason for submiting 
> this I-D as a IETF I-D is exactly to discuss these issues and get 
> consensus on e.g., what the proper/safe value should be for this limit.
The current limits are workaround for using inappropriate algorithms for 
maintaining the  SACK scoreboard.   The easy way to implement the 
scoreboard has cost O(N^2).  However there is at least one OS that uses 
an O(N*ln(N)) scoreboard, and O(N) might be possible.  (These are the 
total cost of the worst case recovery at window size N, so O(N) total 
cost is constant cost per ACK.)

If you have a moderately fast continental  scale Ethernet (1500 Byte 
MTU, 1 Gb/s, 100 ms RTT), you need a window size of 9000-18000 
packets.    Slow start typically loses ever other or every third packet, 
so you might hypothetically need to recover from 3000 to 9000 holes 
following a slow-start.    Telling host implementers that they should 
limit the number of holes rather than investing in better algorithms is 
pushing them in the wrong direction.   Kludges in existing 
implementations, or arguments about typical users are no excuse to tell 
implementers that they should not do this correctly for all users, 
including users who need the very highest performance.

Here is a hint about RFC 2018 (which probably applies to many other 
RFCs):  Every single SHOULD is a clue that we knew of something that 
might be done better than permitted by the document at hand.   Going 
through a spec and "tightening" it, by changing SHOULDs into MUSTs, is 
guaranteed to close of opportunities for improvement (although  some 
might be closed already for other reasons).

>> And then all of us who think TCP might still be improved may as well
>> just go home and retire, because nothing that we want to try will be
>> permitted by standard conforming firewalls.
>>
>> No I really don't want to work on this document, but I am not ready to
>> retire yet, so I guess I will.
>
> Thanks.
>
>
>
>> Think of it a huge gray-matter tax imposed by one standards
>> organization on another.
>
> I really don't understand this statement. The only standard 
> organization involved in this is the IETF. UK CPNI is *NOT* a 
> standards organization (please see http://www.cpni.gov.uk).
Yes, but it issued a document full of advice to implementers, that has 
the potential to have lasting negative repercussions.  If they really 
are not high profile, then there is a chance that we can get away with 
just ignoring their report.

Once I have had time to actually read the whole thing, I will comment 
further.   (I am traveling for another couple of days).

Thanks,
--MM--


From fernando@gont.com.ar  Mon Jun 29 11:14:48 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2DC3A6BDB for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.155
X-Spam-Level: 
X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.444,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLxEAvsfRSoc for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:14:47 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id B44983A6A91 for <tcpm@ietf.org>; Mon, 29 Jun 2009 11:14:45 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 3E30F6B65D7; Mon, 29 Jun 2009 15:15:08 -0300 (ART)
Received: from [192.168.0.156] (148-82-231-201.fibertel.com.ar [201.231.82.148]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5TIEmLW026697; Mon, 29 Jun 2009 15:14:53 -0300
Message-ID: <4A490492.3050407@gont.com.ar>
Date: Mon, 29 Jun 2009 17:14:42 -0100
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Matt Mathis <matt.mathis@gmail.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com>
In-Reply-To: <4A48F60A.7020602@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 29 Jun 2009 15:15:07 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 29 Jun 2009 18:14:48 -0000

Matt Mathis wrote:

>> Please read e.g., page 24 (Section 3.6.1) and let me know if this is 
>> the same mindset. Here's an excerpt of the aforementioned Section:
>>
>> "  These four bits are reserved for future use, and must be zero.  As
>>    with virtually every field,
> --Snip--
> Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
> forbids ever extending SACK by adding a subtype, for example to 
> negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
> carried in additional bytes in the SACK-permitted option.  

Are you sure this would ever work regardless of the advice we are 
giving? I could check if you want, but I bet most stacks have been 
performing this type of checks for quite some time now.

Also, why not using a different option type for that?



> As far as I 
> know every implementation today correctly parses the option length (e.g. 
> skips forward by the relevant amount), but ignores the option data, so 
> such a change would be backwards compatible with all existing 
> implementations.

I will check this and come back to you.




>>> I read all of 2 pages before I found something that, if significantly
>>> deployed, would haunt some Internet users for a very very long time (p
>>> 43, SACK resource exhaustion).
>>
>> I guess you are arguing against the proposed limit of 16 for the 
>> maximum number of sack holes? I understand you could argue that this 
>> value could/should be raised. However, IIRC I based my proposal on 
>> existing data on the number of holes.
[....]
>> I guess/hope you are not arguing against enforcing limits, but about 
>> the specific value proposed in the I-D. And the reason for submiting 
>> this I-D as a IETF I-D is exactly to discuss these issues and get 
>> consensus on e.g., what the proper/safe value should be for this limit.
> The current limits are workaround for using inappropriate algorithms for 
> maintaining the  SACK scoreboard.

It's more than that. If you don't enforce any limits, you could get a 
system to commit lots of memory for the scoreboard. Not enforcing limits 
is a highway to buffer overflows and other type of attacks. You must 
impose *some* limit.



> The easy way to implement the 
> scoreboard has cost O(N^2).  However there is at least one OS that uses 
> an O(N*ln(N)) scoreboard, and O(N) might be possible.  (These are the 
> total cost of the worst case recovery at window size N, so O(N) total 
> cost is constant cost per ACK.)

Could you provide details of the algorithms you mention, references, etc.?



> If you have a moderately fast continental  scale Ethernet (1500 Byte 
> MTU, 1 Gb/s, 100 ms RTT), you need a window size of 9000-18000 
> packets.    Slow start typically loses ever other or every third packet, 
> so you might hypothetically need to recover from 3000 to 9000 holes 
> following a slow-start.    Telling host implementers that they should 
> limit the number of holes rather than investing in better algorithms is 
> pushing them in the wrong direction.   

As I mentioned above, as a general rule to security problems, you need 
to enforce limits. We can argue about the specific value, But I don't 
think you'd want any data structure to be able to grow without bounds 
these days. You recommend this, somebody implements it, and the next day 
you have the attack tool posted on bugtraq.



> Kludges in existing 
> implementations, or arguments about typical users are no excuse to tell 
> implementers that they should not do this correctly for all users, 
> including users who need the very highest performance.

Nobody had brought up this issue of the algorithm. And, again, the 
reason for publishing the I-D was to provide the means to discuss this 
stuff within the IETF. If there's anything that can be improved, I'd be 
happy to do it.




> Here is a hint about RFC 2018 (which probably applies to many other 
> RFCs):  Every single SHOULD is a clue that we knew of something that 
> might be done better than permitted by the document at hand.   
> Going through a spec and "tightening" it, by changing SHOULDs into MUSTs, is 
> guaranteed to close of opportunities for improvement (although  some 
> might be closed already for other reasons).

In this particular case, we didn't change any SHOULD into a MUST. The 
only reference to the option length in RFC 2018 is in the option figure.



>> I really don't understand this statement. The only standard 
>> organization involved in this is the IETF. UK CPNI is *NOT* a 
>> standards organization (please see http://www.cpni.gov.uk).
> Yes, but it issued a document full of advice to implementers, that has 
> the potential to have lasting negative repercussions.  If they really 
> are not high profile, then there is a chance that we can get away with 
> just ignoring their report.

I don't really know what "high profile" is supposed to mean. The 
motivation for producing this document is explained in the 
Preface/Introduction of the document. This type of document clearly has 
an impact on implementations, because it provides help to developers 
that before this document was only available (if anything) by going 
through the 100+ papers referenced in this I-D. Many developers have 
payed attention to this document.

We have been in very close contact with the developer community of a 
number of operating systems, and the document was very welcome. It was 
felt that such a document was needed. And many of them are working on 
document.

The motivation for bringing this document to the IETF was to further 
polish the document, and give the IETF the chance to publish something 
on these issues. Even for things like "SYN floods" or "ICMP attacks", 
the IETF has provided advice/discussion at least ten or twenty years 
*later* from when many implementations had to do something about it.

There's too much stuff that an implementer of TCP has to figure out by 
himself. And many of the problems that have been found in real 
implementations have to do with that. This document simply tries to 
change that state of affairs.

Think about any TCP vulnerability that has ever been discussed in, say, 
bugtraq or full-disclosure, and I bet at least 95% have been ignored by 
the IETF (or put another way, nothing was published about them). This is 
not good.


> Once I have had time to actually read the whole thing, I will comment 
> further.   (I am traveling for another couple of days).

Thanks!

I look forward to your feedback.

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From A.Hoenes@tr-sys.de  Mon Jun 29 11:24:48 2009
Return-Path: <A.Hoenes@tr-sys.de>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490223A697B for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:24:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.994
X-Spam-Level: *
X-Spam-Status: No, score=1.994 tagged_above=-999 required=5 tests=[AWL=0.743,  BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMiahwgCBgSt for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:24:47 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 9168F3A689F for <tcpm@ietf.org>; Mon, 29 Jun 2009 11:24:46 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA274229757; Mon, 29 Jun 2009 20:22:37 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA09081; Mon, 29 Jun 2009 20:22:36 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@tr-sys.de>
Message-Id: <200906291822.UAA09081@TR-Sys.de>
To: tcpm@ietf.org
Date: Mon, 29 Jun 2009 20:22:35 +0200 (MESZ)
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 29 Jun 2009 18:24:48 -0000

TCPMers,
I strongly support adopting draft-gont-tcp-security as a work
item for TCPM, and I recommend the target being BCP.

This adoption SHOULD be accompanied by an ambitious timeline.
Experience has sadly shown that absent that, discussion is not
focussed, folks are getting tired, the discussion fades out, and
implementers and other IETF WGs start taking the draft as the
truth (as happened with other work).

Therefore, I suggest that a fix deadline for WGLC of *one year*
after adoption be set, and a forward-to-IESG deadline of another
IETF meeting, i.e. IETF 79.
That seems aggressive but reasonable, given that the draft of the
original document has been under broad discussion for already many
years.  I hope the chairs will manage to keep discussion straight
and tightly oriented towards progress with the deadlines in mind.

Additionally, the WG should take the opportunity of this assessment
to identify work items where the TCP specifications need to be
clarified / updated / revised (on the Standards Track) in the
subsequent year.
I hereby restate previous comments that the WG should eventually
take its name seriously after so many years and start effectively
*maintaining* the TCP specifications -- or it (and the IETF) will
loose even more credibility.  If we do not undertake this task
soon, many parts of the TCP specs will become irrelevant and
outdated/superseded by the predominant implementations soon.

I already have spent several weeks for reading and discussing draft
versions of the original document, and I commit more working cycles
in discussion of topics set aside in the final CPNI prepublication
steps (in order to get the document out) and other/new points of
discussion.

I hope that the discussion of the draft will be based on strong
support and cooperation of implementers, and that the chairs will
manage to keep the "gatekeepers of the holy grail" from obstructing
the process by endlessly recycling threads not leading to progress.

Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+


From ilpo.jarvinen@helsinki.fi  Mon Jun 29 11:48:29 2009
Return-Path: <ilpo.jarvinen@helsinki.fi>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A8F3A6DD2 for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.19
X-Spam-Level: 
X-Spam-Status: No, score=-5.19 tagged_above=-999 required=5 tests=[AWL=1.110,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwtz7BhCpMZ1 for <tcpm@core3.amsl.com>; Mon, 29 Jun 2009 11:48:28 -0700 (PDT)
Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4C73A6A32 for <tcpm@ietf.org>; Mon, 29 Jun 2009 11:48:27 -0700 (PDT)
Received: from svm-3.cs.helsinki.fi (melkinkari.cs.helsinki.fi [128.214.11.43]) (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 29 Jun 2009 21:48:43 +0300 id 00063E02.4A490C8B.00000935
Received: by svm-3.cs.helsinki.fi (Postfix, from userid 50795) id 83791D4A11; Mon, 29 Jun 2009 21:48:43 +0300 (EEST)
Received: from localhost (localhost [127.0.0.1]) by svm-3.cs.helsinki.fi (Postfix) with ESMTP id 7A667D5629; Mon, 29 Jun 2009 21:48:43 +0300 (EEST)
Date: Mon, 29 Jun 2009 21:48:43 +0300 (EEST)
From: "=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=" <ilpo.jarvinen@helsinki.fi>
X-X-Sender: ijjarvin@melkinkari.cs.Helsinki.FI
To: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <4A490492.3050407@gont.com.ar>
Message-ID: <Pine.LNX.4.64.0906292137340.31833@melkinkari.cs.Helsinki.FI>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A490492.3050407@gont.com.ar>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 29 Jun 2009 18:48:29 -0000

On Mon, 29 Jun 2009, Fernando Gont wrote:

> Matt Mathis wrote:
> 
> > > > I read all of 2 pages before I found something that, if significantly
> > > > deployed, would haunt some Internet users for a very very long time (p
> > > > 43, SACK resource exhaustion).
> > >
> > > I guess you are arguing against the proposed limit of 16 for the maximum
> > > number of sack holes? I understand you could argue that this value
> > > could/should be raised. However, IIRC I based my proposal on existing data
> > > on the number of holes.
> [....]
> > > I guess/hope you are not arguing against enforcing limits, but about the
> > > specific value proposed in the I-D. And the reason for submiting this I-D
> > > as a IETF I-D is exactly to discuss these issues and get consensus on
> > > e.g., what the proper/safe value should be for this limit.
> > The current limits are workaround for using inappropriate algorithms for
> > maintaining the  SACK scoreboard.
> 
> It's more than that. If you don't enforce any limits, you could get a system
> to commit lots of memory for the scoreboard. Not enforcing limits is a highway
> to buffer overflows and other type of attacks. You must impose *some* limit.

To me most sensible limit seems to be number of outstanding segments (not 
bytes) divided by two. There should be really very little reason to go 
beyond that. But of course not all implementations can directly 
determinate the number of outstanding segments (and would have to use some 
divided by MSS heurestics).

> > The easy way to implement the scoreboard has cost O(N^2).  However there is
> > at least one OS that uses an O(N*ln(N)) scoreboard, and O(N) might be
> > possible.  (These are the total cost of the worst case recovery at window
> > size N, so O(N) total cost is constant cost per ACK.)
> 
> Could you provide details of the algorithms you mention, references, etc.?

Any linked-list based implementation is basically O(n^2) under 
worst case attack, but they can also end up being that even in 
non-malicious cases too depending on the direction of lookups
and/or loss pattern.

O(n) for normal patterns seems well possible due to rather well 
predictable order of processing, obviously O(n*log n) is necessary
for malicious.

Also similar issues easily exist in the out-of-order segment handling at 
the receiver side.

-- 
 i.

From fernando@gont.com.ar  Tue Jun 30 01:19:12 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976313A6BB9 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 01:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.936,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrERCELNHjaL for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 01:19:11 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 67C193A6841 for <tcpm@ietf.org>; Tue, 30 Jun 2009 01:18:41 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 0E88E6B65AB; Tue, 30 Jun 2009 05:17:48 -0300 (ART)
Received: from [192.168.0.156] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5U8HhUU009786; Tue, 30 Jun 2009 05:17:44 -0300
Message-ID: <4A49CA1A.6060702@gont.com.ar>
Date: Tue, 30 Jun 2009 07:17:30 -0100
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Matt Mathis <matt.mathis@gmail.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com>
In-Reply-To: <4A48F60A.7020602@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 05:17:46 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 08:19:12 -0000

Hello, Matt,

> Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
> forbids ever extending SACK by adding a subtype, for example to 
> negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
> carried in additional bytes in the SACK-permitted option.  As far as I 
> know every implementation today correctly parses the option length (e.g. 
> skips forward by the relevant amount), but ignores the option data, so 
> such a change would be backwards compatible with all existing 
> implementations.

I had promised to come back to you on this one. FreeBSD ignores those 
options whose length is not equal to the expected value. Excerpt of the 
tcp_dooptions() function from netinet/tcp_input.c:

		case TCPOPT_SACK_PERMITTED:
			if (optlen != TCPOLEN_SACK_PERMITTED)
				continue;
			if (!(flags & TO_SYN))
				continue;
			if (!V_tcp_do_sack)
				continue;
			to->to_flags |= TOF_SACKPERM;
			break;

The same thing is done for all other TCP options.


Linux does exactly the same thing. Excerpt of the tcp_parse_options() 
function from net(ipv4/tcp_input.c (available online at: 
http://lxr.linux.no/linux+v2.6.30/net/ipv4/tcp_input.c#L3763):


3763                        case TCPOPT_SACK_PERM:
3764                                if (opsize == TCPOLEN_SACK_PERM && 
th->syn &&
3765                                    !estab && sysctl_tcp_sack) {
3766                                        opt_rx->sack_ok = 1;
3767                                        tcp_sack_reset(opt_rx);
3768                                }
3769                                break;


This suggests that extending SACK while still using the same option type 
is not a good idea, or at least not a backwards-compatible one. (It's 
worth noting that about 220 of the 256 available TCP option numbers are 
currently unassigned... so it doesn't look like there's a TCP 
option-number shortage problem, either)

That said, the point you raised is worth noting (i.e., that TCP 
implementations ignore options that do not match the expected option 
length), so it doesn't come as a surprise to anybody trying to extend an 
existing TCP option.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 30 08:09:37 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32FC33A6B4E for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 08:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prue6A0io9Qp for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 08:09:36 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 712DF3A680A for <tcpm@ietf.org>; Tue, 30 Jun 2009 08:09:36 -0700 (PDT)
Received: from [75.212.158.245] (245.sub-75-212-158.myvzw.com [75.212.158.245]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5UF8aVv005601; Tue, 30 Jun 2009 08:08:38 -0700 (PDT)
Message-ID: <4A4A2A73.0@isi.edu>
Date: Tue, 30 Jun 2009 08:08:35 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar> <4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar>
In-Reply-To: <4A49CA1A.6060702@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 15:09:37 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Hello, Matt,
...
> I had promised to come back to you on this one. FreeBSD ignores those
> options whose length is not equal to the expected value.
...
> Linux does exactly the same thing.
...
> This suggests that extending SACK while still using the same option type
> is not a good idea, or at least not a backwards-compatible one. 
...

It may also suggest a bug.

This is a key flaw in the approach taken in this document. A proper scan
of all aspects of TCP for security vulnerabilities would be useful, but
the doc focuses on implementations as if they provide unique or correct
insight into the issue. The state of implementations may provide a
reason to look at this issue, but do not necessarily provide the right
basis for determining how to proceed.

TCP is not secure; it was not intended to be. We cannot make it secure
simply by dropping vulnerable components. We cannot make it secure by
focusing on poor implementation choices.

If the WG is to proceed on this, there are two viable choices:

	1) a from-scratch analysis of every aspect of TCP
	for security, not just the ones implementers have
	either tripped over or misdesigned

	2) a from-scratch design of a new secure transport
	protocol (in TSVWG)

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKKnMACgkQE5f5cImnZru7JgCfdOW7mkM7H9mMb66Uhr49gZ8m
hWoAn17S1rnnG4qiRKA4zD+7z6VRqAqU
=TgqU
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Tue Jun 30 09:40:49 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EA93A6973 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 09:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LafTcpbGFLrD for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 09:40:48 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 25A563A6A9C for <tcpm@ietf.org>; Tue, 30 Jun 2009 09:40:48 -0700 (PDT)
Received: from [70.213.131.54] (54.sub-70-213-131.myvzw.com [70.213.131.54]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5UGalE2027601; Tue, 30 Jun 2009 09:36:49 -0700 (PDT)
Message-ID: <4A4A3F1F.1060904@isi.edu>
Date: Tue, 30 Jun 2009 09:36:47 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>, Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 16:40:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wes,

Taking a look at your proposed objectives:

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
...
> As a systems engineer, my first thought is always for requirements, so
> when I looked at Fernando's document, my question was if we're intending
> to do a "TCP implementation profile" for security, then what are the
> actual requirements to build to ... something like:
> 
> - TCP MUST be able to be implemented in a way free of exploitable
>   conditions leading to:
>   - unbounded memory utilization
>   - unbounded CPU utilization
>   - data injection by off-path third-parties
>   - connection breakage by off-path third-parties
>   - packet amplification by off-path third parties
>   - ...

I don't understand why TCP must be able to be implemented in a secure
fashion. It wasn't designed that way.

It would be more useful, IMO, to at least admit that and change the
above to acknowledge that, e.g., (changing the wording and the level
down to SHOULD):

- - TCP SHOULD be able to be implemented in a way that mitigates, to the
extent possible, the impact of exploitable conditions leading to:

- - Where further protection from exploitable conditions is required, a
protocol designed for security may be required; TCP is not intended to
serve this purpose, either with or without security extensions.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKPucACgkQE5f5cImnZrufVwCg/iNLT0IYw6UuwpBWKFc2dLgx
l/oAoPRYgZY8RgxzWy6gjinv8Qs8PWJO
=ZeEv
-----END PGP SIGNATURE-----

From wesley.m.eddy@nasa.gov  Tue Jun 30 10:25:57 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F50028C20F for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.567
X-Spam-Level: 
X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xehOtFHVn-re for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:25:54 -0700 (PDT)
Received: from ndmsnpf01.ndc.nasa.gov (ndmsnpf01.ndc.nasa.gov [198.117.0.121]) by core3.amsl.com (Postfix) with ESMTP id 307C73A6CD2 for <tcpm@ietf.org>; Tue, 30 Jun 2009 10:25:54 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf01.ndc.nasa.gov (Postfix) with ESMTP id BE6B0260366; Tue, 30 Jun 2009 11:20:15 -0500 (CDT)
Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5UGKEm5027990; Tue, 30 Jun 2009 11:20:15 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 30 Jun 2009 11:18:55 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Joe Touch <touch@ISI.EDU>, Fernando Gont <fernando@gont.com.ar>
Date: Tue, 30 Jun 2009 11:18:53 -0500
Thread-Topic: [tcpm] poll for adopting draft-gont-tcp-security
Thread-Index: Acn5lOSH6gGgwBlGRh+H8/0xkHVEKQAAbQmQ
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov> <fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com> <4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu>
In-Reply-To: <4A4A2A73.0@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-30_13:2009-06-25, 2009-06-30, 2009-06-30 signatures=0
Cc: Matt Mathis <mathis@psc.edu>, Matt, tcpm Extensions WG <tcpm@ietf.org>, Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 17:25:57 -0000

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>Joe Touch
>Sent: Tuesday, June 30, 2009 11:09 AM
>
> ...
>
>This is a key flaw in the approach taken in this document. A proper scan
>of all aspects of TCP for security vulnerabilities would be useful, but
>the doc focuses on implementations as if they provide unique or correct
>insight into the issue. The state of implementations may provide a
>reason to look at this issue, but do not necessarily provide the right
>basis for determining how to proceed.
>
>TCP is not secure; it was not intended to be. We cannot make it secure
>simply by dropping vulnerable components. We cannot make it secure by
>focusing on poor implementation choices.
>
>If the WG is to proceed on this, there are two viable choices:
>
>	1) a from-scratch analysis of every aspect of TCP
>	for security, not just the ones implementers have
>	either tripped over or misdesigned
>
>	2) a from-scratch design of a new secure transport
>	protocol (in TSVWG)


Since 2 is out of our scope in TCPM, we'd have to move that to discussion
on TSVWG.

Just my personal thoughts here ... not co-chairing yet ...

As for from-scratch analysis, my personal thought is that Fernando's list
of issues identified is a strong starting point, even if we don't agree
about some of the mitigations suggested.  I 100% agree with Matt and Joe's
warnings that we need to come at the mitigations from the standpoint of
reducing risks without closing off our potential to continue innovating,
extending, and keeping TCP working as a key part of the Internet.  To me,
this task resembles some of the BEHAVE working group's work, where we know
that people are doing bad things in implementation, so we have need to
write guidelines documents to tell the implementers what they should be
doing.

I think much of Fernando's analysis is quite good, at least in terms of
identifying potential areas that can be exploited.  However, I do think
it could benefit from taking another step back in order to organize and
make sure the set of issues and recommendations is complete.

As a systems engineer, my first thought is always for requirements, so
when I looked at Fernando's document, my question was if we're intending
to do a "TCP implementation profile" for security, then what are the
actual requirements to build to ... something like:

- TCP MUST be able to be implemented in a way free of exploitable
  conditions leading to:
  - unbounded memory utilization
  - unbounded CPU utilization
  - data injection by off-path third-parties
  - connection breakage by off-path third-parties
  - packet amplification by off-path third parties
  - ...

- Recommended mitigations to security issues identified in legacy TCP
  specifications MUST NOT further limit TCP properties of:
  - interoperability
  - scalability (data rates, loss rates, RTT, etc.)
  - extensibility (new options, congestion control, use of reserved
    bits, etc.)
  - ...

If we can clearly state the goals like this, then we can both organize
the issues found more logically, and we can evaluate the potential harm
of the proposed implementation techniques very systematically.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From fernando@gont.com.ar  Tue Jun 30 10:44:36 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A413A6E9C for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.175
X-Spam-Level: 
X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.424,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Ap-erKLa6p for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:44:34 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id A5E3928C42A for <tcpm@ietf.org>; Tue, 30 Jun 2009 10:44:22 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F33936B6720 for <tcpm@ietf.org>; Tue, 30 Jun 2009 14:44:21 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UHi81u026579; Tue, 30 Jun 2009 14:44:08 -0300
Message-ID: <4A4A4EEF.3040004@gont.com.ar>
Date: Tue, 30 Jun 2009 14:44:15 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 14:44:17 -0300 (ART)
Subject: [tcpm] [Fwd: Re:  poll for adopting draft-gont-tcp-security]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 17:44:36 -0000

Folks,

FYI, this is a post by NetBSD's Christos Zoulas, which is most likely
being held for moderator's approval.

Thanks,
Fernando




-------- Original Message --------
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
Date: Tue, 30 Jun 2009 12:15:08 -0400
From: christos@zoulas.com (Christos Zoulas)
Organization: Astron Software
To: tcpm@ietf.org
CC: fernando@gont.com.ar


Hello,

I just finished reading this thread, and my conclusion is that
Fernando Gonts document draft-gont-tcp-security should be adopted
as a work item for TCPM.  Any document this size is bound to have
flaws and corrections and adjustments will be necessary. I cannot
think of a more qualified group of people to work on this document,
and I think it will be time well spent.

Best Regards,

christos


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando@gont.com.ar  Tue Jun 30 10:46:05 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776493A6E9C for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.175
X-Spam-Level: 
X-Spam-Status: No, score=-3.175 tagged_above=-999 required=5 tests=[AWL=0.424,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUp6mXox1JYB for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:46:05 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 30C5C3A6E96 for <tcpm@ietf.org>; Tue, 30 Jun 2009 10:46:04 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id F16546B671A for <tcpm@ietf.org>; Tue, 30 Jun 2009 14:45:46 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UHjarY027097; Tue, 30 Jun 2009 14:45:37 -0300
Message-ID: <4A4A4F4A.4090507@gont.com.ar>
Date: Tue, 30 Jun 2009 14:45:46 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "tcpm@ietf.org" <tcpm@ietf.org>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 14:45:46 -0300 (ART)
Subject: [tcpm] [Fwd: Re:  poll for adopting draft-gont-tcp-security]
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 17:46:05 -0000

Folks,

FYI, this is a post by NetBSD's Christos Zoulas, which is most likely
being held for moderator's approval.

Thanks,
Fernando




-------- Original Message --------
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
Date: Tue, 30 Jun 2009 12:15:08 -0400
From: christos@zoulas.com (Christos Zoulas)
Organization: Astron Software
To: tcpm@ietf.org
CC: fernando@gont.com.ar


Hello,

I just finished reading this thread, and my conclusion is that
Fernando Gonts document draft-gont-tcp-security should be adopted
as a work item for TCPM.  Any document this size is bound to have
flaws and corrections and adjustments will be necessary. I cannot
think of a more qualified group of people to work on this document,
and I think it will be time well spent.

Best Regards,

christos


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando@gont.com.ar  Tue Jun 30 10:49:20 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519BD3A6CCC for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.246
X-Spam-Level: 
X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=0.353,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjn2EdQwXT-I for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 10:49:19 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 1694C3A68E5 for <tcpm@ietf.org>; Tue, 30 Jun 2009 10:49:18 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A57096B675E; Tue, 30 Jun 2009 14:49:22 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UHn6Us027900; Tue, 30 Jun 2009 14:49:07 -0300
Message-ID: <4A4A5019.1080004@gont.com.ar>
Date: Tue, 30 Jun 2009 14:49:13 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu>
In-Reply-To: <4A4A2A73.0@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 14:49:19 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 17:49:20 -0000

Joe Touch wrote:

>> This suggests that extending SACK while still using the same option type
>> is not a good idea, or at least not a backwards-compatible one.
> ...
> 
> It may also suggest a bug.

Where's the bug? The spec says the length field is e.g. 2. If you
implement the standard, and receive an option with a length field that
is different than 2, how are you supposed to process the option? If you
don't know how to process it, it seems sensible to ignore the option.



> This is a key flaw in the approach taken in this document. A proper scan
> of all aspects of TCP for security vulnerabilities would be useful, but
> the doc focuses on implementations as if they provide unique or correct
> insight into the issue. 

It doesn't focus on implementations. The advice provided in the document
is not motivated for the simple fact that there's some implementation
implementing the recommended behavior, but because it was considered the
proper thing to do.



> The state of implementations may provide a
> reason to look at this issue, but do not necessarily provide the right
> basis for determining how to proceed.

Please read the document and let me know which recommendation is
motivated by the simple fact that somebody did something in their stack.



> If the WG is to proceed on this, there are two viable choices:
> 
> 	1) a from-scratch analysis of every aspect of TCP
> 	for security, not just the ones implementers have
> 	either tripped over or misdesigned

This is exactly what the document does.


> 	2) a from-scratch design of a new secure transport
> 	protocol (in TSVWG)

It is amazing that you don't consider as a viable choice that of
adopting draft-gont-tcp-security as a wg item, and using this document
as the starting point.

It's the result of 2+ years of work, and the result of lots of my own
time and lots of time spent by the reviewers, and the developer community.

IMHO, the main issue with this document when it comes to your assessment
of the document is "NWH": Not Written Here.

This is very frustrating and sad.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1






From fernando@gont.com.ar  Tue Jun 30 11:09:34 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 456FB3A6E7E for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level: 
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[AWL=0.003,  BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDD2PrH-pXqt for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:09:33 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 718EC3A6EAF for <tcpm@ietf.org>; Tue, 30 Jun 2009 11:08:55 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id B292C6B677E; Tue, 30 Jun 2009 15:09:18 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UI95cK008343; Tue, 30 Jun 2009 15:09:07 -0300
Message-ID: <4A4A54CB.60400@gont.com.ar>
Date: Tue, 30 Jun 2009 15:09:15 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov>
In-Reply-To: <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 15:09:17 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>, Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 18:09:34 -0000

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> Just my personal thoughts here ... not co-chairing yet ...
> 
> As for from-scratch analysis, my personal thought is that Fernando's list
> of issues identified is a strong starting point, even if we don't agree
> about some of the mitigations suggested.  I 100% agree with Matt and Joe's
> warnings that we need to come at the mitigations from the standpoint of
> reducing risks without closing off our potential to continue innovating,
> extending, and keeping TCP working as a key part of the Internet.  

These considerations were made when writing the document. As stated by
other tcpm'ers, no document is meant to be perfect. If anybody catches
any recommendation that is deemed to go against this principle, we can
fix the document, and that's it.

Simply knocking down an entire effort of many people during many years
simply because some people do not agree with some of the proposed
mitigations seems simply ridiculous.



> I think much of Fernando's analysis is quite good, at least in terms of
> identifying potential areas that can be exploited.  However, I do think
> it could benefit from taking another step back in order to organize and
> make sure the set of issues and recommendations is complete.

Bringing the document to the IETF, and having the tcpm wg adopt this I-D
is taking that step back. Is assessing the entire document, and applying
changes where deemed necessary.



> As a systems engineer, my first thought is always for requirements, so
> when I looked at Fernando's document, my question was if we're intending
> to do a "TCP implementation profile" for security, then what are the
> actual requirements to build to ... something like:
> 
> - TCP MUST be able to be implemented in a way free of exploitable
>   conditions leading to:
>   - unbounded memory utilization
>   - unbounded CPU utilization
>   - data injection by off-path third-parties
>   - connection breakage by off-path third-parties
>   - packet amplification by off-path third parties
>   - ...
> 
> - Recommended mitigations to security issues identified in legacy TCP
>   specifications MUST NOT further limit TCP properties of:
>   - interoperability
>   - scalability (data rates, loss rates, RTT, etc.)
>   - extensibility (new options, congestion control, use of reserved
>     bits, etc.)
>   - ...
> 
> If we can clearly state the goals like this, then we can both organize
> the issues found more logically, and we can evaluate the potential harm
> of the proposed implementation techniques very systematically.

While not explicitly mentioned, this was the standpoint from which this
document was produced. Yes, there may be things to fix.... every
document can be improved. And by bringing this to the IETF it's implicit
that the resulting RFC would differ from the version of the document
originally published by the UK CPNI.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From fernando@gont.com.ar  Tue Jun 30 11:19:40 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D0828C3F3 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level: 
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=0.302,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm7uF7C5YAs5 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:19:39 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 9A18928C404 for <tcpm@ietf.org>; Tue, 30 Jun 2009 11:19:37 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DC5F36B6550; Tue, 30 Jun 2009 15:18:33 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UIIKim011212; Tue, 30 Jun 2009 15:18:21 -0300
Message-ID: <4A4A56F5.30806@gont.com.ar>
Date: Tue, 30 Jun 2009 15:18:29 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov> <4A4A3F1F.1060904@isi.edu>
In-Reply-To: <4A4A3F1F.1060904@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 15:18:32 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 18:19:40 -0000

Joe Touch wrote:

> I don't understand why TCP must be able to be implemented in a secure
> fashion. 

Because we don't want our systems to be trivially hacked. C'mon Joe...
Should we CC this thread to full-disclosure & bugtraq... it will
probably make the day of most of the subscribers. I really feel tempted
to do so. (I also feel tempted to CC this thread to every relevant
mailing-list of open source OSes).




> It would be more useful, IMO, to at least admit that and change the
> above to acknowledge that, e.g., (changing the wording and the level
> down to SHOULD):
> 
> - TCP SHOULD be able to be implemented in a way that mitigates, to the
> extent possible, the impact of exploitable conditions leading to:

Do we really need to nit-pick at every document and waste cycles in
end-less discussions that get nowhere, instead of getting stuff done?

Why don't we work on the document itself? Is there anything you think
could be improved? Post feedback, and let's improve the document.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From touch@ISI.EDU  Tue Jun 30 11:39:46 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE9928C210 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:39:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level: 
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENUch1So47xg for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:39:45 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B68EF3A6883 for <tcpm@ietf.org>; Tue, 30 Jun 2009 11:39:45 -0700 (PDT)
Received: from [75.217.54.49] (49.sub-75-217-54.myvzw.com [75.217.54.49]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5UIW3MN029458; Tue, 30 Jun 2009 11:32:05 -0700 (PDT)
Message-ID: <4A4A5A23.1010009@isi.edu>
Date: Tue, 30 Jun 2009 11:32:03 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar>
In-Reply-To: <4A4A56F5.30806@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 18:39:46 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>> I don't understand why TCP must be able to be implemented in a secure
>> fashion. 
> 
> Because we don't want our systems to be trivially hacked.

We agree on that.

However, there are different issues here:

	1- protecting a particular TCP connection from attack
	2- protecting an endsystem from resource overload
	3- protecting the data a user transfers

TCP was never intended for any of these. IPsec, and TCP's MD5 and AO
options are intended to address some of these. If you're concerned with
hackers, you protect all three above - which means assuming IPsec and/or
MD5/AO, *then* talking about other issues.

Addressing vulnerabilities in unprotected TCP is like caulking the
windows of a car. It won't make it float.

>> It would be more useful, IMO, to at least admit that and change the
>> above to acknowledge that, e.g., (changing the wording and the level
>> down to SHOULD):
>>
>> - TCP SHOULD be able to be implemented in a way that mitigates, to the
>> extent possible, the impact of exploitable conditions leading to:
> 
> Do we really need to nit-pick at every document and waste cycles in
> end-less discussions that get nowhere, instead of getting stuff done?
> 
> Why don't we work on the document itself? Is there anything you think
> could be improved? Post feedback, and let's improve the document.

I've repeatedly said why I don't want to proceed on this path. It puts
the WG in the position of repeating ourselves on issues we've already
decided. Specific example - ICMP in-window checking. We acknowledge
systems do this, but do NOT recommend it as a security check. I've said
why in at least 3 different IETF meetings, as have others. Yet this doc
recommends it. That exceeds advice of the WG.

If you want this doc to be the basis of work in this WG, why don't
**YOU** start by revising it to at least apply the existing WG positions
on previously discussed advice?

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKWiMACgkQE5f5cImnZrti0ACgzg5DD3SU3xMMhmYC8EbBlq/E
ob4An2c6WSG+znQ37e8yUxr2C3aYlnHP
=M0OE
-----END PGP SIGNATURE-----

From touch@ISI.EDU  Tue Jun 30 11:46:14 2009
Return-Path: <touch@ISI.EDU>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE2B3A6EA9 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQHMYoAwqFkf for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 11:46:13 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 4A0023A6E86 for <tcpm@ietf.org>; Tue, 30 Jun 2009 11:46:13 -0700 (PDT)
Received: from [75.217.54.49] (49.sub-75-217-54.myvzw.com [75.217.54.49]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n5UIiIOM002817; Tue, 30 Jun 2009 11:44:21 -0700 (PDT)
Message-ID: <4A4A5D02.2000402@isi.edu>
Date: Tue, 30 Jun 2009 11:44:18 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <4A4A5019.1080004@gont.com.ar>
In-Reply-To: <4A4A5019.1080004@gont.com.ar>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 18:46:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> This suggests that extending SACK while still using the same option type
>>> is not a good idea, or at least not a backwards-compatible one.
>> ...
>>
>> It may also suggest a bug.
> 
> Where's the bug? The spec says the length field is e.g. 2. If you
> implement the standard, and receive an option with a length field that
> is different than 2, how are you supposed to process the option? If you
> don't know how to process it, it seems sensible to ignore the option.

OK, since this is supposed to be a security doc, can you explain why you
take a segment with a mis-formed option and ignore it, even when the
length - the field that tells you where the next option starts - is
nonsensical?

Why don't you drop the segment or send a RST?

>> This is a key flaw in the approach taken in this document. A proper scan
>> of all aspects of TCP for security vulnerabilities would be useful, but
>> the doc focuses on implementations as if they provide unique or correct
>> insight into the issue. 
> 
> It doesn't focus on implementations. The advice provided in the document
> is not motivated for the simple fact that there's some implementation
> implementing the recommended behavior, but because it was considered the
> proper thing to do.

OK, so explain why ignoring segments with misformed option lengths is
"proper". Feel free to link in pointers to posted discussions that came
to that conclusion.

>> If the WG is to proceed on this, there are two viable choices:
>>
>> 	1) a from-scratch analysis of every aspect of TCP
>> 	for security, not just the ones implementers have
>> 	either tripped over or misdesigned
> 
> This is exactly what the document does.

A thorough analysis would have listed what to do with every option, not
just those deemed "commonly implemented", e.g.

It would also have caught the above bug issue, rather than deeming
current implementations to have thoughtfully considered the proper solution.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpKXQIACgkQE5f5cImnZrun2QCeLKq+tFY7bzBguLb3rVZdf1oO
zbsAn0RqKS9mEpnIfXMh95gEOwz9Pegr
=647s
-----END PGP SIGNATURE-----

From fernando@gont.com.ar  Tue Jun 30 13:02:19 2009
Return-Path: <fernando@gont.com.ar>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737C53A6EF5 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.33
X-Spam-Level: 
X-Spam-Status: No, score=-3.33 tagged_above=-999 required=5 tests=[AWL=0.269,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zXyfK3rD3pM for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:02:18 -0700 (PDT)
Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 97BCF3A6ED3 for <tcpm@ietf.org>; Tue, 30 Jun 2009 13:02:15 -0700 (PDT)
Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 90C9D6B660B; Tue, 30 Jun 2009 16:49:48 -0300 (ART)
Received: from [172.16.1.134] (host69.190-139-184.telecom.net.ar [190.139.184.69]) (authenticated bits=0) by venus.xmundo.net (8.14.1/8.14.1) with ESMTP id n5UJnWFJ031325; Tue, 30 Jun 2009 16:49:33 -0300
Message-ID: <4A4A6C53.9040008@gont.com.ar>
Date: Tue, 30 Jun 2009 16:49:39 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <C304DB494AC0C04C87C6A6E2FF5603DB2217B28763@NDJSSCC01.ndc.nasa.gov>	<fc0ff13d0906241711k44de4f77u8ec825e1ea151a1e@mail.gmail.com>	<4A4317ED.1040905@gont.com.ar>	<4A48F60A.7020602@gmail.com> <4A49CA1A.6060702@gont.com.ar> <4A4A2A73.0@isi.edu> <C304DB494AC0C04C87C6A6E2FF5603DB2217BA03DF@NDJSSCC01.ndc.nasa.gov> <4A4A3F1F.1060904@isi.edu> <4A4A56F5.30806@gont.com.ar> <4A4A5A23.1010009@isi.edu>
In-Reply-To: <4A4A5A23.1010009@isi.edu>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Tue, 30 Jun 2009 16:49:47 -0300 (ART)
Cc: Matt Mathis <mathis@psc.edu>, "tcpm-chairs@tools.ietf.org" <tcpm-chairs@tools.ietf.org>, tcpm Extensions WG <tcpm@ietf.org>, Matt Mathis <matt.mathis@gmail.com>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 20:02:19 -0000

Joe Touch wrote:

> However, there are different issues here:
> 
> 	1- protecting a particular TCP connection from attack
> 	2- protecting an endsystem from resource overload
> 	3- protecting the data a user transfers
> 
> TCP was never intended for any of these. 

TCP was not designed with congestion control in mind... so what? Will
you knock down RFC2581, too?

Whether it was designed with those issues in mind or not, doesn't
matter. TCP operates in hostile environments and therefore, to the
extent that it's possible, it's is desirable that it is as resilient as
possible.



> IPsec, and TCP's MD5 and AO options are intended to address some of these. 

>From your perspective, why would you work on TCP-AO if TCP is not meant
to provide security??



> If you're concerned with
> hackers, you protect all three above - which means assuming IPsec and/or
> MD5/AO, *then* talking about other issues.
> 
> Addressing vulnerabilities in unprotected TCP is like caulking the
> windows of a car. It won't make it float.

You use a helmet when you ride a motorcycle, right? Does that mean that
a motorcycle becomes secure? No it doesn't. But it does mean that you
probably will not get very injured if you fall from your motorcycle at
20 km/h.

C'mon Joe...




>> Why don't we work on the document itself? Is there anything you think
>> could be improved? Post feedback, and let's improve the document.
> 
> I've repeatedly said why I don't want to proceed on this path. It puts
> the WG in the position of repeating ourselves on issues we've already
> decided. Specific example - ICMP in-window checking. We acknowledge
> systems do this, but do NOT recommend it as a security check. I've said
> why in at least 3 different IETF meetings, as have others. Yet this doc
> recommends it. That exceeds advice of the WG.

I had meant to remove most of that ICMP stuff. This is a pending change,
and I thought I had already removed most of that stuff (and replace it
with a small discussion, and a pointer to the ICMP attacks I-D).



> If you want this doc to be the basis of work in this WG, why don't
> **YOU** start by revising it to at least apply the existing WG positions
> on previously discussed advice?

As I said, this is no problem, and I thought I had already applied this
change.

That said, I don't believe this is a show stopper.... (issues solved, as
far as I can tell).

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From christos@zoulas.com  Tue Jun 30 09:16:48 2009
Return-Path: <christos@zoulas.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1ECE3A6973 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 09:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCwV7k5hSYPT for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 09:16:47 -0700 (PDT)
Received: from rebar.astron.com (rebar.astron.com [38.117.134.202]) by core3.amsl.com (Postfix) with ESMTP id AC2253A6924 for <tcpm@ietf.org>; Tue, 30 Jun 2009 09:16:47 -0700 (PDT)
Received: by rebar.astron.com (Postfix, from userid 10080) id 7DA715654F; Tue, 30 Jun 2009 12:15:08 -0400 (EDT)
From: christos@zoulas.com (Christos Zoulas)
Date: Tue, 30 Jun 2009 12:15:08 -0400
Organization: Astron Software
X-Mailer: Mail User's Shell (7.2.6 beta(4.pl1)+dynamic 20000103)
To: tcpm@ietf.org
Message-Id: <20090630161508.7DA715654F@rebar.astron.com>
X-Mailman-Approved-At: Tue, 30 Jun 2009 13:34:04 -0700
Cc: fernando@gont.com.ar
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 16:16:48 -0000

Hello,

I just finished reading this thread, and my conclusion is that
Fernando Gonts document draft-gont-tcp-security should be adopted
as a work item for TCPM.  Any document this size is bound to have
flaws and corrections and adjustments will be necessary. I cannot
think of a more qualified group of people to work on this document,
and I think it will be time well spent.

Best Regards,

christos

From wesley.m.eddy@nasa.gov  Tue Jun 30 13:34:17 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3709F3A6962 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.569
X-Spam-Level: 
X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqiFxuManQrY for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 13:34:16 -0700 (PDT)
Received: from ndmsnpf02.ndc.nasa.gov (ndmsnpf02.ndc.nasa.gov [198.117.0.122]) by core3.amsl.com (Postfix) with ESMTP id CB1A63A69F2 for <tcpm@ietf.org>; Tue, 30 Jun 2009 13:33:54 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndmsnpf02.ndc.nasa.gov (Postfix) with ESMTP id 0DA377BA34 for <tcpm@ietf.org>; Tue, 30 Jun 2009 15:33:28 -0500 (CDT)
Received: from ndjshub04.ndc.nasa.gov (ndjshub04.ndc.nasa.gov [198.117.4.163]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5UKXRBg003798 for <tcpm@ietf.org>; Tue, 30 Jun 2009 15:33:27 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub04.ndc.nasa.gov ([198.117.4.163]) with mapi; Tue, 30 Jun 2009 15:33:27 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: tcpm Extensions WG <tcpm@ietf.org>
Date: Tue, 30 Jun 2009 15:33:26 -0500
Thread-Topic: Wes - in re: The GONT  draft on TCP Security should be advanced -I Agree
Thread-Index: Acn5mc9Zfv+jkNgdRZaUo0QVyhcKBQAKCB1g
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217BA0635@NDJSSCC01.ndc.nasa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-30_16:2009-06-25, 2009-06-30, 2009-06-30 signatures=0
Subject: [tcpm] FW: Wes - in re: The GONT draft on TCP Security should be advanced -I Agree
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 20:34:17 -0000

FYI - I received this off-list, but with the request to forward
it to TCPM ...

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: Todd Glassey CISM CIFI [mailto:tglassey@earthlink.net]
>Sent: Tuesday, June 30, 2009 11:45 AM
>To: weddy@grc.nasa.gov; david.borman@windriver.com
>Subject: Wes - in re: The GONT draft on TCP Security should be advanced
>-I Agree
>
>Wes/David
>
>http://www.ietf.org/mail-archive/web/tcpm/current/msg04641.html
>
>the TCP Security Draft is very important and will come to fill a unique
>niche requirement for creating an anchoring document to leverage
>controls against in the Audit Community and InfoSec auditor's world and
>as such this document has the potential to become a mainstay of the
>Audit world as well by referring to the expertise of the IETF in its
>review and assessment of TCP itself.
>
>Additionally one needs to be done specifically for UDP and the protocols
>which rely on it, but that's another issue all together.
>
>How I would approach this it to split the project into pieces (vertical
>silos) and have each silo create a set of deliverables. Because of the
>size of this project I would take it on with the following proviso -
>that being that if the project stalls it will be shelved and taken off
>the WG's  agenda.
>
>What I think is that there are parts of the standard-analysis which are
>important to varying communities and they will rally to provide those
>engineering resources to the WG to accomplish the vetting necessary to
>advance this effort.
>
>Todd Glassey, General Troublemaker


From wesley.m.eddy@nasa.gov  Tue Jun 30 14:04:43 2009
Return-Path: <wesley.m.eddy@nasa.gov>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68A93A6842 for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 14:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coNvGDelXqci for <tcpm@core3.amsl.com>; Tue, 30 Jun 2009 14:04:42 -0700 (PDT)
Received: from ndjsnpf02.ndc.nasa.gov (ndjsnpf02.ndc.nasa.gov [198.117.1.122]) by core3.amsl.com (Postfix) with ESMTP id A5D713A6CB4 for <tcpm@ietf.org>; Tue, 30 Jun 2009 14:04:25 -0700 (PDT)
Received: from ndjsppt02.ndc.nasa.gov (ndjsppt02.ndc.nasa.gov [198.117.1.101]) by ndjsnpf02.ndc.nasa.gov (Postfix) with ESMTP id E5A17B064B; Tue, 30 Jun 2009 16:04:46 -0500 (CDT)
Received: from ndjshub03.ndc.nasa.gov (ndjshub03.ndc.nasa.gov [198.117.4.162]) by ndjsppt02.ndc.nasa.gov (8.14.3/8.14.3) with ESMTP id n5UL4kZa008484; Tue, 30 Jun 2009 16:04:46 -0500
Received: from NDJSSCC01.ndc.nasa.gov ([198.117.4.166]) by ndjshub03.ndc.nasa.gov ([198.117.4.162]) with mapi; Tue, 30 Jun 2009 16:04:47 -0500
From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <wesley.m.eddy@nasa.gov>
To: Christos Zoulas <christos@zoulas.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Date: Tue, 30 Jun 2009 16:04:45 -0500
Thread-Topic: [tcpm] poll for adopting draft-gont-tcp-security
Thread-Index: Acn5wkA++fxZDnR+RP22raPwya8BuAAADXdQ
Message-ID: <C304DB494AC0C04C87C6A6E2FF5603DB2217BA0686@NDJSSCC01.ndc.nasa.gov>
References: <20090630161508.7DA715654F@rebar.astron.com>
In-Reply-To: <20090630161508.7DA715654F@rebar.astron.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-06-30_16:2009-06-25, 2009-06-30, 2009-06-30 signatures=0
Cc: "fernando@gont.com.ar" <fernando@gont.com.ar>
Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Tue, 30 Jun 2009 21:04:43 -0000

Hi Christos, I had to approve this email from the moderator
queue, so I'm guessing you're not on the TCPM mailing list?
Thanks for your comments; here is one point that I need to
raise, not particularly in response to your mail, but
collectively to several similar mails that have come in to
me from people external to the TCPM list:

Remember, we're a volunteer organization  ... As the TCPM
chairs, trying to gauge *working group* support sufficient
to both adopt the work and complete it, it's worth a lot
more to have people that are committing to be "in" the
working group (i.e subscribed to the mailing list), and to
say they'll review, add to, or otherwise provide inputs on
the draft content.  For all the external folks who are
trying to weigh in on this, but not on the list, I encourage
you to join first:
https://www.ietf.org/mailman/listinfo/tcpm
We'll really appreciate inputs on this and other working
group items.

It should be understood that since we're a volunteer
organization, we can't just throw people and money at a
task ... people have to throw themselves at it and we
provide an avenue for them to work together with the
mailing list and working group meetings :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>-----Original Message-----
>From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of
>Christos Zoulas
>Sent: Tuesday, June 30, 2009 12:15 PM
>To: tcpm@ietf.org
>Cc: fernando@gont.com.ar
>Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
>
>
>Hello,
>
>I just finished reading this thread, and my conclusion is that
>Fernando Gonts document draft-gont-tcp-security should be adopted
>as a work item for TCPM.  Any document this size is bound to have
>flaws and corrections and adjustments will be necessary. I cannot
>think of a more qualified group of people to work on this document,
>and I think it will be time well spent.
>
>Best Regards,
>
>christos
>_______________________________________________
>tcpm mailing list
>tcpm@ietf.org
>https://www.ietf.org/mailman/listinfo/tcpm