13.3. ESP-Attributes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | PayloadType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 2
Length 1
PayloadType 1 byte. Indicates the contents of the ESP Transform
Data field, using the IP Next Header (Protocol)
value. Up-to-date values of the IP Next Header
(Protocol) are specified in the most recent
"Assigned Numbers" [RFC-1700].
For example, when encrypting an entire IP datagram,
this field will contain the value 4, indicating IP-
in-IP encapsulation.
When a list of Attributes is specified, this Attribute begins the
section of the list which applies to the Encapsulating Security
Payload (ESP).
When listed as an Offered-Attribute, the PayloadType is set to 255.
When selected as an Attribute-Choice, the PayloadType is set to the
actual value to be used.
13.4. MD5-IPMAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 5
Length 0
13.4.1. Symmetric Identification
When selected as an Identity-Choice, the immediately following
Identification field contains an unstructured Variable Precision
Integer. Valid Identifications and symmetric secret-keys are
preconfigured by the parties.
There is no required format or content for the Identification value.
The value may be a number or string of any kind. See "Use of
Identification and Secrets" for details.
The symmetric secret-key (as specified) is selected based on the
contents of the Identification field. All implementations MUST
support at least 62 bytes. The selected symmetric secret-key SHOULD
provide at least 64-bits of cryptographic strength.
As described in "Identity Verification", the Verification field value
is the MD5 [RFC-1321] hash over the concatenation of:
MD5( key, keyfill, data, datafill, key, md5fill )
where the key is the computed verification-key.
The keyfill and datafill use the same pad-with-length technique
defined for md5fill. This padding and length is implicit, and does
not appear in the datagram.
The resulting Verification field is a 128-bit Variable Precision
Integer (18 bytes including Size). When used in calculations, the
Verification data includes both the Size and Value fields.
For both "Identity Verification" and "Validity Verification", the
verification-key is the MD5 [RFC-1321] hash of the following
concatenated values:
+ the symmetric secret-key,
+ the computed shared-secret.
For "Session-Key Computation", the symmetric secret-key is used
directly as the generation-key.
Regardless of the internal representation of the symmetric secret-
key, when used in calculations it is in the same form as the Value
part of a Variable Precision Integer:
- most significant byte first.
- bits used are right justified within byte boundaries.
- any unused bits are in the most significant byte.
- unused bits are zero filled.
The symmetric secret-key does not include a Size field.
13.4.2. Authentication
May be selected as an AH or ESP Attribute-Choice, pursuant to [RFC-
1828] et sequitur. The selected Exchange-Scheme SHOULD provide at
least 64-bits of cryptographic strength.
As described in "Session-Key Computation", the most significant 384-
bits (48 bytes) of the Key-Generation-Function iterations are used
for the key.
Profile:
When negotiated with Photuris, the transform differs slightly from
[RFC-1828].
The form of the authenticated message is:
MD5( key, keyfill, datagram, datafill, key, md5fill )
where the key is the SPI session-key.
The additional datafill protects against the (impractical) attack
described in [PO96]. The keyfill and datafill use the same pad-
with-length technique defined for md5fill. This padding and
length is implicit, and does not appear in the datagram.
13.5. Organizational
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute 255
Length >= 4
When the Length is four, no Value(s) field is
present.
OUI 3 bytes. The vendor's Organizationally Unique
Identifier, assigned by IEEE 802 or IANA (see [RFC-
1700] for contact details). The bits within the
byte are in canonical order, and the most
significant byte is transmitted first.
Kind 1 byte. Indicates a sub-type for the OUI. There is
no standardization for this field. Each OUI
implements its own values.
Value(s) 0 or more bytes. The details are implementation
specific.
Some implementors might not need nor want to publish their
proprietary algorithms and attributes. This OUI mechanism is
available to specify these without encumbering the authors with
proprietary number requests.
A. Automaton
An example automaton is provided to illustrate the operation of the
protocol. It is incomplete and non-deterministic; many of the
Good/Bad semantic decisions are policy-based or too difficult to
represent in tabular form. Where conflicts appear between this
example and the text, the text takes precedence.
The finite-state automaton is defined by events, actions and state
transitions. Events include reception of external commands such as
expiration of a timer, and reception of datagrams from a peer.
Actions include the starting of timers and transmission of datagrams
to the peer.
Events
DU13 = Communication Administratively Prohibited
SF0 = Bad SPI
SF4 = Need Authentication
SF5 = Need Authorization
WC = Want Confidentiality
RCQ+ = Receive Cookie_Request (Good)
RCQ- = Receive Cookie_Request (Bad)
RCR+ = Receive Cookie_Response (Good)
RCR- = Receive Cookie_Response (Bad)
RVQ+ = Receive Value_Request (Good)
RVQ- = Receive Value_Request (Bad)
RVR+ = Receive Value_Response (Good)
RVR- = Receive Value_Response (Bad)
RIQ+ = Receive Identity_Request (Good)
RIQ- = Receive Identity_Request (Bad)
RIR+ = Receive Identity_Response (Good)
RIR- = Receive Identity_Response (Bad)
RUN+ = Receive SPI_Needed (Good)
RUN- = Receive SPI_Needed (Bad)
RUM+ = Receive SPI_Update (Good)
RUM- = Receive SPI_Update (Bad)
RBC = Receive Bad Cookie
RRL = Receive Resource Limit
RVF = Receive Verification Failure
RMR = Receive Message Reject
TO+ = Timeout with counter > 0
TO- = Timeout with counter expired
UTO = Update TimeOut
XTO = Exchange TimeOut
Actions
scq = Send Cookie_Request
scr = Send Cookie_Response
svq = Send Value_Request
svr = Send Value_Response
siq = Send Identity_Request
sir = Send Identity_Response
sum = Send SPI_Update
se* = Send error message (see text)
sbc = Send Bad Cookie
srl = Send Resource Limit
svf = Send Verification Failure
brto = Backoff Retransmission TimeOut
buto = Backoff Update TimeOut
rto = Set Retransmission TimeOut
uto = Set Update TimeOut
xto = Set Exchange TimeOut
log = log operator message
A.1. State Transition Table
States are indicated horizontally, and events are read vertically.
State transitions and actions are represented in the form
action/new-state. Multiple actions are separated by commas, and may
continue on succeeding lines as space requires; multiple actions may
be implemented in any convenient order. The state may be followed by
a letter, which indicates an explanatory footnote. The dash ('-')
indicates an illegal transition.
Initiator
| 0 1 2 3 4
| Initial Cookie CookieBad Value ValueBad
------+--------------------------------------------------
DU13 |rto,scq/1 rto,scq/1 rto,scq/1 3 4
SF0 |rto,scq/1 1 2 3 4
SF4 |rto,scq/1 1 2 3 4
SF5 |rto,scq/1 1 2 3 4
WC |rto,scq/1 1 2 3 4
|
RCR+ | - rto,svq/3 rto,svq/3 3 4
RCR- | 0 1 2 3 4
RVR+ | - - - rto,siq/5 rto,siq/5
RVR- | 0 1 2 3 4
RIR+ | - - - - -
RIR- | 0 1 2 3 4
|
RUN+ | - - - - -
RUN- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
RUM+ | - - - - -
RUM- | sbc/0 sbc/1 sbc/2 sbc/3 sbc/4
|
RBC | - - - 4 4
RRL | - brto/2 brto/2 brto/4 brto/4
RVF | - - - - -
RMR | - - - - -
|
TO+ | - scq/1 scq/2 svq/3 svq/4
TO- | - 0 scq/1 0 scq/1
UTO | - - - - -
XTO | - 0 0 0 0
Initiator
| 5 6 8
|Identity IdentityBad Update
------+-----------------------------
DU13 | 5 6 8
SF0 | 5 6 rto,scq/1
SF4 | 5 6 rto,scq/1
SF5 | 5 6 rto,scq/1
WC | 5 6 sun/8
|
RCR+ | 5 6 8
RCR- | 5 6 8
RVR+ | 5 6 8
RVR- | 5 6 8
RIR+ | uto/8 uto/8 8
RIR- | svf/5 svf/6 8
|
RUN+ | - - sum/8
RUN- | sbc/5 sbc/6 se*/8
RUM+ | - - 8
RUM- | sbc/5 sbc/6 se*/8
|
RBC | 6 6 rto,scq/1
RRL | 5 6 buto/8
RVF | log/5 log/6 log/8
RMR | log/5 log/6 log/8
|
TO+ | sim/5 sim/6 -
TO- | 0 scq/1 -
UTO | - - sum/8
XTO | 0 0 0
Responder
| 0 7 8
| Initial Ready Update
------+-----------------------------
WC | - 7 sun/8
|
RCQ+ | scr/0 scr/7 scr/8
RCQ- | srl/0 srl/7 srl/8
RVQ+ |xto,svr/7 svr/7 svr/8
RVQ- | sbc/0 sbc/7 sbc/8
RIQ+ | - uto,sir/8 sir/8
RIQ- | sbc/0 se*/7 se*/8
|
RUN+ | - - sum/8
RUN- | sbc/0 sbc/7 se*/8
RUM+ | - - 8
RUM- | sbc/0 sbc/7 se*/8
|
RBC | - 7 rto,scq/1
RRL | - - buto/8
RVF | - - log/8
RMR | - - log/8
|
UTO | - - sum/8
XTO | - 0 0
A.2. States
Following is a more detailed description of each automaton state.
The "Bad" version of a state is to indicate that the Bad_Cookie or
Resource_Limit message has been received.
A.2.1. Initial
The Initial state is fictional, in that there is no state between the
parties.
A.2.2. Cookie
In the Cookie state, the Initiator has sent a Cookie_Request, and is
waiting for a Cookie_Response. Both the Restart and Exchange timers
are running.
Note that the Responder has no Cookie state.
A.2.3. Value
In the Value state, the Initiator has sent its Exchange-Value, and is
waiting for an Identity_Message. Both the Restart and Exchange
timers are running.
A.2.4. Identity
In the Identity state, the Initiator has sent an Identity_Request,
and is waiting for an Identity_Response in reply. Both the Restart
and Exchange timers are running.
A.2.5. Ready
In the Ready state, the Responder has sent its Exchange-Value, and is
waiting for an Identity_Message. The Exchange timer is running.
A.2.6. Update
In the Update state, each party has concluded the Photuris exchange,
and is unilaterally updating expiring SPIs until the Exchange
LifeTime expires. Both the Update and Exchange timers are running.
B. Use of Identification and Secrets
Implementation of the base protocol requires support for operator
configuration of participant identities and associated symmetric
secret-keys.
The form of the Identification and Secret fields is not constrained
to be a readable string. In addition to a simpler quoted string
configuration, an implementation MUST allow configuration of an
arbitrary stream of bytes.
B.1. Identification
Typically, the Identification is a user name, a site name, a Fully
Qualified Domain Name, or an email address which contains a user name
and a domain name. Examples include:
user
node.site.
user@node.site.
rcmd@node.site.
"Mundane Name" <user@node.site>
There is no requirement that the domain name match any of the
particular IP addresses in use by the parties.
B.2. Group Identity With Group Secret
A simple configuration approach could use a single Identity and
Secret, distributed to all the participants in the trusted group.
This might be appropriate between routers under a single
administration comprising a Virtual Private Network over the
Internet.
Nota Bene:
The passwords used in these examples do not meet the "MD5-IPMAC
Symmetric Identification" recommendation for at least 64-bits of
cryptographic strength.
The administrator configures each router with the same username and
password:
identity local "Tiny VPN 1995 November" "abracadabra"
identity remote "Tiny VPN 1995 November" "abracadabra"
When the Initiator sends its Identity_Request, the SPI Owner
Identification field is "Tiny VPN 1995 November" and the SPI Owner
secret-key is "abracadabra".
When the Responder sends its Identity_Response, the SPI Owner
Identification field is "Tiny VPN 1995 November" and the SPI Owner
secret-key is "abracadabra". The SPI User Identification is "Tiny
VPN 1995 November" (taken from the request), and the SPI User
secret-key is "abracadabra".
Note that even in the face of implementations with very poor random
number generation yielding the same random numbers for both parties
at every step, and with this completely identical configuration, the
addition of the SPI User Verification field in the response
calculation is highly likely to produce a different Verification
value (see "Identity Verification"). In turn, the different
Verification values affect the calculation of SPI session-keys that
are highly likely to be different in each direction (see "Session-Key
Computation").
B.3. Multiple Identities With Group Secrets
A more robust configuration approach could use a separate Identity
and Secret for each party, distributed to the participants in the
trusted group. This might be appropriate for authenticated firewall
traversal.
An administrator has one or more networks, and a number of mobile
users. It is desirable to restrict access to authorized external
users. The example boundary router is 10.0.0.1.
The administrator gives each user a different username and password,
together with a group username and password for the router.
The administrator configures (in part):
identity local "199511@router.site" "FalDaRah"
identity remote "Happy_Wanderer@router.site" "FalDaRee"
Each mobile user adds commands to tunnel and authenticate.
route addprivate 10.0.0.0/8 tunnel 10.0.0.1
secure 10.0.0.1 authenticate-only
identity local "Happy_Wanderer@router.site" "FalDaRee"
identity remote "199511@router.site" "FalDaRah"
identity remote "199512@router.site" "FalDaHaHaHaHaHaHa"
When the mobile Initiator sends its Identity_Request, the SPI Owner
Identification field is "Happy_Wanderer@router.site" and the SPI
Owner secret-key is "FalDaRee".
When the firewall Responder sends its Identity_Response, the SPI
Owner Identification field is "199511@router.site" and the SPI Owner
secret-key is "FalDaRah". The SPI User Identification field is
"Happy_Wanderer@router.site" (taken from the request), and the SPI
User secret-key is "FalDaRee".
In this example, the mobile user is already prepared for a monthly
password changeover, where the router might identify itself as
"199512@router.site".
B.4. Multiple Identities With Multiple Secrets
Greater security might be achieved through configuration of a pair of
secrets between each party. As before, one secret is used for
initial contact to any member of the group, but another secret is
used between specific parties. Compromise of one secret or pair of
secrets does not affect any other member of the group. This might be
appropriate between the routers forming a boundary between
cooperating Virtual Private Networks that establish local policy for
each VPN member access.
One administrator configures:
identity local "Apple" "all for one"
identity local "Apple-Baker" "Apple to Baker" "Baker"
identity remote "Baker" "one for all"
identity remote "Baker-Apple" "Baker to Apple"
Another configures:
identity local "Baker" "one for all"
identity local "Baker-Apple" "Baker to Apple" "Apple"
identity remote "Apple" "all for one"
identity remote "Apple-Baker" "Apple to Baker"
When the Initiator sends its Identity_Request, the SPI Owner
Identification field is "Apple" and the SPI Owner secret-key is "all
for one".
When the Responder sends its Identity_Response, finding that the
special pairing exists for "Apple" (in this example, indicated by a
third field), the SPI Owner Identification field is "Baker-Apple" and
the SPI Owner secret-key is "Baker to Apple". The SPI User
Identification is "Apple" (taken from the request), and the SPI User
secret-key is "all for one".
Operational Considerations
The specification provides only a few configurable parameters, with
defaults that should satisfy most situations.
Retransmissions
Default: 3.
Initial Retransmission TimeOut (IRTO)
Default: 5 seconds.
Exchange TimeOut (ETO)
Default: 30 seconds. Minimum: Retransmissions * IRTO.
Exchange LifeTime (ELT)
Default: 30 minutes. Minimum: 2 * ETO.
SPI LifeTime (SPILT)
Default: 5 minutes. Minimum: 3 * ETO.
Each party configures a list of known identities and symmetric
secret-keys.
In addition, each party configures local policy that determines what
access (if any) is granted to the holder of a particular identity.
For example, the party might allow anonymous FTP, but prohibit
Telnet. Such considerations are outside the scope of this document.
Security Considerations
Photuris was based on currently available tools, by experienced
network protocol designers with an interest in cryptography, rather
than by cryptographers with an interest in network protocols. This
specification is intended to be readily implementable without
requiring an extensive background in cryptology.
Therefore, only minimal background cryptologic discussion and
rationale is included in this document. Although some review has
been provided by the general cryptologic community, it is anticipated
that design decisions and tradeoffs will be thoroughly analysed in
subsequent dissertations and debated for many years to come.
Cryptologic details are reserved for separate documents that may be
more readily and timely updated with new analysis.
History
The initial specification of Photuris, now called version 1 (December
1994 to March 1995), was based on a short list of design
requirements, and simple experimental code by Phil Karn. Only one
modular exponentiation form was used, with a single byte index of
pre-specified group parameters. The transform attributes were
selected during the public value exchange. Party privacy was
protected in the identification signature exchange with standard ESP
transforms.
Upon submission for review by the IP Security Working Group, a large
number of features were demanded. A mere 254 future group choices
were not deemed enough; it was expanded to two bytes (and renamed
schemes), and was expanded again to carry variable parameters. The
transform attributes were made variable length to accomodate optional
parameters. Every other possible parameter was made negotiable.
Some participants were unable to switch modes on the UDP sockets to
use standard ESP transforms for only some messages, and party privacy
was integrated into the protocol. The message headers were
reorganized, and selection of transform attributes was delayed until
the identification exchange. An additional update message phase was
added.
Version 2 (July 1995 to December 1995) specification stability was
achieved in November 1995 by moving most parameters into separate
documents for later discussion, and leaving only a few mandatory
features in the base specification. Within a month, multiple
interoperable implementations were produced.
Unfortunately, in a fit of demagoguery, the IP Security Working Group
decided in a straw poll to remove party privacy protection, and the
Working Group chair terminated the meeting without allowing further
discussion. Because the identification exchange messages required
privacy to function correctly, the messages were reorganized again.
Party privacy and other optional schemes were split into a separate
document.
The implementors established a separate discussion group. Version 3
(April 1996 to June 1997) enjoyed a long period of specification
stability and multiple implementations on half a dozen platforms.
Meanwhile, the IP Security Working Group has developed a competing
specification with large numbers of negotiable parameters. Also, the
PPP Extensions Working Group has deployed link security transforms.
Version 4 (July 1997 onward) attempts to maintain a semblance of
interface compatibility with these other efforts. Minor changes are
specified in transform padding format and key generation. More than
one value is permitted per scheme, giving greater latitude in choice
for future extensions. The opportunity is taken to return party
privacy to the base document, and make small semantic changes in
automated updates and error recovery. All ESP transform attributes
are moved to separate documents, to (hopefully) avoid future
incompatible changes to the base document.
Acknowledgements
Thou shalt make no law restricting the size of integers that may
be multiplied together, nor the number of times that an integer
may be multiplied by itself, nor the modulus by which an integer
may be reduced. [Prime Commandment]
Phil Karn was principally responsible for the design of the protocol
phases, particularly the "cookie" anti-clogging defense, developed
the initial testing implementation, and provided much of the design
rationale text (now removed to a separate document).
William Simpson was responsible for the packet formats and
attributes, additional message types, editing and formatting. All
such mistakes are his responsibility.
This protocol was later discovered to have many elements in common
with the Station-To-Station authentication protocol [DOW92].
Angelos Keromytis developed the first completely independent
implementation (circa October 1995). Also, he suggested the cookie
exchange rate limitation counter.
Paul C van Oorschot suggested signing both the public exponents and
the shared-secret, to provide an authentication-only version of
identity verification. Also, he provided text regarding moduli,
generator, and exponent selection (now removed to a separate
document).
Hilarie Orman suggested adding secret "nonces" to session-key
generation for asymmetric public/private-key identity methods (now
removed to a separate document), and provided extensive review of the
protocol details.
Bart Preneel and Paul C van Oorschot in [PO96] recommended padding
between the data and trailing key when hashing for authentication.
Niels Provos developed another independent implementation (circa May
1997), ported to AIX, Linux, OpenBSD, and Solaris. Also, he made
suggestions regarding automated update, and listing multiple moduli
per scheme.
Bill Sommerfeld suggested including the authentication symmetric
secret-keys in the session-key generation, and using the Cookie
values on successive exchanges to provide bi-directional user-
oriented keying (now removed to a separate document).
Oliver Spatscheck developed the second independent implementation
(circa December 1995) for the Xkernel.
International interoperability testing between early implementors
provided the impetus for many of the implementation notes herein, and
numerous refinements in the semantics of the protocol messages.
Randall Atkinson, Steven Bellovin, Wataru Hamada, James Hughes, Brian
LaMacchia, Cheryl Madson, Lewis McCarthy, Perry Metzger, Bob Quinn,
Ron Rivest, Rich Schroeppel, and Norman Shulman provided useful
critiques of earlier versions of this document.
Special thanks to the Center for Information Technology Integration
(CITI) for providing computing resources.
References
[BGMW93] E. Brickell, D. Gordon, K. McCurley, and D. Wilson, "Fast
Exponentiation with Precomputation (Extended Abstract)",
Advances in Cryptology -- Eurocrypt '92, Lecture Notes in
Computer Science 658 (1993), Springer-Verlag, 200-207.
Also U.S. Patent #5,299,262, E.F. Brickell, D.M. Gordon,
K.S. McCurley, "Method for exponentiating in
cryptographic systems", 29 Mar 1994.
[DH76] Diffie, W., and Hellman, H.E., "New Directions in
Cryptography", IEEE Transactions on Information Theory, v
IT-22 n 6 pp 644-654, November 1976.
[DOW92] Whitfield Diffie, Paul C van Oorshot, and Michael J
Wiener, "Authentication and Authenticated Key Exchanges",
Designs, Codes and Cryptography, v 2 pp 107-125, Kluwer
Academic Publishers, 1992.
[Firefly] "Photuris" is the latin name for the firefly. "Firefly"
is in turn the name for the USA National Security
Administration's (classified) key exchange protocol for
the STU-III secure telephone. Informed speculation has
it that Firefly is based on very similar design
principles.
[LL94] Lim, C.H., Lee, P.J., "More flexible exponentiation with
precomputation", Advances in Cryptology -- Crypto '94,
Lecture Notes in Computer Science 839 (1994), Springer-
Verlag, pages 95-107.
[Prime Commandment]
A derivation of an apocryphal quote from the usenet list
sci.crypt.
[PO96] Bart Preneel, and Paul C van Oorshot, "On the security of
two MAC algorithms", Advances in Cryptology -- Eurocrypt
'96, Lecture Notes in Computer Science 1070 (May 1996),
Springer-Verlag, pages 19-32.
[RFC-768] Postel, J., "User Datagram Protocol", STD 6,
USC/Information Sciences Institute, August 1980.
[RFC-791] Postel, J., "Internet Protocol", STD 5, USC/Information
Sciences Institute, September 1981.
[RFC-1321] Rivest, R., "The MD5 Message-Digest Algorithm", MIT
Laboratory for Computer Science, April 1992.
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", Cisco Systems, June 1995.
[RFC-1828] Metzger, P., Simpson, W., "IP Authentication using Keyed
MD5", July 1995.
[RFC-1829] Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC
Transform", July 1995.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, Harvard University, March
1997.
[RFC-2521] Karn, P., and Simpson, W., "ICMP Security Failures
Messages", March 1999.
[Rooij94] P. de Rooij, "Efficient exponentiation using
precomputation and vector addition chains", Advances in
Cryptology -- Eurocrypt '94, Lecture Notes in Computer
Science, Springer-Verlag, pages 403-415.
[Schneier95]
Schneier, B., "Applied Cryptography Second Edition", John
Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7.
Contacts
Comments about this document should be discussed on the
photuris@adk.gr mailing list.
Questions about this document can also be directed to:
Phil Karn
Qualcomm, Inc.
6455 Lusk Blvd.
San Diego, California 92121-2779
karn@qualcomm.com
karn@unix.ka9q.ampr.org (preferred)
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Full Copyright Statement
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn
and William Allen Simpson (1994-1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards (in which case the procedures for
copyrights defined in the Internet Standards process must be
followed), or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY 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.