Re: [tcpm] WGLC for UTO

Lars Eggert <lars.eggert@nokia.com> Wed, 10 October 2007 16:01 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife01-000724-8b; Wed, 10 Oct 2007 12:01:29 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ife00-00071w-K4 for tcpm-confirm+ok@megatron.ietf.org; Wed, 10 Oct 2007 12:01:28 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ife00-00071o-5W; Wed, 10 Oct 2007 12:01:28 -0400
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ifdzz-0000wu-LC; Wed, 10 Oct 2007 12:01:28 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AG0idO029882; Wed, 10 Oct 2007 19:01:21 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:48 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:48 +0300
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 18:59:47 +0300
Received: from [172.18.176.123] (essapo-nirac252124.europe.nokia.com [10.162.252.124]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9AFxhp9031981; Wed, 10 Oct 2007 18:59:45 +0300
In-Reply-To: <BAB4DC0CD5148948A86BD047A85CE2A703EF7F64@E03MVZ4-UKDY.domain1.systemhost.net>
References: <BAB4DC0CD5148948A86BD047A85CE2A703EF7F64@E03MVZ4-UKDY.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <4F48A5DF-F6C9-4910-9189-065F99BB2885@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [tcpm] WGLC for UTO
Date: Wed, 10 Oct 2007 10:59:42 -0500
To: "ext tcpm-bounces@ietf.org" <tcpm-bounces@ietf.org>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 10 Oct 2007 15:59:47.0979 (UTC) FILETIME=[9549BDB0:01C80B56]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: tcpm@ietf.org, mallman@icir.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0298636757=="
Errors-To: tcpm-bounces@ietf.org

On 2007-10-10, at 10:22, ext tcpm-bounces@ietf.org wrote:
> Concern:
>
> Section 4.1 Middleboxes suggests that "In the future, such [stateful]
> firewalls may learn to parse the TCP User Timeout Option and adapt
> connection state management accordingly." Would it be worth adding  
> that
> in this case this could become a potential security issue as it would
> allow cooperative users to cause a stateful firewall to maintain
> connection state for over 22 hours?

Similar to how UTO is not binding for the ends (i.e., they may close  
a connection at any time), it is not binding for middleboxes. So  
these (so far purely hypothetical) middleboxes are free to time out  
the binding at any time, for example, if they become resource- 
constrained. We could make that explicit in the draft, if people feel  
the current text is unclear.

> Nits:

We'll fix these.

Thanks,
Lars
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm