diff options
| author | Othmar Gsenger <otti@anytun.org> | 2008-04-12 11:24:13 +0000 |
|---|---|---|
| committer | Othmar Gsenger <otti@anytun.org> | 2008-04-12 11:24:13 +0000 |
| commit | 572823f65b365cd27345ee59d89b115df34c5338 (patch) | |
| tree | 8f9ae97b3480b5fe7f049ec040b0e8aeefab7bd9 /internet-draft-satp.txt | |
| parent | makefile fixes (diff) | |
svn cleanup
Diffstat (limited to 'internet-draft-satp.txt')
| -rw-r--r-- | internet-draft-satp.txt | 952 |
1 files changed, 0 insertions, 952 deletions
diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt deleted file mode 100644 index 330476c..0000000 --- a/internet-draft-satp.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft June 21, 2007 -Expires: December 23, 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 December 23, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Abstract - - The secure anycast tunneling protocol (SATP) defines a protocol used - for communication between any combination of unicast and anycast - tunnel endpoints. It allows tunneling of every ETHER TYPE protocol - (ethernet, ip ...). SATP directly includes cryptography and message - authentication based on the methodes used by SRTP. It can be used as - an encrypted alternative to IP Encapsulation within IP [3] and - Generic Routing Encapsulation (GRE) [4]. It supports both anycast - receivers and senders. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 - 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 4 - 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.1. Tunneling from unicast hosts over anycast routers - to other unicast hosts . . . . . . . . . . . . . . . . 4 - 2.1.2. Tunneling from unicast hosts to anycast networks . . . 5 - 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 5 - 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 8 - 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 9 - 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. sequence number . . . . . . . . . . . . . . . . . . . . . 9 - 4.4. payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.5. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 9 - 4.6. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 - 4.7. payload type field . . . . . . . . . . . . . . . . . . . . 10 - 4.7.1. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 - 4.7.2. authentication tag (RECOMMENDED) . . . . . . . . . . . 10 - 4.8. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 5.1. Replay protection . . . . . . . . . . . . . . . . . . . . 12 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 7.2. Informational References . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Intellectual Property and Copyright Statements . . . . . . . . . . 17 - - - - - - -Gsenger Expires December 23, 2007 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE [4] - and a secure tunneling protocol as IPsec [5] in tunnel mode. It can - be used to build redundant virtual private network (VPN) connections. - It supports peer to peer tunnels, where tunnel endpoints can be any - combination of unicast, multicast or anycast hosts, so it defines a - Host Anycast Service [6]. Encryption is done per packet, so the - protocol is robust against packet loss and routing changes. To save - some header overhead it uses the encryption techniques of SRTP [1]. - -1.1. Notational Conventions - - The keywords "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 [2]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2. Motivation and usage scenarios - - This section gives an overview of possible usage scenarios. Please - note, that the protocols used in the figures are only examples and - that SATP itself does not care about either transport protocols or - encapsulated protocols. Routing is not done by SATP and each - implemetation MAY choose it's own way of doing this task (e.g. using - functions provided by the operating system). SATP is used only to - encapsulate and encrypt data. - -2.1. Usage scenarions - -2.1.1. Tunneling from unicast hosts over anycast routers to other - unicast hosts - - An example of SATP used to tunnel in a unicast client - anycast - server model - - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - - Figure 1 - - In this scenario the payload gets encapsuleted into a SATP packet by - a unicast host and gets transmitted to one of the anycast routers. - It than gets decapsulated by the router. This router makes a routing - descision based on the underlying protocol and transmits a new SATP - package to one or more unicast hosts depending on the routing - descition. - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -2.1.2. Tunneling from unicast hosts to anycast networks - - An example of SATP used to encrypt data between a unicast host and - anycast networks - - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - - Figure 2 - - When the unicast hosts wants to transmit data to one of the anycast - DNS servers, it encapsulates the data and sends a SATP packet to the - anycast address of the routers. The packet arrives at one of the - routers, gets decapsulated and routed to the DNS server. This method - can be used to tunnel between a clients and networks providing - anycast services. It can also be used the other way to virtually - locate a unicast service within anycasted networks. - -2.1.3. Redundant tunnel connection of 2 networks - - An example of SATP used to connect 2 networks - - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - - - - -Gsenger Expires December 23, 2007 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Figure 3 - - Network A has multiple routers, that act as gateway/tunnel endpoints - to another network B. This is done to build a redundant encrypted - tunnel connection between the two networks. All tunnel endpoints of - network A share the same anycast address and all tunnel endpoints of - network B share another anycast address. When a packet from network - A gets transmitted to network B, it first arrives on one of network - A's border routers. Which router is used is determined by network - A's internal routing. This router encapsulates the package and sends - it to the anycast address of the network B routers. The SATP packet - arrives at one of network B's routers and gets decapsulated and - routed to it's destination within network B. - -2.2. Encapsulation - - SATP does not depend on which lower layer protocols is used, but this - section gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - Examples of SATP used with different lower layer and payload - protocols - - +------+-----+-------------------------------+ - | | | + ---------------+------ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - - Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - - Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | + ---------------+------ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - - Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - - Tunneling of IPv6 over IPv4 with RTP payload - - Figure 4 - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -3. Using SATP on top of IP - -3.1. Fragmentation - - The only way of fully supporting fragmentation would be to - synchronise fragments between all anycast servers. This is - considered to be too much overhead, so there are two non perfect - solutions for these 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. - - If the payload type is IP and the ip headers's Don't Fragment (DF) - bit is set, than the DF bit of the outer IP header HAS TO be set as - well. - -3.2. ICMP messages - - ICMP messages MUST be relayed according to rfc2003 section 4 [3]. - This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -4. Protocol specification - -4.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 | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | sender ID # | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ + | - | | .... payload ... | | - | |-------------------------------+-------------------------------+ | - | | padding (OPT) | pad count(OPT)| payload type | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. sender ID - - The sender ID is a 16 bit unsigned integer. It HAS TO be unique for - every sender sharing the same anycast address - -4.3. sequence number - - The sequence number is a 32 bit 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. - -4.4. payload - - A packet of the type payload type (e.g. an IP packet). - -4.5. padding (OPTIONAL) - - Padding of max 255 octets. 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 - - - -Gsenger Expires December 23, 2007 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - format, so a RTP like padding is supported. If the padding count - field is present, than the padding count field MUST be set to the - padding lenght. - -4.6. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - It's presence 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. - -4.7. payload type field - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [7] . - 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 - -4.7.1. MKI (OPTIONAL) - - The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [1] for details - -4.7.2. authentication tag (RECOMMENDED) - - The authentication tag is RECOMMENDED and of configurable length. It - contains a cryptographic checksum of the sender ID, sequence number - and the encrypted portion, but not of the MKI. On sender side - encryption HAS TO be done before calculating the authentication tag. - A receiver HAS TO calculate the authentication tag before decrypting - the encrypted portion. - -4.8. Encryption - - Encryption is done in the same way as for SRTP [1]. This section - will only discuss some small changes that HAVE TO be made. Please - read SRTP RFC3711 section 3-9 [1] for details. - - - -Gsenger Expires December 23, 2007 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - - The least significant bits of SSRC are replaced by the sender ID and - the rest is filled with zeros. For the SRTP SEQ the 16 least - significant bits of the SATP sequence number are used and the 16 most - significant bits of the sequence number replace the 16 least - significant bits of the SRTP ROC. - - Difference between SRTP and SATP - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP sequence number | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP ROC least significant | SRTP SEQ | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7 - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -5. Security Considerations - - As SATP uses the same encrytion technics as SRTP [1], it shares the - same security issues. This section will only discuss some small - changes. Please read SRTP RFC3711 section 9 [1] for details. - -5.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has it's own replay list, which SHOULDN'T be syncronised, because of - massive overhead. This leads to an additional possible attack. A - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered of be very unlikely, because - multiple attack hosts in different loactions are needed to reach the - seperate anycast receivers and the number of replays is limited to - the count of receivers - 1. Such replays might also happen because - of routing problems, so a payload protocol HAS TO be robust against a - small number of duplicated packages. The window size and position - HAS TO be syncronised between multible anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -6. IANA Considerations - - The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numbers have - to be assiged by IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -7. References - -7.1. Normative References - - [1] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - -7.2. Informational References - - [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, - "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. - - [5] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [6] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -URIs - - [7] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) June 2007 - - -Author's Address - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires December 23, 2007 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) June 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 December 23, 2007 [Page 17] - |