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

["Anantha Ramaiah (ananth)" <[e-mail]>]

 
> 
> 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.

Ok.

> 
> 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.

Agreed.

-Anantha


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm