[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
- [Trigtran] TrigTran security requirements Gorry Fairhurst