Subject: [Trigtran] TrigTran security requirements

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 Jul 2003 23:19:27 +0200

This is just a short note, I was thinking about TrigTran, and the
authentication mechanisms talked about in the ALIAS BOF.

Here's what I came up with:

The end host that wishes to respond to a TrigTran message can use a whole of
heuristics to know if it expects a TrigTran Link-Up message, so this makes
it less vulnerable to spurious signals. The link-up draft gives some of this
machinery already.

I'd really like to see a solution where we can deploy and use TrigTran in
places other than a last hop router. What would be nice, is to know if the
TrigTran router that originates the signal is actually one on the path
between the sender and receiver - that is, has it actually seen the packets
passing between sender and receiver? This implies actually inspecting
packets and using these to identify which flows (i.e. Sending hosts) are
using the link which is covered by the TrigTran process.

One potential solution is to compute a digest of the packet(s) seen, so that
the TrigTran router can explicitly return the digest with the TrigTran
signal to the end hosts, to show that it is actually one that is involved in
forwarding the traffic - and therefore the TrigTran signal actually may be
useful. In this case, the TrigTran router doesn't need to validate its
identity in this process, merely to verify it is on the path.

One problem, as ever, is the presence of tunnel encapsulations, since the
signal may then end up at the tunnel end point, rather than the end host.
This isn't tragic (as in PMTUD), it simply deprives the end host from access
to the signal.

Gorry

_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran