diff options
| -rw-r--r-- | papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt | 1456 |
1 files changed, 1456 insertions, 0 deletions
diff --git a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt new file mode 100644 index 0000000..a636f71 --- /dev/null +++ b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt @@ -0,0 +1,1456 @@ + + + +Network Working Group O. Gsenger +Internet-Draft C. Pointner +Expires: October 3, 2009 April 2009 + + + secure anycast tunneling protocol (SATP) + draft-gsenger-pointner-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 October 3, 2009. + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 1] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 2] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 + 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 5 + 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.1. Tunneling from unicast hosts over anycast routers + to other unicast hosts . . . . . . . . . . . . . . . . 5 + 2.1.2. Tunneling from unicast hosts to anycast networks . . . 6 + 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 6 + 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 9 + 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 9 + 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 10 + 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 10 + 4.2. sequence number . . . . . . . . . . . . . . . . . . . . . 10 + 4.3. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.4. MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.5. payload type . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.6. payload . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.7. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 11 + 4.8. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 11 + 4.9. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 11 + 5. Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. Cryptographic Contexts . . . . . . . . . . . . . . . . 12 + 5.1.2. SATP Packet Processing . . . . . . . . . . . . . . . . 13 + 5.1.3. Key derivation . . . . . . . . . . . . . . . . . . . . 15 + 5.2. Predefined Transforms . . . . . . . . . . . . . . . . . . 16 + 5.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2.2. Authentication and Integrity . . . . . . . . . . . . . 18 + 5.2.3. Key Derivation Pseudo Random Functions . . . . . . . . 18 + 5.3. Adding SATP Transforms . . . . . . . . . . . . . . . . . . 19 + 6. Key Managment and Anycast Synchronization Considerations . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 7.1. Replay protection . . . . . . . . . . . . . . . . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 9.2. Informational References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . . . 26 + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 3] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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 similar to 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 & Pointner Expires October 3, 2009 [Page 4] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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 & Pointner Expires October 3, 2009 [Page 5] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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 & Pointner Expires October 3, 2009 [Page 6] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 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 & Pointner Expires October 3, 2009 [Page 7] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 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 & Pointner Expires October 3, 2009 [Page 8] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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 & Pointner Expires October 3, 2009 [Page 9] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +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)| | + +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ + | : 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. The starting point is signaled by the key exchange mechanism + and then value is then increased by 1 for every packet sent. After + the maximum value it starts over from 0. + +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. + +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. + + + +Gsenger & Pointner Expires October 3, 2009 [Page 10] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 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 which may be added in future + (see Section 5.3) MUST define wheter they need padding or not and if + they need it they MUST define a proper padding format. 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. 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. On transmitter side encryption HAS TO be + done before calculating the authentication tag. A receiver HAS TO + calculate the authentication tag before decrypting the encrypted + portion. + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 11] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +5. Cryptography + + As mentioned earlier the cryptography of SATP is based on SRTP + [RFC3711]. For that reason we recommend to read this document as + well (especially chapter 7 Rationale). However some modifications + were made in order to fit the changed conditions of SATP. The + following section describes the whole cryptography of SATP. + +5.1. Basic Concepts + + In order to cope with anycast and packet loss it is important to be + able to process one packet on its own without the need for packets + from the past as an additional information source. Therefore SATP as + well as SRTP [RFC3711] defines a so called cryptographic context. + This context consits of all information which is needed to process a + single SATP packet and is divided into packet specific parameters and + global parameters. The packet specific parameters can be found in + the protocol header and global parameters have to be generated by the + key exchange mechanism external to SATP (see Section 6). For anycast + sender the global parameters have to be synchronized between all + hosts which share the same anycast address. The packet specific + parameters MUST NOT be synchronized. + SATP uses two types of keys: master keys and session keys. A session + key is meant to be used for a cryptographic transform (encrytion or + message authentication) for one packet. The master keys are used to + derive packet-specific session keys in a cryptographical secure way. + +5.1.1. Cryptographic Contexts + +5.1.1.1. Global Parameters + + As mentioned above global parameters HAVE TO either be provided by + the key exchange mechanism or configured manually. + + o a master key(s) which MUST be random and kept secret. + + o a master salt which MUST be random and MAY be public (RECOMMENDED + to be kept secret as well). + + o a role specifier used by the key derivation to determine which + session keys to generate for outbound or inbound traffic. + + o identifier for the key derivation pseudo random function. + + o identifier for the encryption algorithm (i.e. cipher and its mode + of operation). + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 12] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + o if used an identifier for the authentication algorithm. + + o transform specific parameters such as key lengths, see + Section 5.2. + + o if used the length of the authentication tag which should be + truncated to the packet. + + o an indicator which specifies if padding is needed or not (presence + of padding count field). + + o a replay list for each sender (see Section 5.1.1.3), maintained by + the receiver which contains the sequence numbers of received and + authenticated packets, this lists may be implemented as a sliding + window. + + o a [ From , To ] value pair which specifies the lifetime of a + master key (including the range endpoints), expressed in terms of + a pair of 32-bit sequence numbers. + +5.1.1.2. Packet-Specific Parameters + + o the sequence number + + o the sender id + + o the mux value + +5.1.1.3. Mapping SATP packets to Cryptographic Contexts + + A cryptographic contexts SHALL be uniquely identifed by the tuple + context identifier: + + context id = [ source address , source port ] + + In order to cope with anycast sender and replay protection there HAS + TO be more than one replay list per context. Each replay list inside + a cryptographic context SHALL be uniquely identified by the sender + id. + +5.1.2. SATP Packet Processing + + Before any SATP packet can be processed a cryptographic context HAS + TO be initialized by the key management mechanism. After that a SATP + sender SHALL do the following to create a SATP packet: + + 1. Determine the next sequence number to use. + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 13] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 2. Determine the crypotgraphic context as described in + Section 5.1.1.3. + + 3. Determine the master key and master salt for the packets sequence + number. + + 4. Compute all session keys and session salts which are needed by + the encryption transform using the key derivation pseudo random + function. + + 5. Encrypt the payload type field concatenated with the payload to + produce the encrypted portion of the packet using the encryption + algorithm defined by the cryptographic context. + + 6. Fill in sender id, mux and sequence number fields. + + 7. If needed compute the session authentication key using the key + derivation pseudo random function. + + 8. Generate the authentication tag over the authenticated portion + using the authentication algorithm defined by the cryptographic + context and append it to the packet. + + On receiver side the packet SHALL be processed as follows: + + 1. Determine the crypotgraphic context as described in + Section 5.1.1.3. + + 2. Determine the master key and master salt for the packets + sequence number. + + 3. Check if the packet was replayed using the replay list for the + packets sender id. + + 4. If needed compute the session authentication key using the key + derivation pseudo random function. + + 5. Generate the authentication tag over the authenticated portion + using the authentication algorithm defined by the crpyptographic + context and compare it with the tag appended to the received + packet. If it is equal remove the tag and move on. If it is + not equal drop the packet. + + 6. Store the sequence number in the replay list. + + 7. Compute all session keys and session salts which are needed by + the encryption transform using the key derivation pseudo random + function. + + + +Gsenger & Pointner Expires October 3, 2009 [Page 14] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 8. Decrypt the encrypted portion using the encryption algorithm + defined by the cryptographic context. + + 9. Check if the payload type is supported by this tunnel endpoint + and discard the packet in case it isn't supported. + + 10. Remove all fields beside the payload itself from the packet. + +5.1.3. Key derivation + + Any encryption or message authentication transform which is used + (predefined or newly introduced according to Section 5.3) MUST obtain + its secret values (keys and salts) using the SATP key derivation. + After the key exchange mechanism has signaled all needed parameters + (i.e. master key and salt) no additional communiction between sender + and receiver is needed until the next rekeying takes place. To + achieve this the key derivation uses an pseudo random function seeded + by the master key, master salt, the packets sequence number and a + label (identifier for the key to compute). + + SATP key derivation + + packet sequence nummber ----+ + | + V + +------------+ master +------------+ + | | key | |--> session encryption key + | ext. key |------->| key | + | management | | |--> session encryption salt + | mechanism |------->| derivation | + | | master | |--> session authentication key + +------------+ salt +------------+ + + Figure 7 + + SRTP [RFC3711] defines a pseudo random function as follows: + Let m and n be positive integers. A pseudo-random function family is + a set of keyed functions {PRF_n(k,x)} such that for the (secret) + random key k, given m-bit x, PRF_n(k,x) is an n-bit string, + computationally indistinguishable from random n-bit strings. + + For SATP key generation a pseudo random function with at least m = + 128 MUST be used. A predefined transform can be found in + Section 5.2.3. The input x of the PRF SHOULD be calculated as + follows: + + 1. Let key_id = label || sequence_number, with label defined as + below. + + + +Gsenger & Pointner Expires October 3, 2009 [Page 15] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + 2. Let x = key_id XOR master_salt, where key_id and master_salt are + aligend so that their least significant bits agree (right- + alignment). + + For each key derived by the key derivation there MUST exist a unique + label, a 32-bit constant. In order to increase security SATP uses + different session keys for inbound and outbound traffic. The role + specifier from the cryptographic context is used to determine which + session keys to use for inbound and outbound packets. The labels can + be computed by calculateing the SHA1 hash over an increasing label- + index. The label value are the 32 leftmost bits of this hash value. + We currently define 6 labels (label-index from 1 to 6) future + extensions may use labels with an index from 7 upwards. + + +--------------------+-------+-------------+------------+ + | key type | role | label-index | label | + +--------------------+-------+-------------+------------+ + | encryption key | left | 1 | 0x356A192B | + | | | | | + | encryption key | right | 2 | 0xDA4B9237 | + | | | | | + | encryption salt | left | 3 | 0x77DE68DA | + | | | | | + | encryption salt | right | 4 | 0x1B645389 | + | | | | | + | authentication key | left | 5 | 0xAC3478D6 | + | | | | | + | authentication key | right | 6 | 0xC1DFD96E | + +--------------------+-------+-------------+------------+ + + Key Derivation Labels + + The role parameter specifies which label should be used for outbound + packets. This means a endpoint with role left MUST use the labels + marked with left for outgoing packets and expects inbound packets to + be encrypted/authenticated using the labels marked with right. + +5.2. Predefined Transforms + + While SATP as well as SRTP allows the use of various encryption and + message authentication algorithms interoperable implementations MUST + support at least the following transforms. To add additional + transforms see Section 5.3. + +5.2.1. Encryption + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 16] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +5.2.1.1. NULL Encryption + + If confidendtiality of the SATP packet is not an issue the null + encryption transform can be used to increase performance. This + transform just copies the plaintext input into the ciphertext output + wihtout any padding. The identifier for that transfrom SHOULD be + NULL and it don't needs any transform specific parameters. It also + doesn't need any key or salt values computed by the key derivation. + +5.2.1.2. AES in Counter Mode + + The following describes how to use AES in counter mode for SATP + encryption. The identifier for that transform SHOULD be AES-CTR- + <key_length> or just AES-CTR in which case the key length defaults to + 128 bits. Beside the key length there are no additional transfrom + specific parameters. This transform needs a key of length + <key_length> and a 112 bit salt. These values can be generated using + the key derivation pseudo random function as follows: + + session_key = PRF_<key_length>(master_key, x) + session_salt = PRF_112(master_key, x) + with PRF and x defined as in Section 5.1.3. + + Basically AES in counter mode generates a pseudo random keystream + seeded by the session key, session salt as well as the sequence + number, sender id and mux value of the packet and encrypts a single + SATP packet using this stream. The encryption process consits of the + generation of that keystream and then bitwise exclusive-oring it onto + the packets payload. If the packet length doesn't fit a multiple of + 128 bits the remaining bits (least significant) of the keystream are + simple ingored. Therefore this transform does not need any padding. + Decryption of the packet can be achieved by generating the same + keystream and exclusive-oring it onto the encrypted portion. + +5.2.1.2.1. Keystream Generation + + In principle AES in counter mode consists of encrypting an + incrementing integer. However the starting point of the integer + value has to be randomized to get a good pseudo random key stream. A + keystream consits of several keystream segements with a size of 128 + bits (AES blocksize). Each segement can be computed by applying AES + with key k on the block CTR. The whole keystream is a concatination + of all its successive segements. Therefore a keystream looks as + follows: + + AES(session_key, CTR) || AES(session_key, CTR + 1 mod 2^128) || + AES(session_key, CTR + 2 mod 2^128) ... + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 17] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + where the 128 bit value CTR is defined as follows: + + CTR = (session_salt * 2^16) XOR (mux * 2^80) XOR (sender_id * 2^64) + XOR (sequence_number * 2^16) + + where each of the four terms are padded with as many leading zeros to + form a 128 bit value. + + Mind that the 16 least siginificant bits of CTR are zero. These bits + are used for the counter. Therefore the number of blocks generated + for one packet MUST NOT exceed 2^16 to avoid keystream reuse. This + means that the packet length MUST NOT exceed 2^16 * 128 bits = 2^23 + bits to ensure the security of the encryption. + +5.2.2. Authentication and Integrity + + It is RECOMMENDED to use an authentication tag and if it is used it + should be processed as follows. The sender generates the tag over + the authenticated portion truncates it to the left-most (most + significant) bits to fit the authentication tag length signaled by + the key exchange mechanism. After that it simple appends the tag to + the packet. The receiver computes the tag in the same way as the + sender and compares if with the received tag. If they don't match + the packet HAS TO be discarded and the incident SHOULD be logged. + +5.2.2.1. HMAC-SHA1 + + This transform uses HMAC-SHA1 (as described in [RFC2104]) as message + authentication algorithm. The identifier for the transfrom SHOULD be + SHA1 and it don't needs any transform specific parameters. The key + should be derived using the key derivation pseudo random function: + + session_auth_key = PRF_20(master_key, x) + with PRF and x defined as in Section 5.1.3 + +5.2.3. Key Derivation Pseudo Random Functions + +5.2.3.1. AES in Counter Mode + + Section 5.1.3 defines a pseudo random function which SHOULD be used + to derive session keys and salts. This describes the use of AES in + counter mode as PRF. The identifier for this PRF SHOULD be AES-CTR- + <key_length> or just AES-CTR in which case the key length defaults to + 128 bits. Beside the key length there are no additional transform + specific parameters. This transform needs a master key of length + key_length and a 112 bit master salt. The pseudo random string + consists of several segements with a size of 128 bits (AES + blocksize). The whole string can be computed as follows: + + + +Gsenger & Pointner Expires October 3, 2009 [Page 18] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + + AES(master_key, CTR) || AES(master_key, CTR + 1 mod 2^128) || + AES(master_key, CTR + 2 mod 2^128) ... + + where the 128 bit value CTR is defined as x * 2^16, with x defined as + in Section 5.1.3. + + This pseudo random function can produce pseudo random strings up to a + length of 2^23 bits. If the requested output length n does not fit + multiples of 128 bits the output SHOULD be truncated to the n first + (left-most) bits. Therefore there are n/128, rounded up, + applications of AES needed to produce the output string. + +5.3. Adding SATP Transforms + + If a new transform is to be added to SATP a standard track RFC MUST + be written to define the usage of the new transform. Any overlap + between the new RFC and this document SHOULD be avoided but it MAY be + needed to update some of the information in this document. For + example new parameters MAY be added to the cryptographic context or + there MAY be additional steps in SATP packet processing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 19] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +6. Key Managment and Anycast Synchronization Considerations + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 20] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +7. Security Considerations + + As the cryptography of SATP is based on SRTP [RFC3711], it basically + shares the same security issues. This section will only discuss some + small changes. Please read SRTP RFC3711 section 9 [RFC3711] for + details. + +7.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 & Pointner Expires October 3, 2009 [Page 21] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +8. 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 & Pointner Expires October 3, 2009 [Page 22] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +9. References + +9.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. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + +9.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 & Pointner Expires October 3, 2009 [Page 23] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +URIs + + [1] <http://www.iana.org/assignments/ethernet-numbers> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 24] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +Authors' Addresses + + Othmar Gsenger + Puerstingerstr 32 + Saalfelden 5760 + AT + + Phone: + Email: satp@gsenger.com + URI: http://www.gsenger.com/satp/ + + + Christian Pointner + Wielandgasse 19 + Graz 8010 + AT + + Phone: + Email: equinox@anytun.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gsenger & Pointner Expires October 3, 2009 [Page 25] + +Internet-Draft secure anycast tunneling protocol (SATP) April 2009 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2009). + + 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 & Pointner Expires October 3, 2009 [Page 26] + |