summaryrefslogtreecommitdiff
path: root/internet-draft-satp.txt
diff options
context:
space:
mode:
Diffstat (limited to 'internet-draft-satp.txt')
-rw-r--r--internet-draft-satp.txt672
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]
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-02 21:23:55 +0000