Subject: [MOBILE-IP] Meeting Minutes of Mobile IP Sessions at IETF46

From: Basavaraj Patil <[email-masked]>
Date: Mon, 29 Nov 1999 13:17:30 CST

This is the final version of the meeting minutes that has been submitted to the
IETF secretariat.

-Raj

=======================================================

Logistics:
--------------
The Mobile IP WG met in Washington D.C for two sessions on Thursday,
November 11th '99 from 9 - 11.30 AM and 3:30 - 5:30 PM.

Attendance at the sessions was approximately 226.

The meeting minutes for both sessions have been reported by Pete McCann.

|---------------------------------------|
| Morning Meeting (9:00 AM - 11:30 AM)  |
|---------------------------------------|

WG Status
----------------
Status of MN-NAI draft - The IESG has assigned an Experimental status
to this document.
Charles says it should be proposed standard - why don't we ask
for this change now?
Pat: "It's not clear how Mobile IP will make use of NAI" said the IESG.
But we need to make it work with other ROAMOPS stuff.
Raj says we will make another request to the IESG to change the status
to PS.

WG documents that will go to last call:
-3Gwireless micro-mobility
-Vendor/Org extensions
-Mobile IP for IPv6

Dave Johnson
Got a lot of comments at the last minute on Mobile IPv6
Mostly regarding IPSec interactions. We will go to working group last
call shortly, then to IETF last call.

Mobile IP Requirements for AAA
Raj says that this document is owned by the Mobile IP WG and the WG
needs to arrive at a consensus on the requirements. The intent is to
feed the requirements as input to the AAA WG.
The WG has been requested to provide more input into AAA
Pat: AAA WG has a very aggressive timeline.  People should read this draft
and provide comments. Maybe the only way to do that is to take it to
last call.

Draft Presentations :
----------------------------

1. Mobile IP Based Micro Mobility Management Protocol for 3Gwireless
Network Systems - draft-ietf-mobileip-3Gwireless-ext-01.txt
(Rajesh Bhalla)

It's a WG document because it will aid deployment of Mobile IP.
The document is a work of TIA TR45.4 and 3GPP2 TSG-A
Lots of contributing companies
Overview of 3G wireless network service domain - RNN, PDSN, R-P network
PDSN terminates link-layer and hosts a foreign agent
Draft focuses on R-P connection - minimizes latency of handoff

R-P Mobillity protocol objectives
  minimize RNN handoff latency and round-trip signaling through the
  packet network
  Extend link layer connectivity beyond a physical layer termination
  RNN and link-layer termination PDSN
  Provide mobility from RNN to RNN
  Provide a secure signaling mechanism for data transport

Q: Raj & Charles: could we use Binding Update for this?
A: yes, but standardization status of Route Optimization is unclear

Q: Dave Johnson: why is your schedule so tight?
A: (rajesh and lipford) yes, our schedule is tight - TSG is already in
   last call

Q: Ramjee: is RP an IP network?
A: yes
Q: Why not send binding update if the FA is at the RNN?
Pete: We have a requirement to give good service to nodes without MIP
      clients.  This is why RP must tunnel PPP data.

Q: Nordmark: how does old PDSN know the MN has gone?
A: timeouts

Q: when do you do a PDSN change?
A: outside the scope

////////////////////////////////////////////////////////

2. Update to RFC2002 - MobileIPv4 revised (Charles Perkins)
(draft-ietf-mobileip-rfc2002-bis-00.txt)

Really, really nit-picky details
Some places in original draft said be careful about using
now it said just don't

>Clarification by Charles:
>This refers to discussion about how to handle ARP for the mobile
>node and the foreign agent.

>RFC2002bis places significant new restrictions on the use of ARP.

MN must ignore reserved bits in advertisement instead of drop the advertisement
Calculation of authentication extension must include SPI
FA can now configure a max number of pending registrations, and may
delete them if > 7 seconds old

>Clarification by Charles:
>RFC2002 offers 7 seconds as a typical value for this timeout.  Particular
>implementations can still pick whatever value they like.  Other
>discussion at the meeting suggested the specification of a minimum
>value, and changing the suggested maximum from 7 seconds to something
>more.

FA must check for the case of MN registration even when on home network
Unrecognized set bits or unrecognized care-of address cause FA to drop
registration request

Max number of outstanding requests not standardize, but 7 seconds is hardcoded.
Dave J. & Nordmark: why is this hard coded?
A: ok, we'll talk about it

What to do with this draft?  Mandatory support for reverse tunneling?
Do we take it to draft standard or to an intermediate proposed
standard?  Does it become an RFC?

Some features have not been tested for interoperability - this would
hinder draft standard status

Pat: if there is a protocol change, it must go back to the beginning?
A: yes, if they are big
Dave: if changes reduce the maturity level, then yes, we have to go back
      to proposed
Pat: all interoperability already uses the new SPI calculation

Q: new FA forwarding text; sometimes two MNs on the same FA sometimes get
   traffic forwarded directly rather than via HA.  Also MNs can introduce
   denial of service if they make a mistake in their registration
   messages - sometimes re-registrations can be redirected at a MN!
A: Reverse tunneling might be important enough to go in.

Q (Charles): Is this a revised draft or a new draft?
A: Raj : maybe it's just a revision and we should go to draft standard
A: Dave: a new proposed standard would be a new 6 month clock
Q: Nordmark: what about the untested features?
A: Charles: yes, that's a concern
Q: what about private addresses?
A: Charles: let's not tackle that yet
A: Raj: we had some discussion and came to consensus, but it doesn't
   need to go in this draft

Montenegro: We could support private addresses with RFC2344
Survey of the room on proposed vs draft for this revision:
about 25 for porposed, low single digits for draft,
a few abstainers.  Because of the low number of votes we will take the
question to the list.

///////////////////////////////////////////////////////

3. AAA Requirements for Mobile IP (Charles Perkins)
(draft-ietf-mobileip-aaa-reqs-00.txt)

This has been presented to AAA WG
Tom Hiller has a similar presentation
This is now a MIP WG item - please read it and comment

Interactions between Mobile IP and AAA
MN presents credentials to the FA
Credentials are sent to FAAA, HAAA where they are verified, sent to HA
AAA protocol should work without specific details of Mobile IP
Mobile IP should work without specific details of AAA
FA - FAAA association, HA-HAAA association

Q: Johnson & Dommety: Can we really do away with security association
between MN and HA?  It's coded in the standards
A: Yes, this is a change, but people in industry like it
Q: Johson & Raj: this is a change.  Doesn't it break implementations?
A: Maybe, but this is a good way to model interaction between MIP and AAA
Q: Gopal: we need to keep RFC2002 as is
A: Charles: we are not breaking RFC2002, but we do need to change the
   requirement MN-HA extension
Q: Vipul: can't we just use MN-HA extension as is?
Q: Pat: AAAH will be generating session keys.  We need to know when to go
   to AAA vs. doing MIP
Q: Gopal: we could view HAAA & HA as one network.  We are asking AAAH to
   do Mobile IP
A: Pat: AAAH has no idea what a MIP RRQ looks like

///////////////////////////////////////////////////////

4. AAA Requirements for cdma2000 (Tom Hiller)
(draft-hiller-cdma2000-AAA-00.txt)

TR45.6 wireless data group
Carriers & vendors

Intro: packet data service for cdma2000; PPP service with limited mobillity +
       Mobile IP
Public & Private network access
Avoid IPsec tunneling over air interface
HA in public or private network
Overlay, dual-authentication architecture

General Architecture
PDSN, AAA, VLR, HLR, HA

cdma2000 MIP deployment status
  We need FAC with RADIUS-like extension
  Deployment depends on NAI and FAC drafts
  We need a robust AAA infrastructure

Q: NAI privacy is not a first requirement?
A: We're studying it, we don't know if it's a long term requirement or not

/////////////////////////////////////////////////////

5. Mobile IP Vendor/Organization Specific Extensions (Gopal Dommety)
(draft-ietf-mobileip-vendor-ext-00.txt)

Facilitate extensions for research and experimentation
Deployment in specific environments
Will help standards organizations (TR45.6) to standardize usage in
specific environments

Two extensions are proposed:
  Normal Vend/Org specific extension (NVSE)
  Type should be in range 128 to 255
  Vendor ID - higher order=0, low 3 bytes are SMI number for org/vendor
  Opaque data

  Critical Vend/Org specific (CVSE)
  Type in range 0-127
  Length is two bytes long

Q: Pat: we all know there will be an identifier in the opaque data.
   In RADIUS, we ended up with a lot of different encodings for the types.
   Maybe we should add a "type" in the opaque data field.
A: Ok, maybe we will add a two-byte type for the data.

Q: Vipul: since type is critical, should we revise RFC2002 to add error
   message if critical type is not recognized?
A: good idea, but we should defer to Charles
A: Charles: he's happy to put it in if the group agrees

Raj: next step is to make the changes and go to last call
Please send comments.  Any major concerns?

//////////////////////////////////////////////////////

6. KENA (Raja Narayanan)
(draft-mkhalil-mobileip-kena-00.txt)

KENA concepts/highlights
  Centralized key distribution framework
  protects user privacy and enables authentication
  is real time sensitive
  can be easily implemented using extensions to existing protocols

Lots of questions about need for NAI privacy and traceability
If NAI is encrypted, it is still the same every time and would be
traceable
Same for link-layer identifier

////////////////////////////////////////////////////////

7. AAA Session Keys (Pat Calhoun)
(draft-calhoun-mobileip-aaa-keys-00.txt)

It's now an individual contribution. The WG was asked if this needs to
be a WG document. General agreement reached. The document will be
resubmitted as a WG document.

MIP AAA requirements state that KDC is required
Creates 3 keys MN-HA, MN-FA, FA-HA

Problem: session keys destined for FA and HA will be delivered in some
         AAA protocol
         MN must get the keys in some other way

Proposal: Session keys destined for the MN are sent to the HA in the
          AAA message
          HA adds these session keys to the Registration Reply
          Mobile node gets the keys when the reply arrives

Q: Gopal: couldn't this be encrypted with the MN-HA key/SPI, not the
   MN-AAA key/SPI
Q: Nordmark: shouldn't we hide the SPIs?
A: Yes, maybe we will make these changes

/////////////////////////////////////////////////////

|---------------------------------------|
| Afternoon Meeting (3:30 PM - 5:30 PM) |
|---------------------------------------|

1. Mobile IP Extension Rationalization (Mohamed Khalil)
(draft-mkhalil-mobileip-mier-00.txt)

Add a "content type" and "E" field.  SPI present if "E" is present.
Then some session data.
Use "type" field like "NAI" or "Authentication Extension" then use
Content-Type to be "MN-HA" or "MN-FA", or "MN" "HA" "FA".  Add an "ET" bit

If someday we run out of types, we need to allocate 2 new types,
one from 0-127, another from 128-256

Q: Pat: why can't we start using the new extended types right away?
A: the long-term solution is harder to manage
Q: Pat: what about the space after the E bit?
A: Different extensions can have different flags
Q: Pat: why cant we encode encryption in the content-type?
A: User could do that if he wants

Q: Charlie: In auth extension, why not have a longer length and not
keep the reserved bits?  They could be taken care of with the SPI.

Q: Dave Johnson: why are we re-doing encryption?  Why not use ESP?
A: this is just like what Pat presented this morning

Q: Why do we need the E bit?
A: Sometimes SPI doesn't need to be present
Q: Pat: there are many types that don't need SPI?

Q:  Raj: what if we just had a reserved section, not an E bit?
A: yes, E bit not needed for many types

Q: Security association may be used for protecting the extension only?
   Then maybe any attribute would need an SPI?
A: Maybe... we'll take further questions on the list.

Q: Is there interest in making this draft a WG item?
(Raj asks) is there a real concern we are running out of Type space?
Q: Pat: how many type numbers are assigned today?
A: Charles: about 20 or so.  We should have a bit more discussion on the
mailing list about whether this is needed.

//////////////////////////////////////////////////////////

2. Mobile IPv6 Connectathon Report (Francis Dupont)

Organized by the G6 group

Implementations by :
    BULL (AIX)
    ERICSSON - TELEBIT (FreeBSD)
    NEC (FreeBSD)
    INRIA (FreeBSD)

Tests were done between MN & fixed correspondent, and MN &MN.
Some tests were done through the 6bone but most tests run on a local WaveLAN.

Graph of network connectivity

Suggestions for improvement in IPv6 draft
   Retransmissions of Binding Updates should increment the sequence number
   Renumbering, HA should DAD before binding ACK
   Draft has to do further into details of HA discovery

Q: Dave Johnson: I have seen only the second one mentioned on the mailing list

Conclusions
   Test event was very successful
   Some IPv6 stacks exist and can communicate
  Movement detection needs clarification
  No tests but discussion about IPSEC, IKE, and MIPv6 - SA with mobile SHOULD use a wildcard source

Q: Dave Johnson: not enough details. where can I get more?
(clarification in French)
A: http://www.loria.fr/~ichris/mobipv6/connectathon99/index.html

///////////////////////////////////////////////////////////

3. Cellular IP Update (Andrew Campbell)
(draft-valko-cellularip-01.txt)

Cellular IP project
Started at Columbia with Ericsson
Simple Vision: combining the strengths of Cellular + IP without
inheriting their weaknesses, leverage MIP work

Design Goals
Fast and seamless handoff
   Per-mobile routing soft-state
   Loss and delay sensitive applications
Scalable and real-time location management
   Support for active and idle mobile hosts
   Routing cache, paging cache/implicit paging
Simple access network design
  Off-shelf IP based boxes  (don't need expensive MSC/BSC)
  Plug and play configuration
  Support L2 or L3 networks

A lot of proposals in the past
   HAWAII, Cellular IP, THEMA, hierarchical MIP

Major changes to the Internet Draft
  Security support added
     Mobile and network have shared secret
     Control messages are authenticated
     Mobile goes through authorization phase, creates a PID, used by MN as
     it goes through the access network
  Paging areas added
     reduces messaging of idle hosts
  Semi-soft handoff with/without "delay devices"
     support for delay and loss sensitive apps (TCP and RTP/UDP) with fast
     handoff
     Sends a route-update packet to the new base station, then can receive
     packets from both old and new base station
     Delay devices introduced to do "coarse synchronization"

Minor changes to the I-D
  Cache mappings cannot be created or modified by data packets, but can
      be refreshed
  Optional paging tear-down
      Use soft-state whenever possible
  Control packets are ICMP
  Control packets must contain timestamp and auth information

Web page for Cellular IP
comet.columbia.edu/cellularip/

/////////////////////////////////////////////////////////////

4. Cellular IP Performance (Javier Gomez)
(draft-gomez-cellularip-perf-00.txt)

Cellular IP nodes/mobile hosts: Pentium 300 MHz
Wired links: ethernet 10/100
wireless links: 802.11 with new device drivers

Software
Runs in user space, based on PCAP
easy to upgrade to newer freeBSD releases
easy to port to other UNIX OSes

Implementation Model
Dowlink interface, uplink interface, PCAP in kernel space
Routing cache, paging cache, in user space

Repeat experiment with TCP (TTCP)
performance graph of downlink TCP throughput vs. number of handoffs per minute
Semisoft handoff improves throughput - using a buffer improves throughput
even more

Q: Charlie: what is semi-soft handoff?
A: immediately upon handoff, we can send control messages to the old BS to
forward packets

Scalability issues
Cellular IP uses per-host routes
Achieves scalability by a separation of active/idle mobile hosts
Most hosts are idle at any given time

Other scalability issues: increase the size of the database in which we
      search for a mobile
Graph: nodes throughput in Mbps vs. number of MNs in the database
Is not too bad for IP forwarding to a single user when we do binary search
Linear search performance gets very poor as number of MNs increases

Q: do you really mean 10^6 MNs?
A: yes
Q: how many routers need to be updated?
A: depends on the scenario

source code is at comet.columbia.edu/cellularip

Q: you are not including changes in the over-the-air data rate as the MN
   changes speed? As the active nodes move at different velocities, they
   change their data rate.
A: yes, we need more signaling

Q: performance are for TCP streams.  What about latency?
A: no.  Compared throughput with IP forwarding
Q: look at CDPD - its latency is too high.
A: Achieving 90% of what IP forwarding can do, so latency should not
   be an issue

/////////////////////////////////////////////////

5. Minimal latency secure handoff (Pat Calhoun)
(draft-calhoun-mobileip-min-lat-handoff-00.txt)

What can we do to minimize latencey when MN-FA share a key?

Mobile IP WG has a AAA KDC requirement
Home AAA server acts as a key distribution center and creates session keys

Foreign agent receives the session keys via the AAA protocol
When MN moves to a new FA, the new FA must retrieve the MN-FA and FA-HA
session keys

An assumption has been made that the FA could get the keys from the AAAF.
If the AAAF does not have the session keys locally, the request must be sent
to the AAAH to retrieve new session keys
This adds considerable delay in the hand-off process

Proposal
When new session keys are distributed by the AAAH, the FA encrypts the
MN-FA and FA-HA session keys, and adds them to the RRP
MN includes them in the RRQ at the new FA

Message size
Increased but only when new keys get generated

Q: (Raj): if all FAs are in the same domain?
A: we could query the previous FA, but it's simpler to use a blob that
   is passed to the new FA
Q: Charles: state of route optimization draft is not clear, but it may come
   back to life.  Wouldn't it be better to retrieve the key from the old FA
   over the wired network using the same SA?
A: do we have a chicken and egg problem?  Before we send the binding update,
   we need to authenticate?
Charlie: no, the binding update includes the authentication
Pat: ok, maybe this isn't necessary

Q: To clarify: when the MN moves to a new FA, instead of sending previous
   FA NAI, just use previous FA notification message from binding update draft
A: Charlie: correct, but we don't need the NAI.  You could use it if you
   wanted to.

Q: (Milo): Two kinds of models, terminal centric, network-centric model.
   Maybe as we roam, I identify myself to the new FA, on behalf of MN I
   establish connectivity to a new HA
A: Charlie: no need to go to the extreme of eliminating all information
   from MIP RRQ
Milo: we still have registration between FA and HA, but not necessarily
      triggered by MN, just the announcement of the MNs identity.  All
      information is retrieved from previous FA.
A: Charlie: not related to current presentation.  This is purely a device
   for passing around keys.

Q: Pat: can we process RRQ and Binding Update simultaneously?
A: Charlie: they happen in parallel
Q: what would happen if MN-FA was invalid, but MN-HA is valid?

Next version of draft will be issued that provides similar functionality
when PKI is used instead of a KDC

////////////////////////////////////////////////////////

6. Buffer Management for MIP (Haseeb Akhtar)
(draft-mkhalil-mobileip-buffer-00.txt)

In addition to the layer-2 mechanism, we are trying to propose something
on layer 3
Problem: packet loss during handoff
MN moves to a new FA, HA creates a new tunnel between HA-NFA, packets in
transit to the previous FA are lost

Q: Dave Johnson: what about packets that were already sprayed into the air
A: old FA is constantly buffering, even packets that were sent on the air

Solution: buffer and forward data
Minimize the window of data loss: previous FA buffers packets and forwards
to the MN
Results in fewer retransmissions for upper layer protocols

3 scenarios are in the draft, we will cover 2.
1. Mobile Assisted handoff
2.  PFANEH handoff

New Messages
Buffer Control Request - Mandatory for MN and FA
Can be sent as an independent message or as an extension to Registration
  Request and Binding Update messages
Buffer Control Response
  Optional for MN and FA

Q: Dave Johnson: I don't think you can convince everyone to allocate large
   buffers in FAs
A: Maybe, but its a tradeoff
A: we need a buffer of 2 or 3 packets
Dave: we need one window size for each TCP connection.  That's more than 2 or 3

/////////////////////////////////////////////////////

7. Dynamic IP Address Allocation in Mobile IP (Tomas Bostrom)

Current assumptions
Mobile IP: transparent availability based on permanent IP address
Permanent home address allocation

Why do we need dynamic address allocation?
Address = location
Name = identity
Hosts should be identified based on names, not IP addresses
Modern technology promotes nomadic computing (home network wherever you go)
=> concepts of home and foreign have become obsolete
     no need for a permanently allocated address

Dynamic Address Allocation Scope
  Home address acquired dynamically on a temporary basis
  Local connectivity
  Roaming between different domains shall be possible
  Both in public and corporate networks
  Support cross-domain allocation
  "Home" and care-of address could be allocated from different admin domains

Solution
  DHCP-like mechanism should manage temporary IP address allocation
  Dynamic address associated with NAI using DNS-like mechanism
  Temp  home address should be kept by the MN as long as it is connected
  to the same admin domain

Q: 100 ms is too slow
A: within a domain only

Q: Gopal: NAI draft + RFC 2002 can do this
A: Would like to extend this idea

Q: Mobile IPv6 solves this problem
A: this is IPv4 base

Q: Milo: you have solved just half a problem, MN is just a client.
   If I want to refer to the MN, I need dynamic DNS.  It is simpler to just
   go to a static HA than try to solve these problems.
A: MN should keep its temp IP address as long as it is connected to the
   same admin domain.
Q: Dave: do you lose that address when you move outside the domain?
A: yes
Q: this breaks TCP connections and the charter of this WG

>Clarification from Tomas to the question:

>When I said yes I assumed that the terminal was turned off before it
>was moved outside the domain. However, if the terminal is turned on
>while moving to a new domain the terminal should keep the same address
>in the new administrative domain using cross-domain allocation
>mechanisms and thereby keep its TCP connections alive.

Q: Gopal: what is the problem you are trying to solve?   If you want to do
   only IP allocation we already do it

/////////////////////////////////////////////////

8. Modifications to "Mobile IP Regional Tunnel Management" from a cellular
perspective (John Wang)
(draft-ietf-mobileip-reg-tunnel-01.txt)

Purpose:
    Propose modifications that could be combined with MIP RT Management
    draft for issues in next generation cellular telephony networks

Issues
   Tromboning in data routing
       Triangle routing through HA
       Should have distributed FA database
   Peer-to-peer rather than master-slave
       over-the-air capacity, computing power, power supply demanding
       (should put more demanding aspects into the network)
       should be able to fool-proof MIP

Q: (Dave Johnson) is tromboning same as triangle routing?
A: yes.

Why is tromboning a great concern?
Cost & quality of service

Q: Dave Johnson: who provides services of higher layers of the hierarchy?
A: cellular service providers could have total or shared ownership
Q: Are you proposing a global infrastructure separate from the Internet?
A: no limitations.  Could be part of intranet, depending on business model

Well Recognized Technology
  UMTS applications
     performance evaluation and architecture optimization
     DDB architecture
  Lucent ATM distributed load-balancing technology very similar

Open issues
  Call routing regional tunnel management, route optimization
  Addressing & routes

Q: Are you proposing new inter- or intra-system network?
A: there is no requirement.  Could be either.  For performance it should
   be intra-system
Q: So this is baseline for UMTS or cdma2000 architecture?
A: Cellular carriers in 3GPP and UMTS require this
Q: 3GPP already has some internal protocol

/////////////////////////////////////////////////////