summaryrefslogtreecommitdiff
path: root/internet-draft-satp.txt
diff options
context:
space:
mode:
authorOthmar Gsenger <otti@anytun.org>2008-04-12 11:24:13 +0000
committerOthmar Gsenger <otti@anytun.org>2008-04-12 11:24:13 +0000
commit572823f65b365cd27345ee59d89b115df34c5338 (patch)
tree8f9ae97b3480b5fe7f049ec040b0e8aeefab7bd9 /internet-draft-satp.txt
parentmakefile fixes (diff)
svn cleanup
Diffstat (limited to 'internet-draft-satp.txt')
-rw-r--r--internet-draft-satp.txt952
1 files changed, 0 insertions, 952 deletions
diff --git a/internet-draft-satp.txt b/internet-draft-satp.txt
deleted file mode 100644
index 330476c..0000000
--- a/internet-draft-satp.txt
+++ /dev/null
@@ -1,952 +0,0 @@
-
-
-
-Network Working Group O. Gsenger
-Internet-Draft June 21, 2007
-Expires: December 23, 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 23, 2007.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger Expires December 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 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 23, 2007 [Page 14]
-
-Internet-Draft secure anycast tunneling protocol (SATP) June 2007
-
-
-URIs
-
- [7] <http://www.iana.org/assignments/ethernet-numbers>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger Expires December 23, 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 23, 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 23, 2007 [Page 17]
-