IP Routing for Wireless/Mobile Hosts (mobileip) Monday, 8/24/98, 0930 - 1130 Co-chairs: Erik Nordmark Jim Solomon Minutes by: John Zao Presentations: 1. Stuart Jacobs , Mobile IP and Public Key Based Authentication, This Internet Draft proposed a set of extensions to Mobile IPv4 control messages including Mobility Agent Advertisements, Registration Requests and Replies for providing non-repudiated proof of origin and integrity of the control messages using public key digital signatures. Two types of extensions are used: 1. Signature Extensions - that affix digital signatures of specific algorithms to the control messages; 2. Certificate Extensions - that contain a chain of certificates needed for verifying the signature in the associated Signature Extensions. X.509 certificates and certificate revocation lists (CRLs) are used to distribute the public keys necessary to verify the digital signatures. [Questions/Comments] 1. What are the computation complexity of digital signatures and its impacts towards the latency of Mobile IP registration? Answer: Verification of a 512-bit RSA signature using a Pentium P-166 laptop takes less than 1/20 of a second. We expect it will take even less time as the computing power of laptops continue to increase. 1a. Can 512-bit RSA signatures provide sufficient protection? Answer: They are probably strong enough for practical purposes since Mobile IP registrations tend to have relatively short life spans. We may consider to use longer keys (e.g. 1024-bit keys) when the need arises. 2. Why not use public key infrastructure (PKI) and the certificate dispatch mechanisms it provides rather than sending certificates in every registration exchange? Besides, how do the mobility agents (MNs, FAs and HAs) obtain CRLs? Answer: Including certificates in the control messages may use up certain amount of bandwidth, but it simplifies the process of getting necessary certificates. The exchanges of CRLs will be addressed in future work. 2. Charles Perkins , Mobile IP and DIAMETER, Lack of authentication/authorization/accounting (AAA) support is slowing down and even preventing the wide-spread adoption of Mobile IP. This draft proposes security mechanisms and Attribute/Value Pairs (AVPs) to provide AAA support for Mobile IP using DIAMETER protocol. DIAMETER is a functional extension of RADIUS for conducting general server based AAA operations. This work uses the protocol to meet the AAA demands associated with Mobile IP registration. Trusted AAA agents will be added to Mobile IP home and foreign domains. Challenge-response exchanges will be passed between the AAA agents and the mobility support entities. The outcome will be authentication of MNs by the AAA agents in their home domains, authori-zation of MN- FA connectivity by the AAA agents in the foreign domains, and accounting managed by FAs under the supervision of AAA agents in the foreign domains. As an option, the AAA agents in home and foreign domains may depend on inter-domain service brokers to establish mutual trust relations. [Questions/Comments] 1. How does AAAF, AAAH, and 3rd-party broker(s) discover one another and establish mutual trust? Answer: Agent discovery and trust management lie beyond the scope of this work and are dealt with in the Roaming Operations (roamops) working group. 2. What's the status of DIAMETER? Answer: The detail of DIAMETER protocol will be presented in the AAA BOF on Friday 8/28. 3. Could this proposal be "transliterated" into RADIUS? Answer: RADIUS can probably be used to support simple Mobile IP AAA but not this full set of exchanges. Remember, RADIUS does not support server-server authenti-cation and was meant to be used for dial-up connections. It may be proper to keep it that way. 3. Shin We , Reverse Network Address Translators (RAT), This Internet Draft proposed to use network address translations (NAT) to perform location management and packet forwarding for Mobile IP. The purpose was to promote Mobile IP deployment by leveraging on the increasing popular NAT technology. The RAT system consists of the Mobile Nodes (MNs), a Registration Server (RS) and one or more RAT devices. Both the RS and the RAT devices are present in MNs' home domain. The RAT devices perform the address translations and play the role similar to HAs. The RS functions as the trusted proxy of MNs to initiate and end NAT sessions for the MNs. As noted by the speaker, RAT is not capable of supporting seamless Mobile IP handoffs and has end-to-end service limitations similar to NAT. Also, the RAT devices functioning like HAs in home domains may become the bottleneck and the single point of failure. No authentication mechanisms are in place at the present stage. [Question] Is this an alternative to SOCKS? SOCKS can also be used to signal address translation devices existing in network domains. References to SOCKS v5 were given to the speaker. 4. Gabriel Montenegro , Negotiated Address Reuse (NAR), NAR is a SOCKS v5 based scheme for managing mappings of IP addresses and other packet header fields between two networking realms in different address spaces. This presentation described the use of NAR to reconcile NAT technology with layer 3 tunneling protocols such as Mobile IP and TEP. NAR has two operation modes, (1) end-to-end address mapping and (2) address translation. Both can be used for Mobile IP packet forwarding. The header fields used for packet demultiplexing are (1) inner header destination address, (2) outer header source address and (3) outer header destination IP address. [Question] Can the NAR protocol work with multiple/nested address spaces? Answer: Yes. 5. Dave Johnson Mobility Support in IPv6, The presentation constituted the last call for changes to the Internet Draft . Following were major issues and changes discussed at the meeting. Also, please refer to the latest draft for a list of recent changes. [Questions/Comments] 1. Is the tunnel a hop or not? Answer: Yes, you need to have one hop left. 2. Rules for binding lifetime -- what if you're registering multiple addresses? Consensus: Choose to use the minimum of all proposed lifetime. 3. Need to specify the duration for remembering the sequence number after the deletion of an address binding. Consensus: Minimum of 120 seconds or remaining lifetime. Issue: CDPD keeps states around for ages. The end-to-end working group couldn't think of anything better than 120sec even after plenty of discussions. 4. Update IPSEC references to the new documents. What if the MN-HA security association expires while the MN is away from home? Decision: look further into the issue and discuss it to the mailing list. [Procedural Issues] 1. Mention to IESG/RFC-EDITOR that this document "updates" IPv6 specifications. 2. Place in the Mobile IPv6 draft, perhaps in the ABSTRACT but definitely up front, that this document places some requirements on **ALL** IPv6 nodes, so don't blow it off just because you don't care about mobility. [Editorial Nits] 1. Add IPCPv6 as a method for obtaining a COA.