Subject: RE: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based schemes)

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 20 Feb 2003 09:30:08 -0600

We've also been having similar conversations about the security considerations for "triggers for transport" triggers, thinking about questions like, "should a sender respond every time it gets a Link Up/Connectivity Restored notification?".

So, we're also pretty interested in people's opinions about how often a sender should adjust its notion of what's "really" happening, and about high the bar needs to be, especially re: "bad-mid-boxes".

Spencer

> -----Original Message-----
> From: Reiner Ludwig [mailto:[email-masked]]
> Sent: Thursday, February 20, 2003 8:14 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Tsvwg] ACK DOS & Eifel (also F-RTO, DSACK-based 
> schemes) 
> 
> 
> At 13:55 19.02.2003, Mark Allman wrote:
> >
> >I am not sure what I think the right answer is here.... I think that
> >it could be Damn Hard to find a single solution.  One way to go that
> >gets you *some* protection is that the sender applies some scheme
> >where it is only allowed to revert CC state "every so often".  So,
> >even if the receiver could game things it would not cause the sender
> >to behave poorly each time the receiver tried to conceal something.
> >I.e., we could think about saying "a sender can only undo CC changes
> >once every 30 seconds" or "a sender can only undo CC changes in
> >every tenth 'loss events' throughout the connection.  I don't know
> >that those are right - they are just examples.
> 
> On the other hand, we are discussing potentially-to-be 
> *experimental* RFCs. 
> Given that, one could argue that we could/should be a bit 
> more relaxed 
> about misbehaving TCP receivers and/or bad-mid-boxes. This is 
> not saying 
> that we should ignore easy protection mechanisms, but maybe 
> during the 
> "experimental phase" we do not have to put all possible 
> engineering smarts 
> into such protection schemes.
> 
> *If* at some stage we start discussing about advancing a proposal to 
> *proposed standard* RFC, it is probably the right time to 
> think harder 
> about these security considerations. 
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Thu, 20 Feb 2003 11:51:23 -0500 (EST)

On Thu, 20 Feb 2003, Spencer Dawkins wrote:

> We've also been having similar conversations about the security
> considerations for "triggers for transport" triggers, thinking about
> questions like, "should a sender respond every time it gets a Link
> Up/Connectivity Restored notification?".
>
> So, we're also pretty interested in people's opinions about how often
> a sender should adjust its notion of what's "really" happening, and
> about high the bar needs to be, especially re: "bad-mid-boxes".

I think if a mechanism cannot be trusted enough to respond to each event,
then the mechanism is not very useful. These proposed event notifications
(triggers, eifel, etc) attempt to help the sender further infer
information from the network. However, if each event notification itself
needs yet another mechanism for the sender to "believe" the notification,
then nothing is gained.

~armando

0--                                                  --0
| Armando L. Caro Jr.      |  Protocol Engineering Lab |
| www.cis.udel.edu/~acaro  |    University of Delaware |
0--                                                  --0