summaryrefslogtreecommitdiff
path: root/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt
diff options
context:
space:
mode:
authorChristian Pointner <equinox@anytun.org>2009-12-05 13:33:22 +0000
committerChristian Pointner <equinox@anytun.org>2009-12-05 13:33:22 +0000
commitcf0c74e107c5b56fd3f0b425e1e103f4bb47c1ff (patch)
tree3f65b33b11bf302b9c7da533ba8541b5cfc58ced /papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt
parentupdated ChangeLog for release (diff)
removed common stuff (moved to repo anytun-common)
Diffstat (limited to 'papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt')
-rw-r--r--papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt1456
1 files changed, 0 insertions, 1456 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
deleted file mode 100644
index a636f71..0000000
--- a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt
+++ /dev/null
@@ -1,1456 +0,0 @@
-
-
-
-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]
-