added txt version of new draft

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]
+