satp internet draft 00 final ietf version

1 files changed, 952 insertions, 0 deletions

diff --git a/draft-gsenger-secure-anycast-tunneling-protocol-00.txt b/draft-gsenger-secure-anycast-tunneling-protocol-00.txt
new file mode 100644
index 0000000..fb3ca45
--- /dev/null
+++ b/draft-gsenger-secure-anycast-tunneling-protocol-00.txt
@@ -0,0 +1,952 @@
+
+
+
+Network Working Group                                         O. Gsenger
+Internet-Draft                                             June 22, 2007
+Expires: December 24, 2007
+
+
+                secure anycast tunneling protocol (SATP)
+           draft-gsenger-secure-anycast-tunneling-protocol-00
+
+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 December 24, 2007.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 1]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+Abstract
+
+   The secure anycast tunneling protocol (SATP) defines a protocol used
+   for communication between any combination of unicast and anycast
+   tunnel endpoints.  It allows tunneling of every ETHER TYPE protocol
+   (ethernet, ip ...).  SATP directly includes cryptography and message
+   authentication based on the methodes used by SRTP.  It can be used as
+   an encrypted alternative to IP Encapsulation within IP [3] and
+   Generic Routing Encapsulation (GRE) [4].  It supports both anycast
+   receivers and senders.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Notational Conventions . . . . . . . . . . . . . . . . . .  3
+   2.  Motivation and usage scenarios . . . . . . . . . . . . . . . .  4
+     2.1.  Usage scenarions . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.1.  Tunneling from unicast hosts over anycast routers
+               to other unicast hosts . . . . . . . . . . . . . . . .  4
+       2.1.2.  Tunneling from unicast hosts to anycast networks . . .  5
+       2.1.3.  Redundant tunnel connection of 2 networks  . . . . . .  5
+     2.2.  Encapsulation  . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Using SATP on top of IP  . . . . . . . . . . . . . . . . . . .  8
+     3.1.  Fragmentation  . . . . . . . . . . . . . . . . . . . . . .  8
+     3.2.  ICMP messages  . . . . . . . . . . . . . . . . . . . . . .  8
+   4.  Protocol specification . . . . . . . . . . . . . . . . . . . .  9
+     4.1.  Header format  . . . . . . . . . . . . . . . . . . . . . .  9
+     4.2.  sender ID  . . . . . . . . . . . . . . . . . . . . . . . .  9
+     4.3.  sequence number  . . . . . . . . . . . . . . . . . . . . .  9
+     4.4.  payload  . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     4.5.  padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . .  9
+     4.6.  padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 10
+     4.7.  payload type field . . . . . . . . . . . . . . . . . . . . 10
+       4.7.1.  MKI (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 10
+       4.7.2.  authentication tag (RECOMMENDED) . . . . . . . . . . . 10
+     4.8.  Encryption . . . . . . . . . . . . . . . . . . . . . . . . 10
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+     5.1.  Replay protection  . . . . . . . . . . . . . . . . . . . . 12
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
+     7.2.  Informational References . . . . . . . . . . . . . . . . . 14
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
+   Intellectual Property and Copyright Statements . . . . . . . . . . 17
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 2]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+1.  Introduction
+
+   SATP is a mixture of a generic encapsulation protocol like GRE [4]
+   and a secure tunneling protocol as IPsec [5] in tunnel mode.  It can
+   be used to build redundant virtual private network (VPN) connections.
+   It supports peer to peer tunnels, where tunnel endpoints can be any
+   combination of unicast, multicast or anycast hosts, so it defines a
+   Host Anycast Service [6].  Encryption is done per packet, so the
+   protocol is robust against packet loss and routing changes.  To save
+   some header overhead it uses the encryption techniques of SRTP [1].
+
+1.1.  Notational Conventions
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119 [2].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 3]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+2.  Motivation and usage scenarios
+
+   This section gives an overview of possible usage scenarios.  Please
+   note, that the protocols used in the figures are only examples and
+   that SATP itself does not care about either transport protocols or
+   encapsulated protocols.  Routing is not done by SATP and each
+   implemetation MAY choose it's own way of doing this task (e.g. using
+   functions provided by the operating system).  SATP is used only to
+   encapsulate and encrypt data.
+
+2.1.  Usage scenarions
+
+2.1.1.  Tunneling from unicast hosts over anycast routers to other
+        unicast hosts
+
+   An example of SATP used to tunnel in a unicast client - anycast
+   server model
+
+                       --------- router -----------
+                      /                            \
+       unicast ------+---------- router ------------+------ unicast
+       host           \                            /        host
+                       --------- router -----------
+
+     unicast  | encrypted     |  anycast  | encrypted     |  unicast
+     tunnel   | communication |  tunnel   | communication |  tunnel
+     endpoint | using SATP    |  endpoint | using SATP    |  endpoint
+
+                                 Figure 1
+
+   In this scenario the payload gets encapsuleted into a SATP packet by
+   a unicast host and gets transmitted to one of the anycast routers.
+   It than gets decapsulated by the router.  This router makes a routing
+   descision based on the underlying protocol and transmits a new SATP
+   package to one or more unicast hosts depending on the routing
+   descition.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 4]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+2.1.2.  Tunneling from unicast hosts to anycast networks
+
+   An example of SATP used to encrypt data between a unicast host and
+   anycast networks
+
+                          -------Router -+---- DNS Server
+                         /                \
+                        /                  --- 6to4 Router
+                       /
+       unicast -------+----------Router --+--- DNS Server
+       host            \                   \
+                        \                   --- 6to4 Router
+                         \
+                          -------Router -+---- DNS Server
+                                          \
+                                           --- 6to4 Router
+
+     unicast  | encrypted     |  anycast  | plaintext
+     tunnel   | communication |  tunnel   | anycast
+     endpoint | using SATP    |  endpoint | services
+
+
+                                 Figure 2
+
+   When the unicast hosts wants to transmit data to one of the anycast
+   DNS servers, it encapsulates the data and sends a SATP packet to the
+   anycast address of the routers.  The packet arrives at one of the
+   routers, gets decapsulated and routed to the DNS server.  This method
+   can be used to tunnel between a clients and networks providing
+   anycast services.  It can also be used the other way to virtually
+   locate a unicast service within anycasted networks.
+
+2.1.3.  Redundant tunnel connection of 2 networks
+
+   An example of SATP used to connect 2 networks
+
+                 Router -----------   ---------------Router
+               /                   \ /                     \
+       Network - Router ------------x                       Network
+          A    \                   / \                     /   B
+                 Router -----------   ---------------Router
+
+               | packets       |  packets  |  packets      |
+    plaintext  | get           |  take a   |  get          | plaintext
+    packets    | de/encrypted  |  random   |  de/encrypted | packets
+               |de/encapsulated|   path    |de/encapsulated|
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 5]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+                                 Figure 3
+
+   Network A has multiple routers, that act as gateway/tunnel endpoints
+   to another network B. This is done to build a redundant encrypted
+   tunnel connection between the two networks.  All tunnel endpoints of
+   network A share the same anycast address and all tunnel endpoints of
+   network B share another anycast address.  When a packet from network
+   A gets transmitted to network B, it first arrives on one of network
+   A's border routers.  Which router is used is determined by network
+   A's internal routing.  This router encapsulates the package and sends
+   it to the anycast address of the network B routers.  The SATP packet
+   arrives at one of network B's routers and gets decapsulated and
+   routed to it's destination within network B.
+
+2.2.  Encapsulation
+
+   SATP does not depend on which lower layer protocols is used, but this
+   section gives an example of how packets could look like.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 6]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+   Examples of SATP used with different lower layer and payload
+   protocols
+
+       +------+-----+-------------------------------+
+       |      |     |      + ---------------+------ |
+       | IPv6 | UDP | SATP | Ethernet 802.3 | ... | |
+       |      |     |      +----------------+-----+ |
+       +------+-----+-------------------------------+
+
+   Tunneling of Ethernet over UDP/IPv6
+
+       +------+-----+---------------------------+
+       |      |     |      +------+-----+-----+ |
+       | IPv4 | UDP | SATP | IPv6 | UDP | RTP | |
+       |      |     |      +------+-----+-----+ |
+       +------+-----+---------------------------+
+
+   Tunneling of IPv6 over UDP/IPv4 with RTP payload
+
+       +------+-------------------------------+
+       |      |      + ---------------+------ |
+       | IPv6 | SATP | Ethernet 802.3 | ... | |
+       |      |      +----------------+-----+ |
+       +------+-------------------------------+
+
+   Tunneling of Ethernet over IPv6
+
+       +------+---------------------------+
+       |      |      +------+-----+-----+ |
+       | IPv4 | SATP | IPv6 | UDP | RTP | |
+       |      |      +------+-----+-----+ |
+       +------+---------------------------+
+
+   Tunneling of IPv6 over IPv4 with RTP payload
+
+                                 Figure 4
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 7]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+3.  Using SATP on top of IP
+
+3.1.  Fragmentation
+
+   The only way of fully supporting fragmentation would be to
+   synchronise fragments between all anycast servers.  This is
+   considered to be too much overhead, so there are two non perfect
+   solutions for these problems.  Either fragmentation HAS TO be
+   disabled or if not all fragments arrive at the same server the ip
+   datagramm HAS TO be discarded.  As routing changes are not expected
+   to occure very frequently, the encapsulated protocol can do a
+   retransmission and all fragments will arrive at the new server.
+
+   If the payload type is IP and the ip headers's Don't Fragment (DF)
+   bit is set, than the DF bit of the outer IP header HAS TO be set as
+   well.
+
+3.2.  ICMP messages
+
+   ICMP messages MUST be relayed according to rfc2003 section 4 [3].
+   This is needed for path MTU detection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 8]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+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           #                               | |
+   +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+                               + |
+   | |              ....        payload        ...                   | |
+   | |-------------------------------+-------------------------------+ |
+   | | padding (OPT) | pad count(OPT)|         payload type          | |
+   +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+
+   | ~                          MKI (OPTIONAL)                       ~ |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   | :                 authentication tag (RECOMMENDED)              : |
+   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+   |                                                                   |
+   +- Encrypted Portion                       Authenticated Portion ---+
+
+                                 Figure 5
+
+4.2.  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.3.  sequence number
+
+   The sequence number is a 32 bit unsigned integer in network byte
+   order.  It starts with a random value and is increased by 1 for every
+   sent packet.  After the maximum value, it starts over from 0.  This
+   overrun causes the ROC to be increased.
+
+4.4.  payload
+
+   A packet of the type payload type (e.g. an IP packet).
+
+4.5.  padding (OPTIONAL)
+
+   Padding of max 255 octets.  None of the pre-defined encryption
+   transforms uses any padding; for these, the plaintext and encrypted
+   payload sizes match exactly.  Transforms are based on transforms of
+   the SRTP protocol and these transforms might use the RTP padding
+
+
+
+Gsenger                 Expires December 24, 2007               [Page 9]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+   format, so a RTP like padding is supported.  If the padding count
+   field is present, than the padding count field MUST be set to the
+   padding lenght.
+
+4.6.  padding count (OPTIONAL)
+
+   The number of octets of the padding field.  This field is optional.
+   It's presence is signaled by the key management and not by this
+   protocol.  If this field isn't present, the padding field MUST NOT be
+   present as well.
+
+4.7.  payload type field
+
+   The payload type field defines the payload protocol.  ETHER TYPE
+   protocol numbers are used.  See IANA assigned ethernet numbers [7] .
+   The values 0000-05DC are reserverd and MUST NOT be used.
+
+   Some examples for protocol types
+
+   HEX
+   0000 Reserved
+   .... Reserved
+   05DC Reserved
+   0800 Internet IP (IPv4)
+   6558 transparent ethernet bridging
+   86DD IPv6
+
+                                 Figure 6
+
+4.7.1.  MKI (OPTIONAL)
+
+   The MKI (Master Key Identifier) is OPTIONAL and of configurable
+   length.  See SRTP Section 3.1 [1] for details
+
+4.7.2.  authentication tag (RECOMMENDED)
+
+   The authentication tag is RECOMMENDED and of configurable length.  It
+   contains a cryptographic checksum of the sender ID, sequence number
+   and the encrypted portion, but not of the MKI.  On sender side
+   encryption HAS TO be done before calculating the authentication tag.
+   A receiver HAS TO calculate the authentication tag before decrypting
+   the encrypted portion.
+
+4.8.  Encryption
+
+   Encryption is done in the same way as for SRTP [1].  This section
+   will only discuss some small changes that HAVE TO be made.  Please
+   read SRTP RFC3711 section 3-9 [1] for details.
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 10]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+   The least significant bits of SSRC are replaced by the sender ID and
+   the rest is filled with zeros.  For the SRTP SEQ the 16 least
+   significant bits of the SATP sequence number are used and the 16 most
+   significant bits of the sequence number replace the 16 least
+   significant bits of the SRTP ROC.
+
+   Difference between SRTP and SATP
+
+          0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                     SATP    sequence number                   |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                      =
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       | SRTP ROC least significant   |         SRTP SEQ               |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+          0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|       SATP sender ID          |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                      =
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                           SRTP SSRC                           |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                                 Figure 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 11]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+5.  Security Considerations
+
+   As SATP uses the same encrytion technics as SRTP [1], it shares the
+   same security issues.  This section will only discuss some small
+   changes.  Please read SRTP RFC3711 section 9 [1] for details.
+
+5.1.  Replay protection
+
+   Replay protection is done by a replay list.  Every anycast receiver
+   has it's own replay list, which SHOULDN'T be syncronised, because of
+   massive overhead.  This leads to an additional possible attack.  A
+   attacker is able to replay a captured packet once to every anycast
+   receiver.  This attack is considered of be very unlikely, because
+   multiple attack hosts in different loactions are needed to reach the
+   seperate anycast receivers and the number of replays is limited to
+   the count of receivers - 1.  Such replays might also happen because
+   of routing problems, so a payload protocol HAS TO be robust against a
+   small number of duplicated packages.  The window size and position
+   HAS TO be syncronised between multible anycast receivers to limit
+   this attack.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 12]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+6.  IANA Considerations
+
+   The protocol is intended to be used on top of IP or on top of UDP (to
+   be compatible with NAT routers), so UDP and IP protocol numbers have
+   to be assiged by IANA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 13]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+        RFC 3711, March 2004.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+        October 1996.
+
+7.2.  Informational References
+
+   [4]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
+        "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
+
+   [5]  Kent, S. and R. Atkinson, "Security Architecture for the
+        Internet Protocol", RFC 2401, November 1998.
+
+   [6]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+        Service", RFC 1546, November 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 14]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+URIs
+
+   [7]  <http://www.iana.org/assignments/ethernet-numbers>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 15]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+Author's Address
+
+   Othmar Gsenger
+   Puerstingerstr 32
+   Saalfelden  5760
+   AT
+
+   Phone:
+   Email: satp@gsenger.com
+   URI:   http://www.gsenger.com/satp/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 16]
+
+Internet-Draft  secure anycast tunneling protocol (SATP)       June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+Gsenger                 Expires December 24, 2007              [Page 17]
+