Internet Engineering Task Force G. Montenegro
INTERNET DRAFT C. Castelluccia
April, 2001
Statistically Unique and Cryptographically Verifiable Identifiers
and Addresses
draft-montenegro-sucv-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC 2026.
Comments should be submitted to the HIP and Mobile IP mailing lists
at hipsec@mail.freeswan.org and mobile-ip@sunroof.eng.sun.com,
respectively.
Distribution of this memo is unlimited.
This document is an Internet-Draft. 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.
Abstract
This document addresses the identifier ownership problem. It
does so by using characteristics of Statistic Uniqueness and
Cryptographic Verifiability (SUCV) of certain entities which
this document calls SUCV Identifiers (SUCV ID's). This note
also proposes using these SUCV characteristics in related
entities called SUCV Addresses in order to severely limit
certain classes of denial of service attacks and hijacking
attacks. SUCV addresses are particularly applicable to solve the
'address ownership' problem that severely undermines confidence
in mechanisms like Binding Updates in Mobile IP for IPv6.
Montenegro, Castelluccia Expires October, 2001 [Page 1]
INTERNET DRAFT SUCV Addresses April 2001
Table of Contents
1.0 Introduction .................................................. 3
2.0 Related Issues ................................................ 3
2.1 Address Ownership .......................................... 3
2.2 Purpose Built Keys [PBK] ................................... 4
3.0 Overview of the Proposal ...................................... 4
4.0 Statistical Uniqueness and Cryptographic Verifiability
(SUCV) ............................................................ 5
4.1 SUCV ID's .................................................. 6
4.2 SUCV ID's versus Addresses ................................. 7
4.3 SUCV Addresses ............................................. 8
4.4 Hash ID Size Considerations ................................ 8
5.0 HIP IPv6 Accomodation Mode .................................... 9
6.0 Use of SUCV Addresses for Mobile IPv6 ......................... 11
6.1 Protocol Overview .......................................... 12
7.0 Security Considerations ....................................... 14
8.0 Conclusions ................................................... 14
References ........................................................ 14
Authors' addresses ................................................ 15
Montenegro, Castelluccia Expires October, 2001 [Page 2]
INTERNET DRAFT SUCV Addresses April 2001
1.0 Introduction
This document addresses the identifier ownership problem
[ADDROWN] by using characteristics of Statistic Uniqueness and
Cryptographic Verifiability (SUCV) of certain entities which
this document calls SUCV Identifiers (SUCV ID's). This note
also proposes using these SUCV characteristics in related
entities called SUCV Addresses in order to severely limit
certain classes of denial of service attacks and hijacking
attacks. SUCV addresses can solve the 'address ownership'
problem that severely undermines confidence in mechanisms like
Binding Updates in Mobile IP for IPv6.
2.0 Related Issues
2.1 Address Ownership
[ADDROWN] argues that there is a fundamental problem in handling
operations like Binding Updates (BU's) in Mobile IP for IPv6
[MIPv6], source routing, etc) that allows hosts to modify how
other hosts route packets to a certain destination. The problem
is that these operations can be misused by rogue nodes to
redirect traffic away from its legitimate destination.
Authentication does not solve this problem. Even if a node
unequivocally identifies itself, this has no bearing on its
rights to modify how packets to any given address are routed.
This is true even if its packets currently seem to emanate from
the address in question. This last point is obvious if one
considers DHCP leased addresses. It is imperative not to allow
any node to redirect traffic for a DHCP address for which it
held a valid lease previously. This would allow it to hijack
traffic meant for the current valid user of the address in
question. Hence, protection against hijacking of valid addresses
requires cryptographic authorization for operations that modify
routing (BU's, source routing, etc). One way to show
authorization is by showing that the requesting node owns the
address for which routing information is being altered. Quoting
[ADDROWN]:
Currently there exists no specified mechanism for proving
address ownership in Internet-wide scale.
Montenegro, Castelluccia Expires October, 2001 [Page 3]
INTERNET DRAFT SUCV Addresses April 2001
2.2 Purpose Built Keys [PBK]
Purpose built keys [PBK] have been proposed as a foundation for
solving scaling and cost concerns associated with some uses of
BU's [MIPv6]. It has also been suggested that such keys [PBK]
can solve the authorization problem that is at the heart of the
address ownership issue.
The proposal is succintly to:
1. Generate a temporary public/private pair
2. Generate an EID = hash(public component)
a. the initiator sends EID to responder along with initial
protocol exchanges.
b. the initiator sends public component to responder along
with subsequent exchanges.
3. The initiator sends the BU and its EID signed with its
private key to the responder.
Notice that the exchange at step 2 must be secure in order to
avoid intruder-in-the-middle attacks, but it is an improvement
over cookies.
Several problems linger:
1. This does NOT really address the address ownership problem of
any publicly routable addresses
2. It is not specified how the EID and public component of the
PK are sent by the initiator to the responder
3. Preventing or limiting hijacking and intruder-in-the-middle
attacks depend on this sequence if not clearly specified.
By the time the issues are worked out, [PBK] will look very
similar to an existing proposal [HIPARCH]. Because of this, it
may be simpler to base a solution on HIP.
3.0 Overview of the Proposal
We assume that we have a network in which the nodes inherently
distrust each other, and in which a global or centralized PKI
(Public Key Infrastructure) or KDC (Key Distribution Center) is
Montenegro, Castelluccia Expires October, 2001 [Page 4]
INTERNET DRAFT SUCV Addresses April 2001
not available.
The goal is to arrive at some fundamental assumptions about
trust on top of which one can build some useful peer-to-peer
communication using opportunistic security.
But in such a network, is there a default rule we can follow
safely? We posit this is it:
Default Trust Rule:
Redirect operations are allowed only with addresses which
are bound (via a cryptographically sound binding) to the
requesting entity.
The above rule (to be refined later) constitutes the only rule
that operates by default, allowing any other more dangerous
operation only if authorized by strong cryptographic
mechanisms.
Furthermore, we suggest it be based on HIP for the following
reasons:
- HIP provides the types of identifiers required by the above
rule.
- The HIP protocol handshake [HIPPROT] is a foundation for a
very solid sequence resistant to denial-of-service attacks.
Nevertheless, this document proposes a specific use or 'profile'
of HIP as applied to environments without DNS (particularly
secure DNS), a centralized PKI, or a Key Distribution Center.
Rather, we favor the opportunistic mode in HIP [HIPIMPL], and
adapt and apply it to Mobile IPv6 (as detailed below). In order
not to hinder deployment, a primary consideration has been to
minimize the modifications of existing protocols and network
support.
Furthermore, at the end of this document we note that there are
other areas that can benefit from similar adaptations of HIP's
opportunistic mode. Their details, however, are left for further
exploration.
4.0 Statistical Uniqueness and Cryptographic Verifiability (SUCV)
In the absence of a third party, how does a principal prove
ownership of its identity to a peer?
Montenegro, Castelluccia Expires October, 2001 [Page 5]
INTERNET DRAFT SUCV Addresses April 2001
Notice that usual owner verification relies on a third party to
provide this function.
In this proposal, the principal self-generates a private/public
key pair. It uses the public key as its identity and proves its
ownership by signing it with its private key. The recipient
verifies the signature, and, consequently, the ownership of the
identity.
4.1 SUCV ID's
It is much more practical for protocols to use fixed length
identifiers (representations of identities). Because of this, we
do not use the public key itself as the identifier, but its hash
(as in HIP).
These identifiers have a strong cryptographic binding with their
public components (of their private-public keys). This is
exactly the purpose that certificates have. Let's call them
Statistically Unique Cryptographically Verifiable ID's, or SUCV
ID's.
Because of this, once a CN obtains information about one of
these identifiers, it has a strong cryptographic assurance about
which entity created it. Not only that, it knows that this
identifier is owned and used exclusively by only one node in the
universe: its peer in the current exchange. Thus, it is safe to
allow that peer to effect changes (via BU's, for example) on how
this address or identifier is routed to. Notice that with
publically routable addresses, this assurance is much harder to
arrive at, given that the address may be 'loaned' to (not owned
by) the peer in question, perhaps thanks to the good service of
a DHCP server.
Despite the fact that currently there is no way to prove address
ownership in the Internet, these considerations lead to the
following fundamental assumption:
Default Trust Rule
Redirect operations are only allowed to affect routing for
entities which have the SUCV property.
The above constitutes perhaps the only rule that operates by
default, allowing any other more dangerous operation only if
authorized by strong cryptographic mechanisms
Montenegro, Castelluccia Expires October, 2001 [Page 6]
INTERNET DRAFT SUCV Addresses April 2001
4.2 SUCV ID's versus Addresses
What should one use: pure identifiers with no routing
significance or addresses?
For example, in the Mobile IPv6 case, a node starts using its
home address, and issues binding updates as it moves.
With a home address that is not an SUCV ID it is never evident
to the CN that whoever was sitting on this address actually owns
it. At the very most, the mobile node can prove that at some
point it was sitting on a certain address, and later it can
prove it is still the same node, but now sitting on another
address.
But it cannot prove ownership. Ignoring this subtle distinction
leads to DOS and hijacking attacks.
Problems may also arise because of honest mistakes in
configuration. For example, say node A was originally sitting on
CoA, and then moved on to CoA'. Suppose it then asks its CN's
to redirect traffic to CoA'. In the meanwhile, the original
CoA may have been assigned to another node B, perhaps by the
DHCP server that rightfully 'owns' that address. The result is
that now traffic meant for B has been redirected to A at its new
location.
Relying on ingress filtering may limit the risk, but
essentially, the only way for a node to prove ownership of an
identifier (in the absence of any other centralized or global
mechanism), is for it to prove that it created this
statistically unique series of bits.
The intent is to use an identifier instead of an address. Using
identifiers that satisfy the SUCV conditions outlined above, it
is possible to gain the tremendous advantage that other nodes
can safely believe the node when it claims ownership of that
identifier. Hence they can safely heed its redirects when it
says that it is now available at some different CoA (and later
at another). Furthermore, you do not rely on ingress filtering
to limit exposure.
A major advantage to using an address is that the data traffic
need not carry extra information in the packet to guarantee
proper delivery by routing. Because of this it is advantageous
to create addresses that are both routable and satisfy the SUCV
property: SUCV addresses.
Montenegro, Castelluccia Expires October, 2001 [Page 7]
INTERNET DRAFT SUCV Addresses April 2001
Another advantage to using an SUCV address is that this address
can be registered in the DNS and the host does not have to worry
about communicating securely this identifier to its correspondent
node. The correspondent node will just get it from the DNS.
4.3 SUCV Addresses
In IPv6, addresses that satisfy the SUCV property may be
obtained as follows:
- use the top 64 bits from your routing prefix (as in rfc3041)
- define the bottom 64 bits as an SUCV ID (called the HID or
'hash' ID). Use these 64 bits instead of the 'interface
identifier' in IPv6 [IPV6ADDR].
The resultant 128 bit field is an identifier that is also
routable, avoiding the need for taking extra space in the packet
by sending routing options. Notice that even after moving, it is
possible to reuse the 'HID' portion of the address with the new
network prefix at the new location. Thus it is possible to reuse
the HID with different CoA's.
Nevertheless, by snooping on binding updates, it is possible for
an attacker to learn the original network prefix used by the
home address. This tells an eavesdropper where this home address
began to be used, and to which network it belongs, potentially
important information.
On the other hand, if you use a 'pure' SUCV ID (without any
routing significance), then your packets will always need extra
information somewhere to assure they are routed properly.
Eavesdroppers may still know where that identity is at any
particular point in time. But at least they will not know where
(under what prefix) that identity began to be used.
For further details on SUCV address please refer to section
5.0.
4.4 Hash ID Size Considerations
In SUCV addresses, one of the lower 64 bits is reserved as the
local/universal bit (the 'u' bit), so only 63 bits are actually
usable as a hash.
Suppose the hash function produces an n-bit long output. If we
Montenegro, Castelluccia Expires October, 2001 [Page 8]
INTERNET DRAFT SUCV Addresses April 2001
are trying to find some input which will produce some target
output value y, then since each output is equally likely we
expect to have to try 2^(n-1) possible input values on average.
If we are trying to find a collision, then by the birthday
paradox we would expect that after trying 1.2*2^n/2 possible
input values we would a 50% probability of collision [BIRTH].
So if n=63, you need 1.2*2^31.5 i.e. 3.64*10^9 tries on average
before having a collision. This is acceptable especially if you
consider that this collision is actually harmfull only if the 2
hosts (that collide) are in the same site (i.e. they have the
same network prefix), and have the same correspondent nodes.
This is very unlikely. Additionally, if the collision is not
deliberate the duplicate address detection (DAD) will detect
it.
If an attacker wishes to impersonate a given SUCV address, it
must attempt 2^62 (i.e. approximately 4.8*10^18) tries to find a
public key that hashes to this SUCV address. If the attacker
can do 1 million hashes per second it will need 142,235 years.
If the attacker can hash 1 billion hashes per second it will
still need 142 years
If we consider that the SUCV Addresses are renewed every 24
hours (as suggested in RFC3041), an attacker would then be able
to hash 5.3*.10^13 hashes/second in order to be able to find a
public key that hashes to the SUCV HID of a given host...
Note that the previous analysis only considers the cost of
computing the hash of the public key. Prior to this step, an
attacker must also generate a valid (public, private) key pair.
This is also a very computionally expensive operation.
As a conclusion SUCV addresses as used in this document provide
more than enough security.
5.0 HIP IPv6 Accomodation Mode
Using these ID's or addresses depends on also communicating
safely the SUCV portion, and this, in turn is dependent on the
packet sequencing, etc. These concerns are not addresses at all
in the PBK draft. On the other hand, HIP includes mechanisms and
detailed considerations in this regard (protection against
replay, DOS and MITM attacks). This is why this note proposes
that a solution be drafted based heavily on HIP [HIPARCH,
HIPPROT, HIPIMPL].
Montenegro, Castelluccia Expires October, 2001 [Page 9]
INTERNET DRAFT SUCV Addresses April 2001
To obtain an IPv6 SUCV address, we define a HIT-64 format and
use its lower 64 bits to form the relevant IPv6 addresses (this
constitutes HIP's IPv6 accomodation mode). So, for example, the
HIT-64 is used to form global aggregatable addresses which start
thus [IPV6ADDR]:
Aggregatable Global Unicast Addresses 001
As well as to derive link-local and site-local addresses which
start thus:
Link-Local Unicast Addresses 1111 1110 10
Site-Local Unicast Addresses 1111 1110 11
The HIT-64 format (section 5.2 of [HIPARCH]) is defined as
follows:
- first 64 bits:
- Bit 0 is one
- HAA field (next 63 bits) formed as follows:
- RAA: 23 bits of registered assigning authority assigned
by ICANN (suggested value: 0)
- RI: 40 bits of registered identity assigned
sequentially by the RAA. (suggested value: 0)
- last 64 bits:
- derived from a hash of the host identity
- used as the interface identifier in IPv6 addresses
The IPv6 accomodation mode consists in using a HIT-64 to form an
IPv6 address.
A HIT-64 derived IPv6 Aggregatable Global Unicast Address
(RFC2374) is formed as follows:
- top 64 bits: as per the valid prefix at the link the device is on
- bottom 64 bits: interface identifier obtained by taking the
last 64 bits of the above HIT-64, and setting bit 6 (the
left-most bit is numbered 0) to one. This creates an
interface identifier with universal significance.
From this IPv6 address, other non-global scope addresses are
derived. For example, a node uses the bottom 64 bits to form
the site-local and link-local addresses on the same prefix
(link) as the aggregatable global unicast address
(alternatively, if a non-global address is formed first, it is
used to form the others). Furthermor, if this address is used in
conjuction with Mobile IP for IPv6 [MIPV6], the Home Agent uses
Montenegro, Castelluccia Expires October, 2001 [Page 10]
INTERNET DRAFT SUCV Addresses April 2001
the Prefix Length information within a "home registration"
binding update to form the corresponding link-local and
site-local addresses for the Mobile Node, and defend them for
purposes of Duplicate Address Detection.
Any of the addresses formed as described above constitute SUCV
addresses.
6.0 Use of SUCV Addresses for Mobile IPv6
In Mobile IPv6, a mobile host obtains a new address, a CoA, each
time it moves. It then registers the binding between its home
address and its new CoA with its home agent and correspond
nodes. Correspondent nodes in posession of such a binding can
send packets to the mobile node directly at its current CoA.
Instead, sending packets to the mobile node's home address
implies sub-optimal routing as they first proceed to the mobile
node's home link, where they are intercepted by the home agent
and forwarded to the mobile node's CoA.
However, the correspond nodes MUST get the assurance the home
address actually belongs to the mobile node. Otherwise, an
attacker could send a binding update with a victim's home
address, thus redirecting all the victim's packets.
Additionally, the correspond nodes SHOULD get the assurance that
the CoA actually belongs to the mobile node. Otherwise, any
host could use the address of another victim as its CoA. The
packets that were initially addressed to the first victim will
then be sent to the victim. Depending on how much traffic this
implies, this could be used as a denial-of-service attack.
These attacks can be avoided if, in order to accept and process
a binding update, a correspond host requires a mobile node to
prove ownership of its home address and its CoA. If ownership is
proven, the correspond node has the assurance that the mobile
node is not hijacking some other node's address, and that it is
not directing packets at some other node's one's address.
The solution that we propose is that a mobile node uses the
method describes previously to configure its Home Address and
its CoA (the same HID and public/private key pair is used for
the home address and the CoA).
By verifying the signature and the HID, the correspond host has
the assurance that the mobile host is not using some other
node's home address and CoA.
Montenegro, Castelluccia Expires October, 2001 [Page 11]
INTERNET DRAFT SUCV Addresses April 2001
As described in [MIPPRIV], the use of SUCV Identifier for Mobile
IPv6 is useful when a mobile node wishes to hide its home
address. Indeed the home address can reveal a lot of information
about a mobile node. [MIPPRIV] proposes to use a random
Temporary Mobile Identifier (TMI) in place of the home address.
By using a SUCV ID as a TMI, a mobile node will be able to prove
ownership of the TMI and avoid hijacking attacks.
6.1 Protocol Overview
The following protocol sequence is based on [HIPPROT]. However,
it has been modified for Mobile IPv6 based on the following
considerations:
- the goal is to secure binding updates sent by a mobile node to
an arbitrary correspondent node
- the protocol should not rely on a third party (i.e. a home
agent, mobility anchor point, global PKI, central key
distribution center, etc)
- HIP is used for 'opportunistic security' so there is no
reliance on DNS
- not all nodes need to use SUCV addresses, only those that wish
their binding updates to be heeded (mobile nodes)
- not all nodes need to verify the validity of SUCV addresses,
only those that wish to safely heed binding updates in order
to populate its binding cache
The proposed protocol that a mobile host uses to send a BU to its CN
is the following:
msg1- The MN sends a BU HELLO message (just to initiate the
exchange) to its correspond node. This message
contains a Nonce, N1.
msg2- The CN replies with a message that contains the
following: N1, HIP Cookie request, SPI, Diffie-Hellman
value, ESP transform (list of supported ESP modes).
In order to defend against msg1 storms, a host might
use the same DH value for a period of time. A HIP
cookie request contains a random number I, the hash of
I concatenated with a random value J, and K, the number
of bits that must match as per [HIPPROT].
Montenegro, Castelluccia Expires October, 2001 [Page 12]
INTERNET DRAFT SUCV Addresses April 2001
When the MN receives msg2, it verifies that the nonce
N1 is the same than the one that was sent in the msg1.
It then computes the HIP Cookie reply by finding J and
replies with msg3.
msg3- The MN replies with a message that contains the
following: HIP Cookie reply, Public key,
Diffie-Hellman value, ESP transform (the selected ESP
modes) and BU. This message MUST be signed by the MN
with its private key.
Note that the home address contained in the BU is
either a SUCV Address or a SUCV Identifier. The CoA is
either a SUCV Address or a regular address. By using a
CoA SUCV address, a CN has the assurance the the CoA
belongs to the MN and has not been stolen.
When the CN receives the msg3, it can verify the ownership of
the Home and CoA addresses and authenticate the BU because it is
signed.
The MN and CN can then derive a session key (using the ephemeral
D-H value), and use it in conjunction with IPSec to authenticate
other subsequent BU (if any) as it is done in current MIPv6.
As long as the MN uses the same HID interface identifier for its
CoA, it does not have to prove the CoA ownership and IPSec
authentication mechanism is fine. If for any reason the MN
configures its CoA with a new interface identifier, it MUST
restart the whole protocol (i.e. msg1, msg2, msg3).
This proposal does not require any prerequisite between the MN
and the CN. By using a Home Address SUCV, that is generated by
hashing a public key, and signing message 2 with the
corresponding private key a MN can prove the ownership of its
Home Address.
Because our proposal is heavily based on HIP, it is resistant to
denial-of service attacks. Because our proposal is based on
SUCV Home Address, it is resistant to Man-in the Middle
attacks. An attacker won't be able to redirect the traffic
destined to a particular SUCV Home Address unless it can find a
(public, private) key pair such that the hash of the public
component is equal to the least significant 64 bits in the SUCV
Home Address. This is computationally infeasable (see section
4.4).
Montenegro, Castelluccia Expires October, 2001 [Page 13]
INTERNET DRAFT SUCV Addresses April 2001
7.0 Security Considerations
The technique introduced in this document is meant to increase
the level of security in the Internet.
This document explains the concept of statistical uniqueness and
cryptographic verifiability (SUCV), specially as it applies to
IPv6 addresses in the form of SUCV addresses. The SUCV
characteristics are used to prove address ownership, thus
preventing a class of attacks which exploit this fault in many
types of commands. In particular, commands which alter how an
address is treated by peers or by the routing infrastructure can
be used to launch denial of service attacks or hijacking
attacks. Proving address ownership eliminates these attacks.
However, given that this technique is meant to be used primarily
in the absence of global infrastructures, the possibility of man
in the middle attacks does remain. Nevertheless, since the
protocol used here is based on HIP, these attacks are limited by
the use of cookies and client puzzles.
8.0 Conclusions
The present document focuses on the use of the SUCV property to
enhance the security of exchanges between an arbitrary pair of
peers in the absence of any third party. In particular, we
propose that SUCV addresses be used to solve the issue of
securing binding updates in Mobile IPv6.
Recent micro-mobility management protocols (such as HAWAII or
Cellular IP) propose to use specialized path setup schemes which
install host-based forwarding entries in specific routers to
support intra-domain micro-mobility. In order to avoid trafic
redirection, routers need to verify the ownership of an address
used by a mobile host before adding an entry for that particular
mobile host in its routing table. SUCV addresses or identifiers
also can be very useful for that purpose.
References
[ADDROWN] Pekka Nikander, "An Address Ownership Problem in IPv6",
draft-nikander-ipng-address-ownership-00.txt, February 2001.
[BIRTH] http://www.rsasecurity.com/rsalabs/faq/2-4-6.html
[HIPARCH] Bob Moskowitz, "HIP Architecture,"
draft-ietf-moskowitz-hip-arch-02.txt
Montenegro, Castelluccia Expires October, 2001 [Page 14]
INTERNET DRAFT SUCV Addresses April 2001
[HIPIMPL] Bob Moskowitz, "HIP Implementation,"
draft-moskowitz-hip-impl-01.txt
[HIPPROT] Bob Moskowitz, "Host Identity Payload and Protocol,"
draft-moskowitz-hip-03.txt
[IPV6ADDR] Hinden, Deering, "IPv6 Addressing Architecture,"
draft-ietf-ipngwg-addr-arch-v3-05.txt
[MIPPRIV] Castelluccia, Dupont, "A Simple Privacy Extension for
Mobile IPv6," draft-castelluccia-mobileip-privacy-00.txt,
February 2001.
[MIPV6] C. Perkins, "Mobile IP for IPv6,",
draft-ietf-mobileip-ipv6-13.txt
[PBK] Bradner, Mankin, Schiller, "Purpose Built Keys,"
draft-bradner-pbk-frame-00.txt
[RFC3041] T. Narten, R. Draves "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6," RFC 3041.
[WeakMD5] H. Dobbertin, "Cryptanalysis of MD5 Compress,"
http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
Authors' addresses
Questions about this document may be directed to:
Gabriel Montenegro
Sun Microsystems Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan, FRANCE
Voice: +33 476 18 80 45
E-Mail: gab@sun.com
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
FRANCE
email: claude.castelluccia@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Montenegro, Castelluccia Expires October, 2001 [Page 15]
INTERNET DRAFT SUCV Addresses April 2001
Copyright (c) The Internet Society (2000). 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 DISCLAIMS 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.
Montenegro, Castelluccia Expires October, 2001 [Page 16]