summaryrefslogtreecommitdiff
path: root/draft-gsenger-secure-anycast-tunneling-protocol-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'draft-gsenger-secure-anycast-tunneling-protocol-00.txt')
-rw-r--r--draft-gsenger-secure-anycast-tunneling-protocol-00.txt952
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]
+
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-02 04:40:45 +0000