[Trigtran] TrigTran security requirements

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 18 July 2003 07:24 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20645 for <trigtran-archive@odin.ietf.org>; Fri, 18 Jul 2003 03:24:41 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPbA-0006hs-VB for trigtran-archive@odin.ietf.org; Fri, 18 Jul 2003 03:24:13 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6I7OCPJ025780 for trigtran-archive@odin.ietf.org; Fri, 18 Jul 2003 03:24:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPbA-0006hj-Py for trigtran-web-archive@optimus.ietf.org; Fri, 18 Jul 2003 03:24:12 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20634 for <trigtran-web-archive@ietf.org>; Fri, 18 Jul 2003 03:24:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPb8-0005vF-00 for trigtran-web-archive@ietf.org; Fri, 18 Jul 2003 03:24:10 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19dPb3-0005vB-00 for trigtran-web-archive@ietf.org; Fri, 18 Jul 2003 03:24:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPaz-0006ga-8i; Fri, 18 Jul 2003 03:24:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dPaY-0006dQ-Gv for trigtran@optimus.ietf.org; Fri, 18 Jul 2003 03:23:34 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20629 for <trigtran@ietf.org>; Fri, 18 Jul 2003 03:23:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dPaW-0005v6-00 for trigtran@ietf.org; Fri, 18 Jul 2003 03:23:32 -0400
Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19dPaL-0005um-00 for trigtran@ietf.org; Fri, 18 Jul 2003 03:23:21 -0400
Received: from [81.160.225.55] ([81.160.225.55]) (authenticated bits=0) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h6I78dgh002951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <trigtran@ietf.org>; Fri, 18 Jul 2003 08:09:57 +0100 (BST)
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Thu, 17 Jul 2003 23:19:27 +0200
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: trigtran@ietf.org
Message-ID: <BB3CDF7F.8FE%gorry@erg.abdn.ac.uk>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 7bit
Subject: [Trigtran] TrigTran security requirements
Sender: trigtran-admin@ietf.org
Errors-To: trigtran-admin@ietf.org
X-BeenThere: trigtran@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/trigtran>, <mailto:trigtran-request@ietf.org?subject=unsubscribe>
List-Id: Triggers for Transport <trigtran.ietf.org>
List-Post: <mailto:trigtran@ietf.org>
List-Help: <mailto:trigtran-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/trigtran>, <mailto:trigtran-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran