Subject: [MOBILE-IP] Minutes of WG meetings at IETF49

From: Basavaraj Patil <[email-masked]>
Date: Mon, 15 Jan 2001 08:30:24 -0600

Mobile IP WG at IETF49 meeting minutes. Thanks to James Kempf and
Scott Corson for capturing the proceedings.

--------------------------------------------------------

Session 1:
::::::::::

Agenda bashing - accepted. Other topics deferred to
end of session 2.

Charter update - streamlined, specific to MIP, other stuff
offloaded to Seamoby.
  - fast handoff for mobile IP v4 & 6

FH MIPv4 - complete
FH MIPv6 - in progress

MIPv6 spec - issues pending

New RFCs - Info 2977 AAA Reqs.
3012 MIPv4 CHAP, Standards track.

Editors queue - 2344bis - reverse tunnelling
                vendor extensions

Passed WG last call - route optimization (no comments)
                    move to IESG next week

                    regional tunnelling (issues raised)
                    being addressed, revision forthcoming
                    Possibly another wg last call.

                    general NAI ext. (no comments)
                    to IESG next week

                    MIPv6. Security issues, new revision
                    result of changes. IPSEC WG

Other IDS - 2002bis IESG last call complete

Ext rationalization - fallen off. Complete last calls last time,
                      (AD comment?)

3G wireless extensions - WG last call, issues during IESG last call
                         discussion, returned to IESG.

HMIPv6 - going to WG doc. Talk about today. Original and INRIA proposal,
       concensus, no comment.

Connectathon Event

Testing of MIPv4, MIPv6, Diameter.

Questions about including HMIPPv6 since it is not yet official.

Dave Johnson - Mobicomm announcement (Rome)

Charlie on MIPv6 update.

reduce confusion, clarify, make sure interoperable.
text included, placements for home address option and
binding update option.

Home address option - needs to be in front of security
headers but before routing header, but means that
intermediate nodes must process.

IPv6 - dest options before routing and after security,
but can put elsewhere. Will be after routing header
but before fragement header (like to have firewalls
use home address for processing).

Binding update after security headers. Renumbering
work, appendix on how to get home address if
you don't have one to start with. Main part
of draft, spec on what to do when home network
renumbers, want to avoid flooding router adverts.

Q. does this use ESP? Later.

Eliminate renumbering, part of message flow.

How to calculate AH (needing for binding update auth)?
Home address option changes care of address, calculate
on stream of data w. home addr in IP addr field and
coa in home addr optoin. Security association is considered tied
to home address.

Use of ESP or AH? Draft allows AH only now. Revisit
requests - return to this.

Can send router solicitation to get more lifetime
for home address, request from home agent.

D bit - does HA have to do duplicate addr detetion?
HA may or may not make sure unique. If mobile
does out of blue, dup addr detection necessary.
Takes longer than spec was for retransmitting
BU. Initial BU retransmission longer.

Details about home agent delaying router adverts
when home network renumbered.

minor point - preferences for HF must be zero if unspecified.

Issues during last call:

use ESP? - AH put into IPSEC without full enthusiasm from
IPSEC, seems right for binding update. AH is mandated
for use with BU and BA. If ESP is better, then why not
allow? Reason for doing w. AH: it works.

Politial problem in IPSEC - some IPSEC WG members want to get rid
of AH.

Meeting with security people, no agreement on AH v.s. ESP.
Will be sent to ADs.

Question: do they need to redo IKE associations if using
ESP and go mobile?
Hardware acceleration is easier for ESP.

Changing opposition: advanced stage of last call. Using
ESP in tunnel mode? No overhead.

Tech problem: must auth binding update, doesn't contain
HA or CoA. ESP only protects part below header, AH
protects whole packet. CoA is above ESP, so would
not be protected. Overhead of adding CoA lower down
is too much, too many ways to encode.

ESP is slightly larger than AH, but to add CoA lower
down would require 16 bytes for address, 2 bytes for
identification, another 6 bytes for padding.

2 kinds of overhead, per packet, overhead of additional
SA, need to be discusssed. SA overhead only once, when
you go mobile.

Process issue: consistent doc not there, will get comments
from IESG. Last night: send to AD with preface pointing
to issues. Trying to complete. IETF last call once.

Code running is for draft 13.

But not in draft. Only two implementors know how
to do it. Code is not in draft.

Nonagreement - whether it should be specified in draft.

What's in the draft- result of last interop test.

What is the prob getting doc only using AH,
details yet to be resolved. Separate draft about
how to use ESP.

With more implementation experience, then revise.

ESP has momentum.

ETSI bakeoff, didn't have AH, one implementation does
not use AH. BA, protected by AH, can't protect unless
in tunnel mode because can't protect routing header.
Using AH makes simple to protect routing header.

AH v.s ESP discussion ended.

How does key negotiantion between CH and MN occur.

SA is associated wi. HA not CoA.

Security DB selectors is difficult problem, select
from database for doing auth, not this
level of granularity in IKE. binding update one
SA, ack another.

How does BU security scale? Security ADs lead that
it is broken. But logic says that IPv6 security
is therefore broken.

Operational issue. Not a routing area issue.
Solution: do triangle routing.

Intractable problem: global PKI, narrow slices.
What is MIP issue is how many SAs need to be
created.

Many keys, could have an SA that does both
BU and normal traffic.

Proactive FAs

FH design team - reduce number proposals to one

two proposals, combined three into one of two

email to only use messages from binding family

authors felt that needs bidirectional support.

need both oFA and nFA to initialte.

Source and target triggers.

Source: oFA sends msg to nFA,
Target: nFA sends msg to oFA.

Bicasting - once handoff message, new packets sent
across both, no L2 - drop packets.

Address power consumption - dormant mode, don't require
mobile to awake. Draft doesn't require.

generalized link layer address - include hardware address to
map link layer to mobile.

Also supports regional registration.
mobile moves to new FA, message handoffs occur, nFA
knows a GFA involved, regional reg done by GFA.

Was design team to come up with solution or combine drafts?
v4 - consolidate drafts where possible, one draft going forward.
Not all possible scenarios.
v6 - more comprehensive.

Result not to rubber stamp.

Security to prevent hijacking of messages, why transfer?
Assume trust relationship.
FAs have security association, includes FA/FA auth extension,
can prove.

Only proves who I am, not that it's authed.

Some access networks in which assumption is not
valid. Possible to solve fast handoff with 802.11?
Hasn't looked at those access networks. IAPP
only in one subnet.

How to you handle packet loss? Is L2 authenticated?

Hesham: mobile does movement detection.
uses standard 2002.
support both mobile network, mobile most be able
to decide whether it can register or not.

support ping-pong. No knowledge of timing.
independent of L2.

support local mobility, with GFA, etc.
Anticipate if L2 allows you to do so.

Simultaneous binding, S bit to two locations
to support ping pong.

Relay to mobile node, mobile node runs movement detection,
registers right away w. SA2, mobile node moves to FA2,
traffic is already there. Not necessarily two streams
because L2 may drop. Need to decouple from L2.
Don't have to base on regional.

Final particular case, GFA as first hop, bicasting to
to both places, but sent to where out.

Comparisons:

FH draft requires L2 messaging over the air
before complete.

Need to have an advert multihop solicatation,
mobile node must come on traffic channel,
no access to signalling channel, send
reg request, reply back before handoff
can take place, indicate to network
that complete.

Radio environment may deteriorate
during handoff on old link.

Provisioning neighbors. Associate link layer
triggers w. FA both, FH also requires advert

FH relies on GFA to redirect traffic.
Who is in control? FH mobile has control,
L2 controls today, mobile has final say.

Karim. Mobile can do movement detection.
One approach, do registration after,
not clear. Don't need to adverise.
Intersystem handoff, no new messages in FH.

Forced by network to do handoff where
you don't want to go, network hands
you off, data sent to wrong FA, no sim bindings,
clear problem.

Much discussion about L3 v.s. L2 handoff.
L3 signalling appropriate for multiple
L3 handover, shouldn't rule out L3 smarts.

Bicasting, base stations can't tell if
mobile is dormant or talking to another
base station.

Discard rather than buffer on L2.
Put drafts together, assumptions
on link layer, similar kinds of network.

Several types of scenarios. Can you start
with something and cover all cases?
Come up with a generic solution? Not for
one link layer.

IAPP traffic for monitoring on
802.11.

What is the best handoff?

Merge two drafts?

Hum says merge.

IPv6 fast handoff.

Design goals - be flexible, one size does not fit all.

Focus on Break before Make - most clear cut case.

Mobile initiated/network initiated.

L2 features when available, but also when not there

Robust, fall back.

Other MIP features - bicasting, buffering, context transfer, localized mm

Advance prepartion of the handoff.

Use MIPv6 messages where possible.

Scenarios:

1) Mobile nod initates handoff at new access router

2) New access router initiates handoff when mobile connects... 2 others

initiate handoff at old, prepare hanoff btween ARs, complete handoff at new
details not done.

Network initiated.

Data coming to old AR, trigger, tells you that handoff needs to take place.
Proxy Router advert send to MN, allows mobile to create new CoA before gets
to new AR,
mobile may need to send a BU.

Old AR sends handoff iniitate to new, acked by new

Mobile connects to new, handoff update, new starts forwarding to mobile.
Later mobile sends BU to home agent, etc.

Will mobile get a binding ack? Could come on old link or new, if old is
deteriorated.

Mobile initiated.
Mobile requests special router solicitation for new one. after that,
same as previous.

Layer 2 assist.
Layer 2 trigger at old causes binding update to new AR.
HAck returned. CoA is actually old CoA, mobile can't create
new CoA, old is valid at new AR for awhile, gets new.

Some variations.

Plans.

High level done, devil is in details.

New draft with solution section to be published by end of year

Regular drafts published as details get resolved.

Conference calls, face to face in January.

Finsh by Minneapolis.

Include more scenarios?

Merge of INRIA and HMIP

motivation: reduce MIP signalling, reduce signalling delay

one or more anchor points in hierarchy

LCOA on link, MAP CoA

MN binds LCOA w. MAP,

Packets intercepted by MAP nd encapsulated to MN.

HMIPv6 does not
 require new security assoc
 modify MIPv6

 no new protocols

 no special routers

 prevent a mn from using both modes.

2 modes:

1) basic, one MAP-COA per MN
2) MAP-COA belongs to the MAP subnet
3) Map intercepts packets to MN's COA

extended: MAP0COA is the MAP address
Map receives packets and forwards to LCOA
Less encapsulation overhead when RO is used
MAP is slightly different from a HA

Ch7 has a comparison why might need either

MAP discovery:

Dynaimc map discovery (should be secured)

Router renumbering extension

map optoin in a destiantion option sent to the ARs (from
the MAP or another node).

Implementaiton.

INRIA has a KAME and FDupont implement.
300 lines

Two implementations interop test in Connectathon.

Need an IPR statement at end.

can mobile node use MAP on link, eq. foreign agent.

Modifying router adverts? Adding an option.

No new protocol? Modifying MIP protocol,
didn't modify binding update.

Only supports one layer of hierarchy.

More than one layer of hierarchy, will select more than
one MAP, mobile needs to know which MAP to send to.

MAP sends packets to mobile node, encapsulate.

Restictions on MAP location in topology? HA only
works because is on same link, MAP sends option
with prefix, home agent may not need. Not subnet
that mobile is visiting, necessarily.

Two BUs to MAP and to HA. What about only one?

Why not just fast handoff? Doesn't reduce amount
of signalling. Would need to update BUs to
all CNs.

Map needs to know LCOA.

difference w. fast handoff - design team's fast handoff,
update previous access router, could also be elsewhere.

No provision for MAP to MAP, standard MIPv6 smooth handoff.

Flexibility of not having FA on first hop, not forced
to have hop by hop hierarchy.

v4 allos coloc coa. most usual case on subnet.

--------------------------------------------------------

Session 2:
::::::::::

A Framework for QoS Support in Mobile IPv6, Hemant Chaskar, Nokia

MIPv6 does not yet address QoS.  This is a proposal to perform QoS
signalling in MIP by introducing a QoS object as an IPv6 extension header,
where the object corresponds to one unidirectional packet stream.  Object
should describe required packet volume, and is included as a hop-by-hop
option.  Different approaches to handling MPLS, DiffServ and IntServ are
included.  Comments from floor that this is (or will be) reinvention of
RSVP.  Object would be sent end to end in BU from MN to HA and CN.

IPv6 Regional Registrations, Charlie Perkins, Nokia

Mentioned solutions to RR problems discussed in Pittsburgh.  The idea
is to reduce signaling to the HA and CNs.  The new approach uses an
anycast group as the destination of a BU.  This was challenged as not
being defined in IPsec.  The approach uses hierarchical anycast to
localize signalling, and can be viewed as a distributed, more robust
structure.  But unfortunately this approach nails down the data path
(like loose source routing) due to security requirement of BUs, and
thus does not have the robust properties that it might have
otherwise.

Mobile IPv6 ETSI Bakeoff, Vijay Devarapalli, Nokia

Report was given on what occurred.

Mobile Network Support in IPv6, INRIA, Thierry Ernst

Presented an approach for supporting mobile sub-network(s).  Mentioned
that with MIPv6 there is no way to send a packet to a mobile on a
mobile sub-network.  One solution is to send network scope binding
updates. Sender of BU must be the mobile router, and must authenticate
the BU as it manages the mobility of the subnet.  The solution raises
an issue of authorization, can the mobile router do this?  Does HMIPv6
solve this and is it a better solution?  It depends if MNs are mobile
aware ...take to the  mailing list.

Limited Private Address Support, Samita Chakrabarti, Sun

Private addresses are limited to mobile nodes only.  Mobile must obtain a
reverse tunnel with registration.  A MN must have a unique home address in
its home domain.

Paging Extension to Hierarchical Mobile IPv6, Regional Paging

MIP is bowing out of paging work for now according to chair in deference
to ongoing work in SeaMoby.  OUT OF SCOPE!

Registration Revocation in Mobile IP, Steven Glass, Sun

Original MIPv4 thought was that short lifetimes would be sufficient, and
denial of service holes would be present otherwise.  AAA has a requirement
that a registration be revoked immediately.   Termination messages must be
authenticated.  An easy solution?  Perhaps not, as the revoke beacon can
be spoofed.  Pitfalls...comments from Dave J. are that the DoS hole
should be closed.  Pat mentioned that we should do this with MIP
signalling and not ICMP signalling.  Should the hole in 2002bis be
documented in a separate draft?

DHCP in Mobile IP, Glass, Sun

Requires changes to HA only and not MN, FA or DHCP.   MIP Extension
proposed to carry full DHCP Ack.  Using one home address to renew/get
another requires turning the HA into a DHCP relay.  Unclear as to
whether/when this will become a WG draft.

Homeless MIPv6, Bengi Shalin, Ericsson

Bind sockets to dynamic address sets, not to single addresses.  Update
address sets via MIPv6 BUs.  Home addresses are not needed, hence the
name.
Home agents may still be used as points of contact, if wanted.  Relies on
DDNS, SIP etc. to be reachable (server-mode).

Intercepting Location Updates, Glenn Morrow, Nortel

Goals include simultaneous location privacy and route optimization.  Allow
a more realistic deployment of route optimization in IPv4.  CoA hidden
from CN by Network in new proposal.  Brings the redirection function
from the CNs to the last hop routers in the form of Correspondent
Agents (CA). Makes use of Router Alert bit in IPv4.  HMIP-type support
is also possible.
A router can be configured to ignore a router alert or not, and this may
be fast or slow path, or not.  The required SAs between routers are
typically already in place.  0-byte overhead tunnels (double NAT end to
end) are also proposed.  What happens if a wrong address occurs (memory
error), there is no recovery option according to Dave Johnson based on
past
WG examination, and who claims the proposed approach has been previously
discussed by the WG and rejected as not workable.

SGM Support in Mobile IP, Jiwoong Lee, Korea Telecom

SGM (implicit multicast) aims to help solve scalability of mobile IP
multicast.  Uses a level 3.5 header to enumerate the unicast destination
address of all mobile nodes.  IM packets can be sent from HA to FA COA or
to MN CCOA.  Assumes FA is not a mcast router.  If native mcast is
available, this is really not required as was pointed out by Alan.

Introducing Mobile IP in IPv4/IPv6 Interconnected Networks, Tsao, Siemens

Aims to solve problem of roaming between IPv4/IPv6 networks, homogeneous
and heterogeneous cases.  The basic approach suggests no new protocol, but
requires translation which is generally to be avoided if possible.
NGtrans is considering this issue as well, and George commented that
NAT should be used as an option of last resort.

Diameter Extensions to MIP, Charlie Perkins, Nokia

Gave an update of changes to the draft, including allowing a home agent to
be allocated in a foreign domain.

Mobile IP and GRE Enhancements, Pat Calhoun, Sun

GRE supports a key field used as a session ID and is multi-protocol.  I-D
defines two new MIP extensions, GRE key extension and the GRE type
extension, to enable GRE protocol type pre-negotiation on registration
prior to data exchange.

GSM SIM Authentication and Key Exchange for Mobile IP,  Havinen, Nokia

Useful to bootstrap MIP/AAA infrastructure off of existing GSMSIM cellular
infrastructure.  See draft if interested.

SA Establishment for Route Optimization in MIPv6, Hesham, Ericsson

MIPv6 mandates secured BUs.  This requires key exchange.  What, how, when?
IKE may be too heavy?  Proposal is not as secure as IKE, not intended to
replace IKE.  Involves one RTT from MN to CN.  Only works if CN has a AAA
server.  There is an IPR statement on this from Ericsson.  Number of
messages over the air is 4 or 6, but still less than IKE in aggressive
mode.

MIP WG Wrap up from Phil

MIPv4 handoff consolidation will begin.  MIPv6 handoff continues.  blah...

----------------------------------------------------------------------------
---------------------------

-Basavaraj
-Phil

---

From: "Lee, Jiwoong" <[email-masked]>
Date: Tue, 16 Jan 2001 09:43:48 +0900

From: "Basavaraj Patil" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 15, 2001 11:30 PM
Subject: [MOBILE-IP] Minutes of WG meetings at IETF49

> available, this is really not required as was pointed out by Alan.

Thank you for a comment.
Could anybody please technically explain the last sentence:

"If native mcast is available, this is really not required as was pointed
out by Alan"

for accurate understanding ? I'll admit it in a humble mind and reflect over
the problem again.

Thank you,
Jiwoong
Korea Telecom M.com