One document matched: draft-zhao-mip6-rr-ext-00.txt
MIP6 Working Group F. Zhao
Internet-Draft S F. Wu
Expires: August 18, 2005 UC Davis
S. Jung
Soongsil University
February 14, 2005
Extensions to Return Routability Test in MIP6
draft-zhao-mip6-rr-ext-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft proposes some extensions to Return Routability Test in
MIP6 to address the privacy issues and enable CN as well as MN to
detect the attack that could compromise the security of MIP6 RO
mechanism.
Zhao, et al. Expires August 18, 2005 [Page 1]
Internet-Draft MIP6 RR Extensions February 2005
Table of Contents
1. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Related Works . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 No infrastructure support . . . . . . . . . . . . . . . . 6
3.2 Pre-existing SA between MN and HA . . . . . . . . . . . . 6
3.3 No pre-existing SA between MN and CN or between HA and
CN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Ingress filtering . . . . . . . . . . . . . . . . . . . . 6
3.5 HA does not have any malicious intention to CN and MN . . 6
3.6 The assumptions of the power of the attacker . . . . . . . 6
4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 The basic RR procedure . . . . . . . . . . . . . . . . . . 8
4.3 Protection of the HoA privacy in the BU message . . . . . 11
4.4 Extending the RR test with a detection mechanism . . . . . 12
4.5 Non-repudiation . . . . . . . . . . . . . . . . . . . . . 14
5. Security consideration . . . . . . . . . . . . . . . . . . . . 15
5.1 The privacy of HoA is protected as much as possible . . . 15
5.2 The disclosure of HoA is postponed as late as possible . . 15
5.3 Supports the fast Binding Updates procedure . . . . . . . 15
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Zhao, et al. Expires August 18, 2005 [Page 2]
Internet-Draft MIP6 RR Extensions February 2005
1. Motivations
The key words 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 [1].
MIP6 adopts Return Routability Test as a lightweight and
infrastructure-less authentication mechanism to achieve a reasonable
level of authentication between MN and CN even without pre-existing
security association. Our motivations to propose some extensions on
the original MIP6 RR test are as follows:
1) Location privacy (We will only focus on the location privacy in
the IP layer in this draft.) attaches more and more attentions
recently; Moreover, RR test could be also used to achieve the
security of NEMO Route Optimization protocol (Although NEMO RO
solution is still under discussion, a potential approach is to enable
MR to register its MNP(s) with CN/CR to achieve the optimal route
just like the procedure of Binding Updates to correspondent nodes in
MIP6.) where the privacy issue, such as MNP (Mobile Network Prefix)
information, becomes even more serious. In this draft, we postpone
the disclosure of HoA as late as possible and use the encryption to
make HoA invisible to the eavesdropper.
In MIP6 RR procedure, HoA is in the cleartext in the HoTi and HoT
messages, thus an eavesdropper can learn that MN is away from the
home network. In every message of the extended RR test, the privacy
of HoA is protected. However, the location privacy of other
messages, such as home BU messages, prefix discovery message and data
message, is out of scope of this draft.
2) In MIP6, an attacker that is able to only eavesdrop the traffic in
the normal IPv6 network can effectively intercept the traffic between
MN and CN, which makes the MIP6 network a little bit less secure than
the normal IPv6 network. For example, an attacker adjacent to a
router on the path between HA and CN can only eavesdrop the traffic
but not intercept the traffic passing by, however by eavesdropping
and launching the RR test, the attacker can successfully intercept
thus take the complete control over the communication between MN and
CN. In this draft we propose a detection mechanism for both CN and
MN to detect any attack that could break the security of MIP6 RO
mechanism.
3) In MIP6, in order to mitigate the attack on the RR test, a timeout
value is maintained. Currently, this value is a few minutes, which
causes a lot of overheads. Also it is unnecessary to keep repeating
the RR test even though there is no attacker around. Thus how to
reduce the signaling overhead is also our concern. The detection
Zhao, et al. Expires August 18, 2005 [Page 3]
Internet-Draft MIP6 RR Extensions February 2005
mechanism enables CN and MN to detect such kind of ôpowerfulö
attacker, thus take the correct responses based on the policy with
requiring the long frequent timeout.
4) It is also our motivation to propose a RR test mechanism that
could be easily extended to RR-test Mobile Network Prefix in NEMO
once NEMO working group is re-chartered to work on the RO problem.
This draft is organized as follows: in Section 2 we briefly review
the related works and then describe the details of our proposal in
Section 3. In Section 4 we present the security analysis.
Zhao, et al. Expires August 18, 2005 [Page 4]
Internet-Draft MIP6 RR Extensions February 2005
2. Related Works
MIP6 protocol [2] adopts RR procudure to enable CN to authenticate
the binding between CoA and HoA of MN in a reasonable level when
there is no pre-exisitng security association between CN and MN. The
rationale and background of this design are documented in [5]. Later
on, a lot of enhancements of MIP6 RO and improvement of the original
RR procedure are proposed [6][7]. Those proposals are based on MIP6
RO; however, NEMO RO has its own security requirements. [8] proposed
the idea of using NPT message to verify the correctness of MNP;
however, it not only generates the amplication effect but also leaves
a hole for an attacker to successfully steal the traffic, which is
found by E. Nordmark firstly to our best knowledgement.
Zhao, et al. Expires August 18, 2005 [Page 5]
Internet-Draft MIP6 RR Extensions February 2005
3. Assumptions
3.1 No infrastructure support
The extended RR test does not require PKI or AAA infrastructure to
assist the authentication procedure and thus avoids the expensive
public key calculation and signaling overhead due to extra message
exchanges.
3.2 Pre-existing SA between MN and HA
We assume that there exists a security association between MN and HA
and integrity and confidentiality of the messages between MN and HA
are protected by this SA.
3.3 No pre-existing SA between MN and CN or between HA and CN
We assume that there is no pre-existing SA between MN and CN or
between HA and CN.
3.4 Ingress filtering
Our proposal does not reply on the ingress filtering, thus we assume
that there is no ingress filtering enforced.
3.5 HA does not have any malicious intention to CN and MN
If HA is malicious, the security of RR procedure in MIP6 is
comprised. For example, a malicious HA can redirect the HoT message
to an attacker so that the attacker can successfully finish the RR
procedure with CN and intercept the traffic to other MN; a malicious
HA can also drop the HoTi or HoT message from or to any MN. In [8],
the same assumption is also implicitly held because otherwise a
malicious HA can forward the NPT messages to the attacker or respond
on behalf of the attacker. Please note that a malicious HA can break
the communication in MIP6 and NEMO when not performing the RO
mechanisms. And this case falls into the category that the attacker
has full control (interception) over the path between CN and HA.
Thus we believe this is a valid assumption.
3.6 The assumptions of the power of the attacker
MIP6 RR procedure limits the attack to be successful only when the
attacker is in some certain locations. In other words, the security
of RR procedure is comprised when the attacker has the following
powers: The attacker is able to access (intercept or eavesdrop) the
message exchanges on the MN-CN path and HA-CN path. To do so, the
attacker could move from one path to the other; or it could have a
Zhao, et al. Expires August 18, 2005 [Page 6]
Internet-Draft MIP6 RR Extensions February 2005
conspirator on the other path; or these two paths are kind of
overlapping with each other and the attacker is attached to the
common part of these two paths.
We assume that the attacker has no ability to access the message on
both paths in a certain time period and when it attaches itself to
either path, the attacker has at most the partial control over the
path to eavesdrop the traffic passing by.
Zhao, et al. Expires August 18, 2005 [Page 7]
Internet-Draft MIP6 RR Extensions February 2005
4. Proposal
Our discussions are based on the following simplified MIP6 scenario:
CN is a fixed node in the Internet. It is possible to use the
reverse tunneling when CN is also a mobile node just like in [5], but
we will address this case in details in the later version of this
draft due to the constrained time frame.
4.1 Notations
Besides those used in [2], we also defines the following notations:
RN: a random number generated and managed by MN with the fixed
length. In other words, the length of RN is pre-configured and well
known by MN, HA, CN and/or any other node.
HV: the output of a secure hash function, such as SHA1.
4.2 The basic RR procedure
When MN moves to a new location other than its home network, MN may
decide to launch the RR procedure with remote node, CN, based on its
policy that is not within the scope of this draft.
HoTi:
Source IP address: HoA
Destination IP address: CN
{home_init_cookie | RN}
MN generates the HoTi message and forwards it into the reverse MN-HA
tunnel, thus the confidentiality and secrecy of HoTi are protected by
SA between MN and HA.
After HA receives the HoTi message, HA can verify that HoA belongs to
this home network. When the verification is successful, HA will
generate the following HoTi_HA message and forward it to CN. Note
that HoTi_HA message can use the same MH type value for HoTi message
because all these messages are transparent to CN. We give the
different names to these two messages in order to highlight their
differences.
HoTi_HA:
Source IP address: HA
Zhao, et al. Expires August 18, 2005 [Page 8]
Internet-Draft MIP6 RR Extensions February 2005
Destination IP address: CN
{home_init_ha_cookie | HV} where HV = SHA1 (HoA | RN)
Please note that HA replaces the source IP address, HoA, with its own
IP address, HA and replaces home_init_cookie with
home_init_ha_cookie. home_init_ha_cookie can be generated by
AES(Kha, HoA | home_init_cookie) or at random and HA establishes a
table storing home_init_ha_cookie, HoA and home_init_cookie in one
entry where home_init_ha_cookie is a primary key. Please note that
HA generates home_init_ha_cookie by encrypting the concatenation of
HoA and home_init_cookie after it verifies the received packet, it
does not risk the Denial-of-Service attack at this stage and saves
the memory cost. However, it may become a serious threat when HA
later decrypts the message to restore HoA and home_init_cookie even
though HA may verify the home_init_ha_cookie firstly, so HA can avoid
the DoS attack at the cost of memory.
After CN receives HoTi_HA message, CN generates the HoT message.
Note that the formula to generate home_token takes HV as input as
well.
HoT:
Source IP address: CN
Destination IP address: HA
{home_init_ha_cookie | home_token | home_nonce_index}
home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0)))
After HA receives HoT message, HA looks up the table with
home_init_ha_cookie as the primary key or decrypts the
home_init_ha_cookie. After successfully achieving HoA and
home_init_cookie, HA generates the following HoT_HA message and
forwards it to MN.
HoT_HA:
Source IP address: CN
Destination IP address: HoA
{home_init_cookie | home_token | home_nonce_index}
home_token = First (128, HMAC_SHA1(Kcn, (HV | home_nonce | 0)))
Zhao, et al. Expires August 18, 2005 [Page 9]
Internet-Draft MIP6 RR Extensions February 2005
Please note that HoT_HA message can use the same MH type value for
HoT message because all these messages are transparent to MN. We
give the different names to these two messages in order to highlight
their differences.
MN generates the CoTi message and sends it directly to CN. Note that
CoTi carries HV instead of HoA in the cleartext.
CoTi:
Source IP address: CoA
Destination IP address: CN
{careof_init_cookie | HV}
HV = SHA1 (HoA | RN)
where RN is the same random number used in the HoTi.
After CN receives CoTi message, CN generates the CoT message. Note
that the formula to generate careof_token takes HV as input as well.
CoT:
Source IP address: CN
Destination IP address: CoA
{careof_init_cookie | careof_token | careof_nonce_index}
careof_token = First (128, HMAC_SHA1(Kcn, (CoA | HV | careof_nonce
| 1)))
The binding management key, Kbm, is generated by taking the
concatenation of home_token and careof_token as input of SHA1.
Kbm = SHA1(home_token | careof_token)
MN generates the BU message as follows and sends it to CN.
BU:
Source IP address: CoA
Destination IP address: CN
Zhao, et al. Expires August 18, 2005 [Page 10]
Internet-Draft MIP6 RR Extensions February 2005
{HoA | Seq | home_nonce_index | careof_nonce_index | RN | HC |
MAC}
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
When CN receives the BU message, CN firstly calculates HV based on
HoA and RN, then generates Kbm and verifies the MAC, finally verifies
the element in the hash chain. If MN requests the Binding
Acknowledgement, CN generates the BA message based on the
verification result.
BA:
Source IP address: CN
Destination IP address: CoA
{Seq | HV | MAC}
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
4.3 Protection of the HoA privacy in the BU message
Kbm = SHA1(home_token | careof_token | 0)
Ken = SHA1(home_token | careof_token | 1)
BU:
Source IP address: CoA
Destination IP address: CN
{Seq | home_nonce_index | careof_nonce_index | HV | ENC | MAC}
ENC = AES (Ken, HoA | RN)
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
BA:
Source IP address: CN
Destination IP address: CoA
{Seq | HV | MAC}
Zhao, et al. Expires August 18, 2005 [Page 11]
Internet-Draft MIP6 RR Extensions February 2005
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
Please note that the decryption operation is after the verification
succeeds, which is necessary to reduce the risk of Denial-of-Service
attack. However, an attacker on the HA-CN path can still pass the
MAC verification and make CN spend resources on the decryption
operation. However, this attack cannot be stopped. So if this is
really a concern for CN, the encryption is better not available.
4.4 Extending the RR test with a detection mechanism
The original MIP6 RR procedure allows an attacker to intercept the
traffic even though this attacker is only able to eavesdrop the
traffic, which makes MIP6 slightly less secure than the normal IPv4
Internet today. In order to address this vulnerability together with
other benefits we describe before, we propose a simple but effective
detection mechanism to enable CN to detect and then take the correct
action when the power of attacker can succeed in the original RR
procedure. The core idea is that either an attacker or a valid MN
must provide the cryptographically sound proof of the previous
successful Binding Update at CN if any before a new Binding Update
being accepted by CN. If the correctness of this proof cannot be
verified by CN, CN will disable the relevant Binding Update Cache
entry and switch from MIP6 RO mode to MIP6 Basic mode.
We adopt the concept of one-way hash chain to achieve this. Although
there are a lot of different kinds of one-way hash chain, we use the
following one:
MN wants to a chain of length l. Firstly, it generates a random
number h_l and then repeatedly applies the one-way hash function, F.
For example, h_l-1=F(h_l), h_l-2=F(h_l-1), à, h_0=F(h_1). This
one-way hash chain has the following properties: 1) MN reveals the
elements of the chain in the order of h_0, h_1, à, h_l to CN. Even
though the attacker acquires h_i in this chain correctly, it is still
cryptographically impossible for him to derive h_j from h_i where
j>i. On the contrary, any one can easily confirm that h_j is part of
the chain if h_i=F(h_j)^(j-i) where j>i. 2) MN can create the chain
all at once and store each element of the chain, or just store h_l
together with the sequence number of the next element in the chain
and generate the element on demand. In practice, other approach can
help to reduce storage cost with a small recomputation penalty. (It
is possible to use log(l) storage and log(l) computation to access an
element). Also we expect that the development of technology will
meet the increasing requirement of battery and memory for MN to
maintain such kind of one-way hash chain.
HC denotes the current element in the one-way hash chain and Seq
Zhao, et al. Expires August 18, 2005 [Page 12]
Internet-Draft MIP6 RR Extensions February 2005
denotes the sequence number of this element in the one-way hash
chain.
MN generates the BU message as follows and sends it to CN.
BU:
Source IP address: CoA
Destination IP address: CN
{HoA | Seq | home_nonce_index | careof_nonce_index | RN | HC |
MAC}
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BU)))
When CN receives the BU message, CN firstly calculates HV based on
HoA and RN, then generates Kbm and finally verifies the MAC. If the
verification is successful, CN performs the following procedure:
Search the Binding Update Cache by using MNÆs HoA as the primary key.
If it does exist, CN verifies the HC in the BU message with the old
element stored in the Binding Updates Cache.
If it succeeds, CN believes this BU message is correct and then sends
the Binding Acknowledgement message if requested.
If it fails, CN realizes that there is an attacker that can
successfully finish the extended RR test; however, CN is not sure
whether this BU message is from the attacker or a valid MN based on
its current knowledge. Thus CN disables this entry until it times
out, indicates the reason in the BA message and forwards the data
packets destined to this HoA based on MIP6 Basic mode rather than
MIP6 RO mode.
If it does not exist, CN accepts the BU message and creates a new
Binding Update Cache Entry and forwards the data packets destined to
this HoA based on MIP6 RO protocol.
CN also has to take into consideration the case that MN fails or
reboots and all the information related to HC is lost. In this case,
CN has to wait until the related BCE expires before accepting the new
BU message.
If MN requests the Binding Acknowledgement, CN generates the BA
message based on the verification result.
Zhao, et al. Expires August 18, 2005 [Page 13]
Internet-Draft MIP6 RR Extensions February 2005
BA:
Source IP address: CN
Destination IP address: CoA
{Seq | HV | MAC}
MAC = First (128, HMAC_SHA1(Kbm, (CoA | CN | BA)))
4.5 Non-repudiation
In this session, we discuss about the non-repudiation issue. It
seems that the only way to achieve the non-repudiation of HA or CN is
to use the public key. Our extended RR test can be extended to
achieve the repudiation when the public keys of HA or CN are
available. The details of this extension are skipped because it is
equivalent to say that there exists the trust relationship between HA
and CN. However, by using hash chain rather than public key, it does
reduce the computation cost.
Zhao, et al. Expires August 18, 2005 [Page 14]
Internet-Draft MIP6 RR Extensions February 2005
5. Security consideration
We take the following special considerations when extending the RR
test:
5.1 The privacy of HoA is protected as much as possible
All other messages use the hash value of HoA instead of HoA in the
cleartext, which not only makes the attacker learn the HoA
information cryptographically impossible, but also help shorten the
length of message, simplify the task to design and parse message
format as the length of a hash function output is fixed. Moreover,
we append a random number to HoA before performing the hash function
in order to make it more difficulty for the attacker to derive the
HoA information.
Please note that the privacy issue is secondary compared with the
authentication because if an attacker can break the authentication of
the RR test, the privacy of HoA cannot be kept. (If the process of
encryption/decryption is much more expensive, the attacker can launch
the Denial-of-Service attack to CN.)
5.2 The disclosure of HoA is postponed as late as possible
Even though the BU message leaks the HoA information, the attacker on
the MN-CN path together with its conspirator on the HA-CN path cannot
launch the redirection attack to intercept the traffic that is
intended to a specific MN if the attackers are assumed to be able to
eavesdrop the traffic only and the detection mechanism is in use.
5.3 Supports the fast Binding Updates procedure
The extended RR test supports the fast Binding Updates procedure in
CN, which is especially useful when MN moves from one location to
another frequently. When MN moves to a new location, MN can reuse
the home_token received at the previous location as long as
home_token is still valid, thus MN saves the home test procedure that
is usually longer than the careof test since HoTi and HoT messages go
through HA firstly.
Please note that the attacks described in [7] do not succeed in our
RR test. For the session hijacking attacks in section 3.1, although
the attacker can learn the home_token, however, it does not know the
HoA information, so the attacker cannot generate the correct BU
message. If the attacker has its conspirator on the MN-CN path,
since its conspirator cannot intercept the message, it cannot stop MN
from finishing the Binding Updates procedure at CN. Together with
the detection mechanism, the traffic cannot be hijacked. For the
Zhao, et al. Expires August 18, 2005 [Page 15]
Internet-Draft MIP6 RR Extensions February 2005
Movement Halting attacks in section 3.2, when the attacker is able to
know home_token and careof_token in the different sessions but from
one single MN, the attacker must have to learn the HoA from the BU
message. If the BU message is encrypted, the attack fails if the
attacker cannot monitor both paths simultaneously. If the BU message
is not encrypted, the attack still fails when the detection mechanism
is used. For the traffic permutation attacks in section 3.3, the
attacker is able to know multiple home_tokens and multiple
careof_tokens in the different sessions from multiple different MNs.
However, since both home_token and careof_token are generated from
the hash output of the HoA information, CN can detect the forged BU
message using mixed home_token and careof_token. Again the detection
mechanism can detect this attack as well.
Our RR test only prevents the attack target at a specific MN and the
attacker has no knowledge of the HoA information associated with this
MN. But the attacker on the HA-CN path is free to launch the RR
procedure for any HoA it chooses. Again, this attack can be
mitigated by the detection mechanism.
Zhao, et al. Expires August 18, 2005 [Page 16]
Internet-Draft MIP6 RR Extensions February 2005
6. Conclusions
In this draft, we propose several extensions to the MIP6 RR test.
Our proposal protects the privacy of HoA and provides a prompt method
for CN to detect the attack accurately when the attacker could
succeed in the original MIP6 RR procedure.
7. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[4] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[5] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", draft-ietf-mip6-ro-sec-02 (work in
progress), October 2004.
[6] Arkko, J. and C. Vogt, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization",
draft-arkko-mip6-ro-enhancements-00 (work in progress), October
2004.
[7] Bao, F., Deng, R. and J. Zhou, "Improvement of Return
Routability Protocol", draft-qiu-mip6-rr-improvement-00 (work in
progress), August 2004.
[8] Ng, C. and J. Hirano, "Extending Return Routability Procedure
for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
progress), October 2004.
Zhao, et al. Expires August 18, 2005 [Page 17]
Internet-Draft MIP6 RR Extensions February 2005
Authors' Addresses
Fan Zhao
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu
S. Felix Wu
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 754 7070
Email: sfwu@ucdavis.edu
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82 2 820 0714
Email: souhwanj@ssu.ac.kr
Zhao, et al. Expires August 18, 2005 [Page 18]
Internet-Draft MIP6 RR Extensions February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao, et al. Expires August 18, 2005 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 03:07:09 |