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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 13 Jan 2003 09:30:13 -0600

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:[email-masked]]
> Sent: Monday, January 13, 2003 8:20 AM
> To: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: [email-masked]
Date: Tue, 14 Jan 2003 09:11:27 +0200

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

> From: ext Spencer Dawkins [mailto:[email-masked]]
> Sent: 13 January, 2003 17:30
> To: [email-masked]
> 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:
> 
> ------------
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 14 Jan 2003 09:09:19 -0600

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 14, 2003 1:11 AM
> To: Spencer Dawkins; [email-masked]
> Subject: RE: TRIGTRAN Security Considerations (was: RE: [Trigtran]
> TRIGTRAN Nextsteps ("let the games begin"))
> 
> 
> Spencer,
>

---

From: [email-masked]
Date: Wed, 15 Jan 2003 06:39:17 +0200

Hi Spencer,

So, cutting to the chase:

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

Good, I think that would be a useful thing for TRIGTRAN to work
on.

thanks,
John