idnits 2.17.1 draft-massar-v6ops-ayiya-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2004) is 7268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 321, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1933 (Obsoleted by RFC 2893) ** Obsolete normative reference: RFC 2030 (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3053 ** Obsolete normative reference: RFC 3300 (Obsoleted by RFC 3600) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIXXS' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations J. Massar 3 Internet-Draft Unfix/SixXS 4 Expires: November 24, 2004 May 26, 2004 6 AYIYA: Anything In Anything 7 draft-massar-v6ops-ayiya-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on November 24, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines a tunneling protocol that can be encapsulated 38 in any other protocol. Using authentication tokens multiple tunnels 39 can be created from behind the same NAT. The tokens allow one to 40 identify the sender of the packet thus making it possible to 41 automatically switch over the endpoint. This protocol is intended as 42 an alternative to the proto-41 protocol in use for tunneling IPv6 43 over IPv4 packets over the internet. Due to the authentication this 44 protocol is especially useful for dynamic non-24/7 endnodes which are 45 located behind NATs and want to use for instance a IPv6 Tunnel 46 Broker. The protocol can carry any payload and thus is not limited to 47 only IPv6 over IPv4 but can also be used for IPv4 over IPv6 and many 48 other combinations of protocols. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. AYIYA Packet format . . . . . . . . . . . . . . . . . . . . . 3 55 4. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1 Tunneling to multiple endhosts behind a NAT . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . 9 64 1. Requirements notation 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Introduction 72 Many users are currently located behind NAT's which prohibit the 73 usage of proto-41 IPv6 in IPv4 tunnels unless they manually 74 reconfigure their NAT setup which in some cases is impossible as the 75 NAT can't be configured to forward proto-41 ([RFC1933]) to a specific 76 host. There might also be cases when multiple endpoints are behind 77 the same NAT, when multiple NAT's are used or when the user has no 78 control at all on the NAT setup. This is a undesired situation as it 79 limits the deployment of IPv6, which was meant to solve the problem 80 of the disturbance in end to end communications by NATs, which where 81 created because of limited address space, in the first place. 83 This problem can be solved easily by tunneling the IPv6 packets over 84 either UDP, TCP or even SCTP. Taking into consideration that multiple 85 seperate endpoints could be behind the same NAT and/or that the 86 public endpoint can change on the fly there is also a need to be able 87 to identify packets as coming from a certain endpoint and to be able 88 to automatically change the endpoint on the fly. The protocol 89 described in this document is protocol independent and can be run 90 over and also encapsulate any protocol. Examples are 91 IPv6-in-UDP-in-IPv4, which is a typical setup which can be used by 92 Tunnel Brokers. 94 This protocol doesn't describe how to determine the identity, 95 signature type or the inner and outer protocols. These should be 96 negotiated manually or automatically by eg using TSP or a relevant 97 protocol which is capable of describing ayiya tunnels. 99 3. AYIYA Packet format 101 The AYIYA protocol is put inside the data part of either UDP 102 [RFC0768], TCP [RFC0793] or SCTP [RFC2960] which are the currently 103 defined transport protocols, future transport protocols could also be 104 used. The transport protocol can be run over both IPv4 or IPv6 or any 105 other future protocol. Schematically this will look like the 106 following diagram. 108 +--------+ +--------+ 109 | Client | <--- Internet ---> | Server | 110 +--------+ +--------+ 111 A complete on the wire packet will have the following format. 113 ,------------------------------. 114 | Delivery Header | 115 | IPv4/IPv6/... | 116 +-------------------------------+ 117 | Transport Header | 118 | TCP/UDP/SCTP/... | 119 +-------------------------------+ 120 | AYIYA Header | 121 +-------------------------------+ 122 | Payload packet | 123 `-------------------------------' 125 The AYIYA protocol header and has the following format. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Identity Type | SignatureType | Next Header | Reserved | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Epoch Time | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 : : 135 : Identity : 136 : : 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 : : 139 : Signature : 140 : : 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 Epoch Time is the time in seconds since "00:00:00 1970-01-01 UTC". 144 Both the client and the server are advised to be synchronized using 145 NTP [RFC2030] to make sure that the system clocks of the hosts don't 146 differ to much even after travelling the intermediate networks 147 between the client and the server. The number of seconds since the 148 above date are stored in a 32 bit unsigned integer in network byte 149 order. 151 The Identity Type specifies what kind of Identity is included in the 152 header. Currently defined are: 154 - 0x01 32 bit integer (4 bytes) 155 - 0x02 64 bit integer (8 bytes) 156 - 0x03 128 bit integer (16 bytes) 157 - 0x04 256 bit integer (32 bytes) 158 - 0x11 4 byte ASCII string 159 - 0x12 8 byte ASCII string 160 - 0x13 16 byte ASCII string 161 - 0x14 32 byte ASCII string 163 Other values are reserved. The kind of identity used by a tunnel is 164 negotiated outside this protocol. ASCII strings are NULL padded if 165 they don't fill the complete identity field. 167 The Signature Type contains the kind of signature used by the 168 protocol. Currently defined are: 170 - 0x01 MD5 (128 bit - 16 bytes) 171 - 0x01 SHA1 (160 bit - 20 bytes) 173 The Next Header, like in IPv6, contains the protocol value of the 174 payload following the Heartbeat Header. There is no length field as 175 we can deduce that already from the protocol that is carrying this 176 packet. A Next Header value of 0xffff is special, see the following 177 Heartbeat section. 179 The Reserved field is reserved and should be initialized to NULL. 181 The signature field should contain the hash of the password specified 182 for the identity in the same hashing method as to be used for hashing 183 the packet itself. The signature is then made over the complete 184 packet, thus the header and payload. By hashing the password we allow 185 arbitrarily lenght passwords to be used. Implementations could choose 186 to precache the hashed password and thus also requiring having the 187 cleartext password. The packet, header and payload can then be sent 188 to the server. This method thus allows verification of the password 189 without sending the password over the network. The server does the 190 same thing, taking the header part of the packet, adding the password 191 and calculating the signature which can then be compared with the 192 signature which was sent by the client. If these match the packet can 193 be processed further. When the signatures don't match the server MUST 194 silently ignore the packet. 196 4. Heartbeat 198 As the server will disable the tunnel after it has not received a 199 packet from the client after a configured time the client should send 200 packets to the other side of the tunnel with the Next Header field to 201 0xffff, the payload should contain a 32 bit sequence number and may 202 be filled with other informations. The server will reply this packet 203 with the same payload allowing the client to compare the information 204 and deduce latency information and other statistical information from 205 it. This packet also allows the client to test if at least the tunnel 206 to the server works. If the signature is not correct, either because 207 of the wrong password, wrong hash, wrong identity or connectivity 208 problems the client won't get a reply and could notify the client of 209 this situation. 211 Clients should send these packets once per 60 seconds as the server 212 is usually configured to disable the tunnel after 120 seconds. 214 5. Acknowledgements 216 The protocol presented has formed during the existence of SixXS 217 [SIXXS] to allow the users of the various tunnel servers provisioned 218 by SixXS to have a dynamic non-static IPv4 endpoint which could even 219 be located behind a NAT. This protocol is a combination of the 220 proto-41 tunneling protocol and the additional SixXS Heartbeat 221 protocol. 223 6. Security Considerations 225 The password used [RFC1321] must never be made publicly available to 226 3rd parties otherwise that 3rd party could sign a packet and 227 automatically reconfigure the tunnel endpoint. This could lead into 228 the 3rd party sending traffic in both directions and thus posing as 229 the actual user. 231 The inclusion of the epochtime along with the verification on the 232 Tunnel Server side should guard against any replay attacks. The 233 Tunnel Server MUST limit that the local clock compared to the 234 timestamp from the packet MUST never differ for more than 60 seconds, 235 this allows for at least some latency and time-desync. 237 Any packet that is not well formed or contains a invalid signature 238 MUST be silently dropped, appropriate loggin may be done of these 239 issues but in that case a ratelimit must be applied to not clutter 240 the logs with these messages. Invalid signatures MUST be handled as 241 possibly being spoofed, thus no packet MUST be sent back as these 242 packets will then go to the spoofed address. 244 A side effect of this protocol is that whenever the client host 245 cannot or does not send a packet in time to the Tunnel Server that it 246 will deconfigure the tunnel. This could be the case when the client's 247 connectivity is interrupted. 249 7. Scenarios 251 7.1 Tunneling to multiple endhosts behind a NAT 253 This scenario demonstrates the scenario where this protocol will find 254 it's main usage: tunneling to multiple endhosts behind a NAT. This 255 setup allows both clients to change their private IPv4 addresses and 256 also to allow the NAT to change it's public IPv4 and source port 257 numbers. The server will notice the change of source IP and port 258 numbers and can reconfigure it's tunnel to send to the specific 259 host:port combination for which a mapping will exist at the NAT and 260 the packet will go through the NAT, not considering firewalling 261 effects. If firewalls are in place then that is an administrative 262 policy which should not be tried to be circumvented. 264 10.0.0.0/8 NAT 192.0.2.0/24 265 | 266 ,----------. (1) | (2) ,--------. 267 | Client A |------|------| | 268 `----------' | | Tunnel | 269 ,----------. | | Server | 270 | Client B |------|------| | 271 `----------' (3) | (4) `--------' 272 | 274 (1) = src = 10.10.0.1:1234, dst = 192.0.2.42:3740 275 (2) = src = 192.0.2.5:4321, dst = 192.0.2.42:3740 276 (3) = src = 10.10.9.2:7890, dst = 192.0.2.42:3740 277 (4) = src = 192.0.2.5:5678, dst = 192.0.2.42:3740 279 Note that TEST-NET [RFC3300] addresses could never reach a Tunnel 280 Server over the public Internet due to filtering of this 281 documentation prefix. 283 8 References 285 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 286 August 1980. 288 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 289 793, September 1981. 291 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 292 April 1992. 294 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 295 IPv6 Hosts and Routers", RFC 1933, April 1996. 297 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 298 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 304 Specifications: ABNF", RFC 2234, November 1997. 306 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 307 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 308 Zhang, L. and V. Paxson, "Stream Control Transmission 309 Protocol", RFC 2960, October 2000. 311 [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 312 Tunnel Broker", RFC 3053, January 2001. 314 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 315 via IPv4 Clouds", RFC 3056, February 2001. 317 [RFC3300] Reynolds, J., Braden, R., Ginoza, S. and A. De La Cruz, 318 "Internet Official Protocol Standards", RFC 3300, November 319 2002. 321 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 322 (IPv6) Addressing Architecture", RFC 3513, April 2003. 324 [SIXXS] Massar, J. and P. van Pelt, "SixXS - IPv6 Deployment & 325 Tunnelbroker", . 327 Author's Address 329 Jeroen Massar 330 Unfix/SixXS 331 Hofpoldersingel 45 332 Gouda 2807 LW 333 NL 335 EMail: jeroen@unfix.org 336 URI: http://unfix.org/~jeroen/ 338 Intellectual Property Statement 340 The IETF takes no position regarding the validity or scope of any 341 intellectual property or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; neither does it represent that it 345 has made any effort to identify any such rights. Information on the 346 IETF's procedures with respect to rights in standards-track and 347 standards-related documentation can be found in BCP-11. Copies of 348 claims of rights made available for publication and any assurances of 349 licenses to be made available, or the result of an attempt made to 350 obtain a general license or permission for the use of such 351 proprietary rights by implementors or users of this specification can 352 be obtained from the IETF Secretariat. 354 The IETF invites any interested party to bring to its attention any 355 copyrights, patents or patent applications, or other proprietary 356 rights which may cover technology that may be required to practice 357 this standard. Please address the information to the IETF Executive 358 Director. 360 Full Copyright Statement 362 Copyright (C) The Internet Society (2004). All Rights Reserved. 364 This document and translations of it may be copied and furnished to 365 others, and derivative works that comment on or otherwise explain it 366 or assist in its implementation may be prepared, copied, published 367 and distributed, in whole or in part, without restriction of any 368 kind, provided that the above copyright notice and this paragraph are 369 included on all such copies and derivative works. However, this 370 document itself may not be modified in any way, such as by removing 371 the copyright notice or references to the Internet Society or other 372 Internet organizations, except as needed for the purpose of 373 developing Internet standards in which case the procedures for 374 copyrights defined in the Internet Standards process must be 375 followed, or as required to translate it into languages other than 376 English. 378 The limited permissions granted above are perpetual and will not be 379 revoked by the Internet Society or its successors or assignees. 381 This document and the information contained herein is provided on an 382 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 383 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 384 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 385 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 386 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 388 Acknowledgment 390 Funding for the RFC Editor function is currently provided by the 391 Internet Society.