RE: TRIGTRAN Security Considerations (was: RE: [Trigtran] TRIGTRAN Nextsteps ("let the games begin"))

Hi, John,

Oh, I'm SURE this text needs to be updated... 

On this specific point (at the risk of designing the protocol in e-mail), there needs to be a "transport responses to triggers" section, and my going-in thought is that transports might use triggers to lengthen timeout values - but not repeatedly, or at least not "to infinity".

If I'm doing a nice, long file transfer on a wireless link, and (for some reason) it's interrupted for a significant number of RTTs, it would be nice for a wireline server to get triggers saying, "this isn't unexpected. We're seeing path strangeness, not (just) peer-host strangeness. If you're willing to hold the connection open, your peer host is likely to 'come back' soon".

This might put more of the responsibility for "giving up" at the application level.

What I think TRIGTRAN should NOT be doing, is sending a "not yet" trigger every measured RTT, or something insane like that.

This seems straightforward enough (send triggers once; if they don't arrive, they aren't required to be reliable anyway, and if we're losing packets on the trigger path, the transports can use their end-to-end mechanisms to figure out EXACTLY what they need to be doing).

So, I think the short answer to John's question is, "yes, that's exactly the kind of thing I'd hope TRIGTRAN triggers would be used for."

Spencer

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Tuesday, January 14, 2003 1:11 AM
> To: Spencer Dawkins; trigtran@ietf.org
> Subject: RE: TRIGTRAN Security Considerations (was: RE: [Trigtran]
> TRIGTRAN Nextsteps ("let the games begin"))
> 
> 
> Spencer,
> 
> Quick question - in a number of wireless networks, there can 
> be spurious time-outs
> due to radio unavailability (or bad layer 2/3 coupling).  
> Quite often, this can 
> kick-off a chain of events, along the line of time-out -> tcp 
> abort -> application 
> protocol tear-down, security association tear-down.  Can 
> TRIGTRAN also be used to 
> prevent unnescessary tear-downs (a sort of - hold on, don't 
> disconnect quite yet 
> message)? If so, your text below might need to be updated slightly.
> 
> thanks,
> John
_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran