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

["Spencer Dawkins" <[e-mail]>]

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