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 (C) The Internet Society (2004). All Rights Reserved.
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.
3. AYIYA Packet format
6. Security Considerations
7.1 Tunneling to multiple endhosts behind a NAT
§ Author's Address
§ Intellectual Property and Copyright Statements
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..
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.
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.
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.
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.
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.
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.
|[RFC0768]||Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.|
|[RFC0793]||Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.|
|[RFC1321]||Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.|
|[RFC1933]||Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.|
|[RFC2030]||Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.|
|[RFC2119]||Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC2234]||Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.|
|[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", RFC 2960, October 2000.|
|[RFC3053]||Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.|
|[RFC3056]||Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.|
|[RFC3300]||Reynolds, J., Braden, R., Ginoza, S. and A. De La Cruz, "Internet Official Protocol Standards", RFC 3300, November 2002.|
|[RFC3513]||Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.|
|[SIXXS]||Massar, J. and P. van Pelt, "SixXS - IPv6 Deployment & Tunnelbroker".|
|Gouda 2807 LW|
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.