[Trigtran] TRIGTRAN Security Considerations

[Kacheong Poon <[e-mail]>]

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

I'm wondering if this kind of end2end notification should be
ruled out.  To me, notification mechanisms, such as ECN, are
much better than triggers.  And security is automatically
tied to the transport protocol as it is end2end.

It seems to me that the issue with "link down" info does not
justify to rule out notification mechanism altogether.  Please
correct me if I am wrong, I believe the major issue here is
that if the link is down for a period of time because of some
transient problems (e.g. wireless), we do not want the other
end to time out prematurely, thus the "link down trigger."
Assuming we are talking about the first hop (I believe this is
what is being considered as the first step), when a transport
level connection is being made, the two sides can agree on a
more reasonable timeout period as one end knows that the
immediate link can have this kind of transient issue.  Will
this eliminate the timeout issue in practise?

The draw back of this with normal transport protocol, such as
TCP, is that the other end will continue to retransmit data
packets.  First, this kind of retransmission with exponential
backoff will probably not cause congestion issue.  Second,
if the transport is modified such that the end2end notification
can include several timeout periods such that the other end
will stop retransmission after a certain period and wait until
it hears again from the end with a down link or a reasonable
timeout period which is longer than the default, it will work
better.  Are they other major problems?

As a matter of fact, there is a security issue with simple
"link down trigger."  What should the other end do when it
gets a "link down trigger?"  Well, the simple behavior is not to
time out and wait until it hears again from the other side.  We
all know that this is the wrong behavior as an attacker can
simply use this kind of trigger to make sure that a machine will
hang on to existing connections, thus exhausting its resources.
(Note that I skip a few steps here to illustrate how this attack
can work effectively in practise...)  So a machine getting a
"link down trigger" will still have to somehow time out the
connection after a period of idle time.  Does it mean that
the "link down trigger" is really not useful at all?  Compare
this trigger with an explicit end2end notificiation of a reasonable
timeout period, which one is better?

Assuming the normal case of first hop link issue, after the link
comes back up, there can be an end2end notification telling
the other end to gracefully recover.  This can replace the "link
up trigger."

What other triggers are needed which cannot be replaced with
end2end notification?  I read in the minutes that this point
of end2end notification was raised in the IETF BOF.  But I
don't see any discussion that it should be ruled out completely.
So what is the major problem with this?  An end2end solution
is better because there is no state stored in the network, thus
it is more scalable.  And security is tied to the transport
automatically.  Why isn't this being considered first before IETF
should look at triggers?  IMHO, there are too many issues with
triggers such that we should only look at it unless all other
alternatives have been ruled out.

							K. Poon.
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran