RE: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

"Anantha Ramaiah (ananth)" <> Wed, 21 November 2007 22:25 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Iuy0Q-0005er-T2; Wed, 21 Nov 2007 17:25:14 -0500
Received: from tcpm by with local (Exim 4.43) id 1Iuy0N-0005eb-V4 for; Wed, 21 Nov 2007 17:25:12 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1Iuy0N-0005eJ-K8 for; Wed, 21 Nov 2007 17:25:11 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1Iuy0K-0008AB-E1 for; Wed, 21 Nov 2007 17:25:11 -0500
Received: from ([]) by with ESMTP; 21 Nov 2007 14:25:07 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id lALMP70a002339; Wed, 21 Nov 2007 14:25:07 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id lALMOevE029598; Wed, 21 Nov 2007 22:25:07 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 14:24:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Date: Wed, 21 Nov 2007 14:24:54 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Thread-Index: AcgshsDDU9ZyEQ50RGe3YxqlgaJNTwAAsTjA
From: "Anantha Ramaiah (ananth)" <>
To: Ted Faber <faber@ISI.EDU>
X-OriginalArrivalTime: 21 Nov 2007 22:24:55.0289 (UTC) FILETIME=[57AAEE90:01C82C8D]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2495; t=1195683907; x=1196547907; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<> |Subject:=20RE=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=20forward=20[Was=20Re=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=K8jQ5nLtfNVlf6tFzqf4VNX75bR72stYN8aRZNaaDQM=; b=Et8mDE0Yxk0kVB3bhRmG4Yhm0FYMPS83imepwmd7WJjHaWeYaklr2YpxHdalq5hCMdDrDOVM 3OrP7E4ioXhegIaHvXm2WTKyuaBNRDQiK2XjA8uyD153plPFKUyEjcXe;
Authentication-Results: sj-dkim-4;; dkim=pass ( sig from verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> I don't understand your snicker quotes around standardize.  
> Changing a MUST NOT to a MAY or SHOULD NOT in 1122 is about 
> as serious as standardizarion effort as one can undertake in TCPM.

Actually I asked the same question below :-) My understanding was the
same ie., changing verbiage is indeed a standardization effort. 
> I (personally) don't see the point of publishing an RFC that 
> describes a technique that a conformant TCP cannot implement.

I agree. So my understanding is that wherever the solution lies, be it a
socket option that can be set by the application OR an implicit timer
within TCP or whatever means, irrrespective of the method chosen, this
warrants a change in the RFC 1122 or atleast a clarification in the
existing verbiage w.r.t zero window probes? Do you agree?

If so then do we agree as a WG to make the change since this is required
irrespective of the fact where the solution lies?
OR do folks in the list have some solution in mind which can be done
without touching the standards?

Sorry, I haven't yet seen this particular discussion happening which is
the main purpose of my email. The only thing so far was a few people
saying that there is no need to change RFC 1122, but I am afraid I
haven't seen the reasons and/or alternate proposals.

> >                              It also mentions about the role of the 
> > application, which is again needed to be treated as 
> informational. Do 
> > you see the need for making further clarifications that would make 
> > this look better?.
> Section 3 of the draft is very hard to follow and is unclear 
> on what's being proposed.  If the work were taken up, I'd 
> recommend rewriting it.


> While one might dismiss a legitimate connection holding a 
> zero window for a long time as a corner case (though doing so 
> is projecting application semantics into the transport), the 
> more telling criticism is the first case.
> An attacker who wanted to mount the DoS attack described in 
> the draft could defeat your proposed mitigation by asking for 
> the same large window and then draining it slowly rather than 
> simply holding the zero window.  The draft mentions that the 
> silly window avoidance makes this difficult, but it just 
> requires the attacker to ACK an MSS worth of data less 
> frequently then if they read a single byte.



tcpm mailing list