IETF Logo Mail Archive

Re: [tcpm] Is this a problem?

Mark Allman <mallman@icir.org> Mon, 19 November 2007 13:38 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 1Iu6pF-0000UW-AE; Mon, 19 Nov 2007 08:38:09 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iu6pD-0000U9-V3 for tcpm-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:38:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6pD-0000Ty-Ku for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:07 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6pD-0007Z6-8K for tcpm@ietf.org; Mon, 19 Nov 2007 08:38:07 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lAJDc5vU012094; Mon, 19 Nov 2007 05:38:06 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 97BB212199C7; Mon, 19 Nov 2007 08:37:59 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 58ADD2F5CF2; Mon, 19 Nov 2007 08:35:38 -0500 (EST)
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
From: Mark Allman <mallman@icir.org>
Subject: Re: [tcpm] Is this a problem?
In-Reply-To: <359024.58790.qm@web31711.mail.mud.yahoo.com>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Who Made Who
MIME-Version: 1.0
Date: Mon, 19 Nov 2007 08:35:38 -0500
Message-Id: <20071119133538.58ADD2F5CF2@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
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="===============0084789957=="
Errors-To: tcpm-bounces@ietf.org

> Clearly there seems to be no consensus on where the problem lies.

That is my read of this thread.

> It seems to me that all of these approaches have a key flaw in that
> they leave the solution to be handled by a proprietary method of
> defending against the attack. Solving the problem in the transport
> layer would make the solution a standard one 

I think a key question here is whether we need a standard solution.  If
this were solved in a 'proprietary' manner, why would that be a big
deal?  I don't understand this notion that we need some sort of standard
behavior here.  Please explain.

allman




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

v2.29.0 | Report a Bug | By Email | System Status