From e40efd4ab6cb6bcb25f8dda72fd7c0a5a6ca2fbb Mon Sep 17 00:00:00 2001 From: Christian Pointner Date: Wed, 19 Mar 2008 18:42:24 +0000 Subject: added revision 2 of internet draft --- ...senger-secure-anycast-tunneling-protocol-02.txt | 952 +++++++++++++++++++++ 1 file changed, 952 insertions(+) create mode 100644 draft-gsenger-secure-anycast-tunneling-protocol-02.txt (limited to 'draft-gsenger-secure-anycast-tunneling-protocol-02.txt') diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-02.txt b/draft-gsenger-secure-anycast-tunneling-protocol-02.txt new file mode 100644 index 0000000..994847f --- /dev/null +++ b/draft-gsenger-secure-anycast-tunneling-protocol-02.txt @@ -0,0 +1,952 @@ + + + +Network Working Group O. Gsenger +Internet-Draft January 2008 +Intended status: Informational +Expires: July 4, 2008 + + + secure anycast tunneling protocol (SATP) + draft-gsenger-secure-anycast-tunneling-protocol-01 + +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 July 4, 2008. + +Copyright Notice + + Copyright (C) The Internet Society (2008). + + + + + + + + + + + + + + +Gsenger Expires July 4, 2008 [Page 1] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 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. sequence number . . . . . . . . . . . . . . . . . . . . . 9 + 4.3. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.4. MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.5. payload type field . . . . . . . . . . . . . . . . . . . . 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 July 4, 2008 [Page 2] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +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 July 4, 2008 [Page 3] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 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 July 4, 2008 [Page 4] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 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 July 4, 2008 [Page 5] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + + 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 July 4, 2008 [Page 6] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 July 4, 2008 [Page 7] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 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 July 4, 2008 [Page 8] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 destinguish multible tunnel connections. + + + + + + + +Gsenger Expires July 4, 2008 [Page 9] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +4.5. 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.6. payload + + A packet of the 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 these transforms might use the RTP padding + 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.8. 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.9. MKI (OPTIONAL) + + The MKI (Master Key Identifier) is OPTIONAL and of configurable + length. See SRTP Section 3.1 [1] 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 + + + +Gsenger Expires July 4, 2008 [Page 10] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + + 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.11. 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. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SATP MUX | SATP sender ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + = + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SRTP SSRC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7 + + + + + + + + + + +Gsenger Expires July 4, 2008 [Page 11] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +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 July 4, 2008 [Page 12] + +Internet-Draft secure anycast tunneling protocol (SATP) January 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 July 4, 2008 [Page 13] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +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 July 4, 2008 [Page 14] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +URIs + + [7] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires July 4, 2008 [Page 15] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +Author's Address + + Othmar Gsenger + Puerstingerstr 32 + Saalfelden 5760 + AT + + Phone: + Email: satp@gsenger.com + URI: http://www.gsenger.com/satp/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger Expires July 4, 2008 [Page 16] + +Internet-Draft secure anycast tunneling protocol (SATP) January 2008 + + +Full Copyright Statement + + Copyright (C) The Internet Society (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 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 July 4, 2008 [Page 17] + -- cgit v1.2.3