Hi,
I am resending this on request also to the multi6 wg after it was
brought to my attention that this protocol could also be used for
solving parts of the multihoming riddle. The below part which was sent to
the v6ops group still mentions that it is primarly meant for targetting
Tunnel Brokers who want to provide tunnels even behind NAT's but as the
protocol is quite generic it can also be used in the scenario where one
tunnels a 'established' communication pair. The issue which this draft
does not handle is the negotiation of the identity type, content and
the hashing method used. But that is up to another draft ;)
-----
For the folks that don't follow the i-d-announce@ietf list, below is the
announcement and I like to receive comments, especially about:
- should the header allow for multiple signature/identity types
(and thus lengths) like the current proposal.
- or should these be fixed.
- formatting/language use (send those to me directly though)
a number of them have already been pointed out to me by Christian Strauff.
I was already pointed out by some quick folks that the use of 'identity'
wasn't entirely clear. The identity field 'identifies' the host that is
sending the packets to the server side of the tunnel. This allows one
to distinguish between multiple hosts behind the same NAT and also
allows to be able to not know what the source of the packets would be.
The 'password' mentioned in some parts is actually a 'shared secret'.
It was pointed out to me that passwords usually are crypted on the
remote host so can't be used for MD5-HMAC, thus read 'shared secret'
there.
Apparently it wasn't clear why to send a hash of the complete packet
also from the draft: main reason is to be able to verify that the
identity sending this packet really is sending it and that it is
unaltered, if people want crypted packets do that in the payload or use
a different 'Next Header' which could include an additional small header
for specifying a crypto method, but that is out of scope for this
protocol.
To avoid the "AYIYA vs $name" discussions: it is a additional protocol
for Tunnel Broker setups to allow those to tunnel to endusers behind
NAT's.
Greets,
Jeroen
-----Forwarded Message-----
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D ACTION:draft-massar-v6ops-ayiya-00.txt
Date: Thu, 27 May 2004 15:40:05 -0400
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : AYIYA: Anything In Anything
Author(s) : J. Massar
Filename : draft-massar-v6ops-ayiya-00.txt
Pages : 10
Date : 2004-5-27
This document defines a tunneling protocol that can be encapsulated
in any other protocol. Using authentication tokens multiple tunnels
can be created from behind the same NAT. The tokens allow one to
identify the sender of the packet thus making it possible to
automatically switch over the endpoint. This protocol is intended as
an alternative to the proto-41 protocol in use for tunneling IPv6
over IPv4 packets over the internet. Due to the authentication this
protocol is especially useful for dynamic non-24/7 endnodes which are
located behind NATs and want to use for instance a IPv6 Tunnel
Broker. The protocol can carry any payload and thus is not limited to
only IPv6 over IPv4 but can also be used for IPv4 over IPv6 and many
other combinations of protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-massar-v6ops-ayiya-00.txt
Attachment:
signature.asc
Description: This is a digitally signed message part