diff options
Diffstat (limited to 'papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt')
| -rw-r--r-- | papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt | 952 |
1 files changed, 0 insertions, 952 deletions
diff --git a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt b/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt deleted file mode 100644 index 257ca7d..0000000 --- a/papers/draft-gsenger-secure-anycast-tunneling-protocol-02.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft May 2008 -Expires: November 2, 2008 - - - secure anycast tunneling protocol (SATP) - draft-gsenger-secure-anycast-tunneling-protocol-02 - -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 November 2, 2008. - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 methods used by the Secure Real-time - Transport Protocol(SRTP) [RFC3711]. It can be used as an encrypted - alternative to IP Encapsulation within IP [RFC2003] and Generic - Routing Encapsulation (GRE) [RFC2784]. Both anycast receivers and - senders are supported. - - -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. sequence number . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.4. MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.5. payload type . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.6. payload . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.7. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10 - 4.8. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10 - 4.9. MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . . . 10 - 4.10. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 10 - 4.11. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 11 - 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 November 2, 2008 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE - [RFC2784] and a secure tunneling protocol as IPsec [RFC2401] 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 [RFC1546]. - Encryption is done per packet, so the protocol is robust against - packet loss and routing changes. To reduce header overhead, - encryption techniques of SRTP [RFC3711] are being used. - -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 [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 is encapsuleted into a SATP packet by a - unicast host and gets transmitted to one of the anycast routers. - After transmisson the packet 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 this decision. - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 is then forwarded to the DNS server. - This method can be used to tunnel between 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 November 2, 2008 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - - Figure 3 - - Network A has multiple routers which act as gateway/tunnel endpoints - to another network B. This way a redundant encrypted tunnel - connection between the two networks is built up. 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 is 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 network B's routers. After - arrival the SATP packet gets decapsulated and routed to its - destination within network B. - -2.2. Encapsulation - - SATP does not depend on the lower layer protocol. This section only - gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - - 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 November 2, 2008 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 occur 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' Don't Fragment (DF) bit - is set, then 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 - [RFC2003]. This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 | MUX | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | | payload type | | | - | +-------------------------------+ | | - | | .... payload ... | | - | | +-------------------------------+ | - | | | padding (OPT) | pad count(OPT)| | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | ~ MKI (OPTIONAL) ~ | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. 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.3. 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.4. MUX - - The MUX (multiplex) field is a 16 bit unsigned integer. It is used - to distinguish multiple tunnel connections. - - - - - - - -Gsenger Expires November 2, 2008 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -4.5. payload type - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [1] . - The values 0000-05DC are reserverd and MUST NOT be used. - - Some examples for protocol numbers - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - -4.6. payload - - A packet of type payload type (e.g. an IP packet). - -4.7. 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 therefore might use the RTP padding format, so - a RTP-like padding is supported. If the padding count field is - present, the padding count field MUST be set to the padding length. - -4.8. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - Its 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.9. MKI (OPTIONAL) - - The MKI (Master Key Identifier) is OPTIONAL and of configurable - length. See SRTP Section 3.1 [RFC3711] for details. - -4.10. 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 transmitter side - - - -Gsenger Expires November 2, 2008 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - - encryption HAS TO be done before calculating the authentication tag. - A receiver HAS TO calculate the authentication tag before decrypting - the encrypted portion. - -4.11. Encryption - - Encryption is done in the same way as for SRTP [RFC3711]. This - section will only discuss some small changes that HAVE TO be made. - Please read SRTP RFC3711 section 3-9 [RFC3711] for details. - - The least significant bits of SSRC are replaced by the sender ID and - the most significant bits are replaced by the MUX. 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SATP MUX | SATP sender ID | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - = - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | SRTP SSRC | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7 - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -5. Security Considerations - - As SATP uses the same encryption techniques as SRTP [RFC3711], it - shares the same security issues. This section will only discuss some - small changes. Please read SRTP RFC3711 section 9 [RFC3711] for - details. - -5.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has its own replay list, which SHOULDN'T be syncronised because of - massive overhead. This leads to an additional possible attack. An - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered be very unlikely because - multiple attack hosts in different locations are needed to reach - seperate anycast receivers and the number of replays is limited to - 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 multiple anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -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 November 2, 2008 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -7. References - -7.1. Normative References - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - -7.2. Informational References - - [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. - Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, - March 2000. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host - Anycasting Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -URIs - - [1] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -Author's Address - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) May 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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. - - - - - - - - - - - -Gsenger Expires November 2, 2008 [Page 17] - |