draft-ietf-seamoby-cardiscovery-issues-03.txt   draft-ietf-seamoby-cardiscovery-issues-04.txt 
IETF Seamoby Working Group Dirk Trossen IETF Seamoby Working Group Dirk Trossen
INTERNET-DRAFT Govind Krishnamurthi INTERNET-DRAFT Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-03.txt Hemant Chaskar draft-ietf-seamoby-cardiscovery-issues-04.txt Hemant Chaskar
12 June, 2002 Nokia 16 October, 2002 Nokia
James Kempf James Kempf
DoCoMo DoCoMo
Issues in candidate access router discovery Issues in candidate access router discovery
for seamless IP-level handoffs for seamless IP-level handoffs
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 5, line 24 skipping to change at page 5, line 18
Scenario 2: Resource intensive applications Scenario 2: Resource intensive applications
Consider an MN running a streaming video application, which might be Consider an MN running a streaming video application, which might be
an important application for the future mobile networks. These an important application for the future mobile networks. These
applications require high bandwidth and possibly other QoS support applications require high bandwidth and possibly other QoS support
to be available at the AR serving the MN. When this MN moves into to be available at the AR serving the MN. When this MN moves into
the coverage area of a new AR, it is possible that the new AR does the coverage area of a new AR, it is possible that the new AR does
not have the capability to support the MN's application. The MN can not have the capability to support the MN's application. The MN can
then be informed about this fact when it is still connected to the then be informed about this fact when it is still connected to the
current AR. Clearly for this, it is necessary to have the knowledge current AR. This information might be used to alert the user about
possible service degradation when moving. If the MN does have choices
in what AR might be used for connectivity after moving, i.e., because
of overlapping coverage areas, these choices might be presented to the
user or the running application might make choices based on certain
preferences. Clearly for this, it is necessary to have the knowledge
of the capabilities of the neighboring ARs, and this can be of the capabilities of the neighboring ARs, and this can be
obtained using the CAR discovery protocol. obtained using the CAR discovery protocol.
Scenario 3: Least-cost phone call Scenario 3: Least-cost phone call
Consider the preference expressed by the MN to prioritize handoffs Consider the preference expressed by the MN to prioritize handoffs
to an AR with minimal cost of access for phone call (``least cost to an AR with minimal cost of access for phone call (``least cost
policy"). The ``cost of access" capability of an AR can be obtained policy"). The ``cost of access" capability of an AR can be obtained
using CAR discovery protocol. using CAR discovery protocol.
skipping to change at page 7, line 21 skipping to change at page 7, line 21
ARs are similar. However, heterogeneity may arise among different ARs are similar. However, heterogeneity may arise among different
ARs due to factors such as additional functions performed by ARs ARs due to factors such as additional functions performed by ARs
(seamless handoff support, security functions, wireless performance (seamless handoff support, security functions, wireless performance
enhancing functions, etc.), administrative and business aspects of enhancing functions, etc.), administrative and business aspects of
providing service to MN (service provider, cost of access, etc.), providing service to MN (service provider, cost of access, etc.),
availability of certain type of resources with AR (QoS availability) availability of certain type of resources with AR (QoS availability)
etc. A solution is needed that will allow the MN to learn the etc. A solution is needed that will allow the MN to learn the
capabilities of CARs that it might be interested in. CAR discovery capabilities of CARs that it might be interested in. CAR discovery
protocol enables this. protocol enables this.
However, since the complexity of the process might grow, in particular
with growing number of capabilities, limitations in the scope of CAR
discovery with respect to, for instance, the number of supported
capabilities or the final decision making, might be necessary to cope
with this complexity issue.
5. SECURITY CONSIDERATIONS 5. SECURITY CONSIDERATIONS
CAR discovery may allow other nodes to learn information about an CAR discovery may allow other nodes to learn information about an
AR, including its IP address and capabilities. Malicious nodes may AR, including its IP address and capabilities. Malicious nodes may
use this kind of information to launch DoS attacks and/or service use this kind of information to launch DoS attacks and/or service
hijacking. Therefore, the following topics should be covered in any hijacking.
solution developed for CAR discovery:
Information about the capabilities of a CAR often needs to be
digitally signed. Otherwise, intentional or accidental APs can
capture traffic, to the detriment of the MN. Such captures can
result in black holes, and/or can facilitate eavesdropping and active
attacks. Attacks like these have already occurred on 802.11 networks.
The need for digital signatures can cause other problems. MNs MUST
be preprovisioned with information that lets them ascertain the
authorization of any CAR. Digital signatures are expensive to compute
and verify; this can translate into increased computational load on
the CARs and on the MNs, and increased power consumption on the MNs.
Therefore, the following topics should be covered in any solution
developed for CAR discovery:
- Authentication of nodes - Authentication of nodes
- Security associations between nodes - Security associations between nodes
- Message/payload encryption. - Message/payload encryption.
- Encryption of CAR capabilities
- Additional load on CARs and MN due to additional security measures
6. ACKNOWLEDGEMENTS 6. ACKNOWLEDGEMENTS
Special thanks are due to John Loughney (Nokia) and Hesham Soliman Special thanks are due to John Loughney (Nokia) and Hesham Soliman
(Ericsson) for their input during the preparation of this document. (Ericsson) for their input during the preparation of this document.
Steve Deering's thoughts about how to involve the mobile node in CAR Steve Deering's thoughts about how to involve the mobile node in CAR
discovery were instrumental in achieving more focus to the problem discovery were instrumental in achieving more focus to the problem
statement. statement.
7. REFERENCES 7. REFERENCES
1. ``IP Mobility Support", C. Perkins (Editor), RFC 2002, October 1. "IP Mobility Support", C. Perkins (Editor), RFC 2002, October
1996. 1996.
2. ``Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari 2. "Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari
Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, May Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, May
2002. 2002.
3. ``Low Latency Handoffs in Mobile IPv4", MIPv4 Handoffs Design 3. "Low Latency Handoffs in Mobile IPv4", MIPv4 Handoffs Design
Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in
progress, February 2001. progress, February 2001.
4. ``Fast handoffs for Mobile IPv6", MIPv6 handoff Design Team, 4. "Fast handoffs for Mobile IPv6", MIPv6 handoff Design Team,
draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April
2001. 2001.
5. ``Problem Description: Reasons For Performing Context Transfers 5. "Problem Description: Reasons For Performing Context Transfers
Between Nodes in an IP Access Network", O. H. Levkowetz, et. al., Between Nodes in an IP Access Network", O. H. Levkowetz, et. al.,
draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in
progress, May 2001. progress, May 2001.
6. ``General requirements for a context transfer framework", H. 6. "General requirements for a context transfer framework", H.
Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in
progress, May 2001. progress, May 2001.
7. ``Buffer Management for Smooth handoffs in Mobile IPv6", G. 7. "Buffer Management for Smooth handoffs in Mobile IPv6", G.
Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi- Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi-
mobileip-buffer6-01.txt, work in progress, March 2001. mobileip-buffer6-01.txt, work in progress, March 2001.
8. ``Supporting Optimized Handover for IP Mobility - Requirements 8. "Supporting Optimized Handover for IP Mobility - Requirements
for Underlying Systems", J. Kempf, et. al., draft-manyfolks-l2- for Underlying Systems", J. Kempf, et. al., draft-manyfolks-l2-
mobilereq-02.txt, work in progress, November 2001. mobilereq-02.txt, work in progress, November 2001.
9. ``A Reverse Address Resolution Protocol", R. Finlayson, et. al. 9. "A Reverse Address Resolution Protocol", R. Finlayson, et. al.
RFC 903, June 1984 RFC 903, June 1984
10. ``Dynamic Host Configuration Protocol", R. Droms, RFC 1531, 10. "Dynamic Host Configuration Protocol", R. Droms, RFC 1531,
October 1993. October 1993.
8. AUTHORS' ADDRSSES 8. AUTHORS' ADDRSSES
Dirk Trossen Dirk Trossen
Communication Systems Laboratory Communication Systems Laboratory
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803, USA Burlington, MA 01803, USA
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/