From 73c9b993bfdf02306e662ede7b40ec68498f7fec Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Tue, 17 Apr 2007 20:48:43 +0000 Subject: protokoll umbenannt --- internet-draft-satp.txt | 672 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 672 insertions(+) create mode 100644 internet-draft-satp.txt (limited to 'internet-draft-satp.txt') diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt new file mode 100644 index 0000000..16faed2 --- /dev/null +++ b/internet-draft-satp.txt @@ -0,0 +1,672 @@ + + + +Network Working Group O. Gsenger +Internet-Draft March 2007 +Expires: September 2, 2007 + + + secure anycast tunneling protocol (satp) + draft-gsenger-secure-anycast-tunneling-protocol-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + 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 September 2, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 1] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +Abstract + + The secure anycast tunneling protocol (satp) defines a protocol used + for communication between any combination of unicast and anycast + tunnel endpoints. It has less protocol overhead than IPSec in Tunnel + mode and allows tunneling of every ETHER TYPE protocol (e.g. + ethernet, ip, arp ...). satp directly includes cryptography and + message authentication based on the methodes used by SRTP. It is + intended to deliver a generic, scaleable, secure and reliability + solution for tunneling and relaying of packets of any protocol. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 2] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +1. Introduction + + anytun defines a Host Anycast Service as defined in rfc1546. It uses + a peer-to-peer achitecture, with anycast servers and unicast clients. + It can be used to build high scalable and redundant tunnel services. + It also has a relay mode, that makes it possible, that only one of + the connection endpoints has to use the anytun protocol. This can be + used to make connections through Firewalls or behind a NAT Router + + RFC3068 [1] DTD. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 3] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +2. Operation modes + + This section gives an overview of possible operation modes und usage + scenarios. Please note, that the protocols used in the figures are + only examples and that anytun itself does not care about either + transport protocols or encapsulated protocols. Routing and network + address translation is not done by anytun. Each implemetation MAY + choose it's own way of doing this task (e.g. using functions provided + by the operating system). Anytun is used to establish and controll + tunnnels, to encapsulate and encrypt data. + +2.1. Usage scenarions + +2.1.1. tunneling from unicast client over anycast servers to unicast + client + + An example of anytun used in tunnel mode + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + | UDP | ---------- | UDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 1 + + In tunneling mode the payload of the anytun packet is transmitted + from one unicast host to the anycast server. This server makes a + routing descision based on the underlying protocol and transmits a + new anytun package to one or more clients depending on the routing + descition. The server MAY also route the packet to a directly + connected network or a service running on the server, but please + note, that this is only usefull for anycast host services like DNS + and that the services HAVE TO be running on all servers in order to + work. + + + + + + + +Gsenger Expires September 2, 2007 [Page 4] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +2.1.2. tunneling from client to a server connected network + + An example of anytun used in open tunnel mode + + ----------- + | RTP | ---------- + ----------- -> |server 1| -> + | UDP | ---------- ----------- + ----------- | RTP | + ----- | IPv6 | ---------- ----------- ----- + | | -> ----------- -> |server 2| -> | UDP* | -> | | + ----- | anytun | ---------- ----------- ----- + ##### ----------- | IPv6* | ##### + | UDP | ---------- ----------- + client 1 ----------- -> |server 3| -> | ... | host + | IPv4 | ---------- not using + ----------- anytun + | ... | anycast + *changed source address + or port + + Figure 2 + + In open tunnel mode only one of two clients talking to each other + over the servers MUST use the anytun protocol. When a client using + the anytun protocol wants to tunnel data, it is building a connection + to the anycast servers using the anytun protocol. The anycast + servers relay the encapsulated packages directly to the destination + without using the anytun protocol. The source address of the + datagramm HAS TO be changed to the anycast address of the server. + The anytun servers act like a source NAT router, therefor for the + destination it saems that it is talking to the client directly. + +2.2. Transport modes + + Anytun does not define wich lower layer protocols HAVE TO be used, + but it's most likely used on top of udp. This section should only + discuss some issues on udp in combination with anycasting and + tunnels. + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 5] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +2.2.1. Using UDP + + An example of anytun used with udp as transport + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + | UDP | ---------- | UDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 3 + + When using UDP no flow controll or retransmission is done, neigther + by UDP nor anytun. The encapsulated protocol HAS TO take care of + this tasks if needed. UDP however has a checksum of the complete udp + datagram, so a packet gets discarded if there is a biterror in the + payload + +2.2.2. Using lightUDP + + An example of anytun used with udp transport + + ----------- ----------- + | RTP | ---------- | RTP | + ----------- -> |server 1| -> ----------- + | UDP | ---------- | UDP | + ----------- ----------- + ----- | IPv6 | ---------- | IPv6 | ----- + | | -> ----------- -> |server 2| -> ----------- -> | | + ----- | anytun | ---------- | anytun | ----- + ##### ----------- ----------- ##### + |lightUDP | ---------- |lightUDP | + client 1 ----------- -> |server 3| -> ----------- client 2 + | IPv4 | ---------- | IPv4 | + ----------- ----------- + | ... | anycast | ... | + + Figure 4 + + + + +Gsenger Expires September 2, 2007 [Page 6] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + + The difference between normal UDP and lightUDP is, that the udp size + is not set to the length of the full packet, but to the lenght of the + data used for the checksum and therefor the checksum is only + calculated for that part. When using lightUDP, the lenght HAS tO be + set to the udp header length + the anytun header lenght. So there is + no error correction or detection done on the payload. This can be + usefull if realtime data is beeing transimittet or the tunneled + protocol does error correction/detection by itself. + +2.2.3. Fragmentation + + The only way of fully supporting fragmentation would be to syncronise + fragments between all anycast servers. This is considered to be to + much overhead, so there are two non perfect solutions for this + problems. Either fragmentation HAS TO be disabled or if not all + fragments arrive at the same server the ip datagramm HAS TO be + discarded. As routing changes are not expected to occure very + frequently, the encapsulated protocol can do a retransmission and all + fragments will arrive at the new server. + +2.3. Protocol specification + +2.3.1. Header format + + Protocol 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | sequence number | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | .... payload ... | | + | |-------------------------------+-------------------------------+ | + | | padding (OPT) | pad count(OPT)| payload type | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ~ MKI (OPTIONAL) ~ | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | : authentication tag (RECOMMENDED) : | + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + +- Encrypted Portion* Authenticated Portion ---+ + + Figure 5 + + + + + + + +Gsenger Expires September 2, 2007 [Page 7] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +2.3.2. sequence number + + The sequenze number is a 32bit unsigned integer in network byte + order. It starts with a random value and is increased by 1 for every + sent packet. After the maximum value, it starts over from 0. This + overrun causes the ROC to be increased. + +2.3.3. payload + + A packet of the type payload type (e.g. an IP packet). + +2.3.4. padding (OPTINAL) + + Padding of max 255 ocitets. None of the pre-defined encryption + transforms uses any padding; for these, the plaintext and encrypted + payload sizes match exactly. Transforms are based on transforms of + the SRTP protocol and these transforms might use the RTP padding + format, so a RTP like padding is supported. If padding field is + present, than the padding count field MUST be set to the padding + lenght. + +2.3.5. padding count + + The number of octets of the padding field. This field is optional. + It's presents is signaled by the key management and not by this + protocol. If this field isn't present, the padding field MUST NOT be + present as well. + +2.3.6. payload type field + + The payload type field defines the payload protocol. ETHER TYPE + protocol numerbers are used. + http://www.iana.org/assignments/ethernet-numbers . The values 0000- + 05DC are reserverd and MUST NOT be used. + + Some examples for protocol types + + HEX + 0000 Reserved + .... Reserved + 05DC Reserved + 0800 Internet IP (IPv4) + 6558 transparent ethernet bridging + 86DD IPv6 + + Figure 6 + + + + + +Gsenger Expires September 2, 2007 [Page 8] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +Appendix A. The appan + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 9] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +3. References + + [1] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", + RFC 3068, June 2001. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 10] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +Author's Address + + Othmar Gsenger + Sporgasse 6 + Graz 8010 + AT + + Phone: + Email: otti@wirdorange.org + URI: http://anytun.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires September 2, 2007 [Page 11] + +Internet-Draft secure anycast tunneling protocol (satp) March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Gsenger Expires September 2, 2007 [Page 12] + -- cgit v1.2.3