protokoll umbenannt

1 files changed, 672 insertions, 0 deletions

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]
+