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

[[e-mail]]

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

> -----Original Message-----
> From: ext Spencer Dawkins [mailto:[e-mail]]
> Sent: 13 January, 2003 17:30
> To: [e-mail]
> Subject: TRIGTRAN Security Considerations (was: RE: 
> [Trigtran] TRIGTRAN
> Nextsteps ("let the games begin"))
> 
> 
> Hi, Gorry,
> 
> What follows is not in RESPONSE to your thought-provoking 
> e-mail, just on the same topic (so it doesn't address all the 
> excellent questions you asked), but Carl and I had been 
> thinking on the same topic, so - to get more points of view:
> 
> ------------
> 
>   Preliminary Security Considerations for TRIGTRAN
>   ================================================
> 
>   TRIGTRAN ("Triggers for Transport" is working on mechanisms 
>   to provide explicit notifications from edge routers to endpoint 
>   transport implementations across the Internet. More details are 
>   available at: 
> 
>     http://www.ietf.org/proceedings/02nov/slides/trigtran-5.pdf/ 
> 
>   But, in a nutshell, the minimal TRIGTRAN architecture looks 
>   like this: 
> 
>    +------+ +-----------------+   (Internet   +------+ 
>    | Host | | TRIGTRAN Router |     goes      | Host | 
>    +------+ +-----------------+      here)    +------+ 
>            X                                     X
>      Sub-network Event -----------------> Notifies Transport 
>           Here                                  Here 
> 
>             (taken from the Problem Statement I-D) 
> 
>   The critical feature here is that the host receiving a TRIGTRAN 
>   trigger is across an arbitrary network topology from the TRIGTRAN 
>   edge router sending the trigger, and the host receiving the 
>   trigger has no previous trust relationship with the TRIGTRAN 
>   router. The host receiving the trigger then takes some 
>   transport-level action (sending a packet, retransmitting a 
>   packet, waiting for some period of time to transmit a packet, 
>   etc.). 
> 
>   The transports would "figure out an event" eventually, 
>   given enough time. TRIGTRAN is intended to provide 
>   network-based hints that clue the transport in more quickly 
>   (where "quickly" is measured in RTTs, not in milliseconds). 
>   Since "link down" will probably be one of the triggers, 
>   end-to-end mechanisms cannot be used to send explicit 
>   notifications (since one of the ends isn't accessible). 
> 
>   A security assessment for TRIGTRAN amounts to evaluating what
>   impact a forged trigger can have on a host that uses the hints
>   to deal with the respective event.  For example, we don't want 
>   TRIGTRAN to provide a mechanism for denial of service attacks, 
>   etc. (this should be obvious, but let's make it explicit).  
> 
>   TRIGTRAN triggers are advisory in nature - they do not replace 
>   transport-level mechanisms (in the case of TCP, the receiver's 
>   ACK stream). If a transport gets a forged "link down" trigger, 
>   but continues to receive ACKs from the actually-reachable receiver, 
>   the reasonable action is to ignore the trigger, not the ACKs. 
>   If a transport gets a forged "link up" trigger, but does not 
>   receive ACKs from the actually-unreachable receiver, the transport 
>   would take its normal action for an unresponsive receiver (in the 
>   case of TCP, this would be RTO, retransmission, and slow start). 
> 
>   The receiving host can use existing transport-level mechanisms 
>   to determine the validity of the trigger. Because TRIGTRAN triggers 
>   are advisory the host isn't required to act as if the 
> events are real.
>   Thus, we don't think a security association is required 
>   between the TRIGTRAN router and the host receiving triggers. If 
>   one is present, fine, but it's not required. 
> 
>   The alternative, requiring the host to establish trust 
> relationships 
>   with arbitrary routers in other administrative domains in order 
>   to receive triggers, seems to be overkill in this situation. 
> 
>   What are we ignoring/overlooking, if we use this model? 
> 
> > -----Original Message-----
> > From: Dr G Fairhurst [mailto:[e-mail]]
> > Sent: Monday, January 13, 2003 8:20 AM
> > To: [e-mail]; Sally Floyd
> > Subject: Re: [Trigtran] TRIGTRAN Nextsteps ("let the games begin")
> > 
> > 
> > I'd like to understand what can go wrong with these signals,
> > and therefore what constraints we need to introduce.
> > 
> > I would like to see a "threat" analysis that looks at the 
> > implications of "Forged, malicious trigtran reports"
> > and also "erronous" reports taht do not reflect actual
> > path status. 
> > 
> > Here's some first thoughts:
> > 
> > Perhaps we could look at how these sort of things impact:
> > 
> > 	1) The network path from the reporting device to end host.
> > 	i.e., the signalling cost itself.
> > 
> > 	2) The impact on the recipient - of retransmission, cwnd
> > 	management, etc.
> > 
> > 	3) The rate/burst characteristics of the traffic on the 
> > 	network path from the sending end-host that arises
> > 	after trigtran processing.
> > 
> > 
> > It could be useful to look at scenarios which produce 
> > confusing indications:
> > 
> > 	1) Alternate paths - one reporting, one not....
> > 
> > 	2) Effect of two reporting devicec, with differing path 
> >      delay (possibly on the same path?) ...
> > 
> > 	etc.
> > 
> > Any ideas???
> > 
> > Gorry Fairhurst
> > 
> > Sally Floyd wrote:
> > > 
> > > Spencer -
> > > 
> > > (Getting to things a little late...)
> > > 
> > > Here are a few things to add to the outline...
> > > 
> > > >Possible Trigger Responses (choice of response depends 
> on trigger)
> > > ...
> > > >       Slow Start
> > >         (Modify the slow-start threshold ssthresh.)
> > >         Sending a trial packet, without waiting for the 
> > retransmit timer to
> > >            expire.
> > > 
> > > ...
> > > >Major Challenges
> > > ...
> > >         Forged, malicious trigtran reports.
> > > 
> > > - Sally 
> _______________________________________________
> Trigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/trigtran
> 
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran