Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on November 24, 2004.

Copyright Notice

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

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.

Table of Contents

1.  Requirements notation
2.  Introduction
3.  AYIYA Packet format
4.  Heartbeat
5.  Acknowledgements
6.  Security Considerations
7.  Scenarios
    7.1  Tunneling to multiple endhosts behind a NAT
§.  References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Requirements notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..

2. Introduction

Many users are currently located behind NAT's which prohibit the usage of proto-41 IPv6 in IPv4 tunnels unless they manually reconfigure their NAT setup which in some cases is impossible as the NAT can't be configured to forward proto-41 ([RFC1933]Gilligan, R. and E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, April 1996.) to a specific host. There might also be cases when multiple endpoints are behind the same NAT, when multiple NAT's are used or when the user has no control at all on the NAT setup. This is a undesired situation as it limits the deployment of IPv6, which was meant to solve the problem of the disturbance in end to end communications by NATs, which where created because of limited address space, in the first place.

This problem can be solved easily by tunneling the IPv6 packets over either UDP, TCP or even SCTP. Taking into consideration that multiple seperate endpoints could be behind the same NAT and/or that the public endpoint can change on the fly there is also a need to be able to identify packets as coming from a certain endpoint and to be able to automatically change the endpoint on the fly. The protocol described in this document is protocol independent and can be run over and also encapsulate any protocol. Examples are IPv6-in-UDP-in-IPv4, which is a typical setup which can be used by Tunnel Brokers.

This protocol doesn't describe how to determine the identity, signature type or the inner and outer protocols. These should be negotiated manually or automatically by eg using TSP or a relevant protocol which is capable of describing ayiya tunnels.

3. AYIYA Packet format

The AYIYA protocol is put inside the data part of either UDP [RFC0768]Postel, J., User Datagram Protocol, August 1980., TCP [RFC0793]Postel, J., Transmission Control Protocol, September 1981. or SCTP [RFC2960]Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, Stream Control Transmission Protocol, October 2000. which are the currently defined transport protocols, future transport protocols could also be used. The transport protocol can be run over both IPv4 or IPv6 or any other future protocol. Schematically this will look like the following diagram.

+--------+                    +--------+
| Client | <--- Internet ---> | Server |
+--------+                    +--------+

A complete on the wire packet will have the following format.

,------------------------------.
|       Delivery Header         |
|        IPv4/IPv6/...          |
+-------------------------------+
|       Transport Header        |
|        TCP/UDP/SCTP/...       |
+-------------------------------+
|          AYIYA Header         |
+-------------------------------+
|        Payload packet         |
`-------------------------------'

The AYIYA protocol header and has the following format.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity Type | SignatureType |  Next Header  |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Epoch Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                            Identity                           :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
:                            Signature                          :
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Epoch Time is the time in seconds since "00:00:00 1970-01-01 UTC". Both the client and the server are advised to be synchronized using NTP [RFC2030]Mills, D., Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, October 1996. to make sure that the system clocks of the hosts don't differ to much even after travelling the intermediate networks between the client and the server. The number of seconds since the above date are stored in a 32 bit unsigned integer in network byte order.

The Identity Type specifies what kind of Identity is included in the header. Currently defined are:

 - 0x01  32 bit integer  (4 bytes)
 - 0x02  64 bit integer  (8 bytes)
 - 0x03 128 bit integer (16 bytes)
 - 0x04 256 bit integer (32 bytes)
 - 0x11   4 byte ASCII string
 - 0x12   8 byte ASCII string
 - 0x13  16 byte ASCII string
 - 0x14  32 byte ASCII string

Other values are reserved. The kind of identity used by a tunnel is negotiated outside this protocol. ASCII strings are NULL padded if they don't fill the complete identity field.

The Signature Type contains the kind of signature used by the protocol. Currently defined are:

 - 0x01 MD5  (128 bit - 16 bytes)
 - 0x01 SHA1 (160 bit - 20 bytes)

The Next Header, like in IPv6, contains the protocol value of the payload following the Heartbeat Header. There is no length field as we can deduce that already from the protocol that is carrying this packet. A Next Header value of 0xffff is special, see the following Heartbeat section.

The Reserved field is reserved and should be initialized to NULL.

The signature field should contain the hash of the password specified for the identity in the same hashing method as to be used for hashing the packet itself. The signature is then made over the complete packet, thus the header and payload. By hashing the password we allow arbitrarily lenght passwords to be used. Implementations could choose to precache the hashed password and thus also requiring having the cleartext password. The packet, header and payload can then be sent to the server. This method thus allows verification of the password without sending the password over the network. The server does the same thing, taking the header part of the packet, adding the password and calculating the signature which can then be compared with the signature which was sent by the client. If these match the packet can be processed further. When the signatures don't match the server MUST silently ignore the packet.

4. Heartbeat

As the server will disable the tunnel after it has not received a packet from the client after a configured time the client should send packets to the other side of the tunnel with the Next Header field to 0xffff, the payload should contain a 32 bit sequence number and may be filled with other informations. The server will reply this packet with the same payload allowing the client to compare the information and deduce latency information and other statistical information from it. This packet also allows the client to test if at least the tunnel to the server works. If the signature is not correct, either because of the wrong password, wrong hash, wrong identity or connectivity problems the client won't get a reply and could notify the client of this situation.

Clients should send these packets once per 60 seconds as the server is usually configured to disable the tunnel after 120 seconds.

5. Acknowledgements

The protocol presented has formed during the existence of SixXS [SIXXS]Massar, J. and P. van Pelt, SixXS - IPv6 Deployment & Tunnelbroker, . to allow the users of the various tunnel servers provisioned by SixXS to have a dynamic non-static IPv4 endpoint which could even be located behind a NAT. This protocol is a combination of the proto-41 tunneling protocol and the additional SixXS Heartbeat protocol.

6. Security Considerations

The password used [RFC1321]Rivest, R., The MD5 Message-Digest Algorithm, April 1992. must never be made publicly available to 3rd parties otherwise that 3rd party could sign a packet and automatically reconfigure the tunnel endpoint. This could lead into the 3rd party sending traffic in both directions and thus posing as the actual user.

The inclusion of the epochtime along with the verification on the Tunnel Server side should guard against any replay attacks. The Tunnel Server MUST limit that the local clock compared to the timestamp from the packet MUST never differ for more than 60 seconds, this allows for at least some latency and time-desync.

Any packet that is not well formed or contains a invalid signature MUST be silently dropped, appropriate loggin may be done of these issues but in that case a ratelimit must be applied to not clutter the logs with these messages. Invalid signatures MUST be handled as possibly being spoofed, thus no packet MUST be sent back as these packets will then go to the spoofed address.

A side effect of this protocol is that whenever the client host cannot or does not send a packet in time to the Tunnel Server that it will deconfigure the tunnel. This could be the case when the client's connectivity is interrupted.

7. Scenarios

7.1 Tunneling to multiple endhosts behind a NAT

This scenario demonstrates the scenario where this protocol will find it's main usage: tunneling to multiple endhosts behind a NAT. This setup allows both clients to change their private IPv4 addresses and also to allow the NAT to change it's public IPv4 and source port numbers. The server will notice the change of source IP and port numbers and can reconfigure it's tunnel to send to the specific host:port combination for which a mapping will exist at the NAT and the packet will go through the NAT, not considering firewalling effects. If firewalls are in place then that is an administrative policy which should not be tried to be circumvented.

  10.0.0.0/8     NAT    192.0.2.0/24
                  |
,----------.  (1) | (2)  ,--------.
| Client A |------|------|        |
`----------'      |      | Tunnel |
,----------.      |      | Server |
| Client B |------|------|        |
`----------'  (3) | (4)  `--------'
                  |

(1) = src = 10.10.0.1:1234, dst = 192.0.2.42:3740
(2) = src = 192.0.2.5:4321, dst = 192.0.2.42:3740
(3) = src = 10.10.9.2:7890, dst = 192.0.2.42:3740
(4) = src = 192.0.2.5:5678, dst = 192.0.2.42:3740

Note that TEST-NET [RFC3300]Reynolds, J., Braden, R., Ginoza, S. and A. De La Cruz, Internet Official Protocol Standards, November 2002. addresses could never reach a Tunnel Server over the public Internet due to filtering of this documentation prefix.

8 References

Author's Address

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2004). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.