Minutes from Mobile IP at 47th IETF Adelaide
Thanks very much to Karim El-Malki(1st session) and Pat Calhoun(2nd session)
for taking the minutes for the working group.


Session One
-----------
1. Agenda Bashing & Status

NAI draft coming out as Proposed Standard RFC
MIPv6 to be submitted to IESG by mid-April
Vendor-extensions draft to be standards track
Challenge/Response submitted to IESG
MIER will be BCP or Informational RFC
AAA Requirements undergoing revisions, should go to last call soon.
RFC2002bis draft will be submitted to IESG in mid-April 

2. Dave Johnson - draft-ietf-mobileip-ipv6-10/11
Changes to MIPv6
Latest version 11 issued in March.
Number of changes:
- Outbound IPSec processing 
   IKE, order of headers, use AH/ESP/AH+ESP?
- DAD for Home Address
  away from home, returning home
  time needed to perform DAD for each new COA
  Must DAD always be performed in Mobile IP?
- Dynamic HA Address discovery
  new mechanism in v11
  new ICMP HA Address disovery messages
- other miscellaneous changes (HA list, Sequence number in BUs)

3. Erik Nordmark - Announcement on IPv6 and AAA discussion
draft-nordmark-ipv6-aaa-hooks 
Draft to be presented at IPng meeting
Issue: How does a MN know that it needs to use AAA and
which protocol to use?
Issue: How can routers use Host Routing - potentially for
mobility between links without changing IPv6 addresses?


4. Charlie Perkins - draft-ietf-mobileip-rfc2002-bis-01
RFC2002 bis
Changes:
- FAs should support reverse tunnelling
- More than 1 advertisement per second
- SPI number must be included as part of authentication
  calculation
- new appendices (number assignments list, change info, packet formats)
- ARP usage
Questions:
- Changes to TTL on RRQ with reverse tunnelling?

5. Gabriel Montenegro - Reverse Tunnelling
draft-ietf-mobileip-rfc2344-bis-00
Possible extensions to the definition of realm identifier
Reverse tunnel Reg. Req. TTL=255 for security
HA discovery (Reg. Reply address used)
Informational appendix on "limited private address support"

6. Tom Hiller - Mobile IP AAA Requirements
draft-ietf-mobileip-reqts-01
Revisions: Auditability, Fast Handoff, IPv6, mutual authentication
between attendant and AAAL (MUST), Real-time accounting,
dynamic SA establishment between attendant and AAA (if
pre-existing SA does not exist).
Questions:
Remove "dynamic SA" above?

7. Pat Calhoun - AAA keys draft
draft-ietf-mobileip-aaa-keys-01
Based on Generalized Key draft
MN-FA Key
MN-HA Key
Will use generalised Key extension which includes the
lifetime field for use in both MN-HA and MN-FA key.
Interoperability was demonstrated at the March Connectathon.


8. Pat Calhoun - draft-calhoun-mobileip-fa-tokens-00
former draft-calhoun-mobileip-min-lat-handoff-00
FA Keys encoded as Opaque Tokens for use in Handoff
Reduce latency of handoffs by having MN send keying
information to new FA (rather than having new FA contact
the old FA or contact the AAA)
May need Token Issuer NAI
Supports symmetric or asymmetric encryption
Questions:
Large message to send over the air?
How big is this key blob?


Session Two
-----------
9. Connectathton Results, Carl Williams, Pat Calhoun, Dave Johnson

Carl Williams discussed the outcome of the connectathon interoperability
event. 
There were 6 Mipv6 implementations, 5 Mipv4 and 4 DIAMETER. There were no
Mobile
 Ipv4 issues found. 

There were many presentations given at connecathon, which are available at 
www.connectathon.org. There was also an Ipv6 round table, which was taped
and 
will be available at www.stardust.com. 

DIAMETER testing of the base protocol, the Mobile IP extension and the
NASREQ 
extensions were successfully tested, as well as the NAI, Challenge/Response
and 
the Mobile IP AAA Keys Internet Draft.

There are plans for a follow on interoperability event in the next 6 months,

and the logistics will be made available in the future. 

The movement detection algorithm was purposefully vague in the draft, and a 
problem was found at connectathon due to one implementation. There is no 
current "good" solution for this, but the next version of the draft will 
include some ideas, which is a plea for ideas. 

10. Regional Registrations, draft-ietf-mobileip-reg-tunnel-01.txt Eva
Gustafson

The draft was presented, and there were no major objections. The new draft 
has removed two messages, and Eva would like to receive comments on whether 
this is a problem.

11. Fast Handoffs and Routing in Hierarchical Mobile IP,
draft-elmalki-soliman-hmipv4v6-00.txt Karim El-Malki

This draft proposes changes for Mobile IP v4 and v6 and introduces fast 
hand-off. The Mobile IP v6 proposal requires changes to the detection of 
whether a Binding Update should be sent, and it requires that the MAP be 
advertised to the Mobile Node. It was noted that this could be used to
create 
a Denial of Service attack.

12. GRE Key and Sequence Extension, draft-dommety-gre-ext-01.txt Gopal
Dommety

This is an update to RFC 1701, and the latest proposed standard version, 
RFC 2784, no longer includes the key and sequence numbers. However, the 
draft-ietf-mobileip-3gwireless-ext requires the key and sequence number, so 
the new standards track RFC does not work with the Mobile IP work. This is 
discussed in gre@ops.ietf.org.

This re-introduces the K and S bit. When the K bit is set, the Key field is 
present. When the S bit is set, the four-octet Sequence field is present.
The 
sequence number is to provide unreliable in-order delivery. Out of order 
packets SHOULD be silently discarded (re-ordering is outside the scope)

13. Local and Indirect Registration for Anchoring Handoffs, Gopal Dommety

In wide area deployment, the handoff latencies could be high. This draft 
reduces FA-HA messages, establishment of secure tunnels as well as 
establishment of FA HA security keys. This draft includes local and indirect

registration, and the anchoring is intended to reduce latency.

Authentication and authorization is done using AAA. Dynamic keys are 
established using IKE and/or Mobile IP (KDC, AAA). The IPSec keys use 
pre-shared keys or PKI. The first FA that is registered with is known as the

anchor Foreign Agent. When the Mobile Node moves to a new Foreign Agent, the

registration is forwarded to the anchor foreign agent.
 
There are some questions as how this scheme supports anchor points that
fail. 
Gopal stated that he will look at adding some reliability in the next
version. 
The anchor point can change at any time, when prompted by the Mobile Node.
 Cisco has claimed a possible IPR on this technology, but Dave Johnson had 
already documented a very similar scheme in 1996, and could be used for
prior 
art.

14. Private IP addresses in Mobile IP, draft-petri-mobileip-pipe-00.txt
Bernhard Petri

If private addresses according to RFC 1918 are used, a receiving agent, or 
mobile node will only detect that it is a private address, but will not
know, 
to which address realm it belongs unless a particular realm is
pre-configured). 
Similar problems for overlapping/non-routable corporate address ranges, even
if 
not private. Corresponding nodes and mobile node are in disparate address 
spaces. FA offers support of address reams different from the one it uses to

communicate with HA.

An extension of IP-IP tunnels, allowing handling of private addresses by 
adding a kind of address realm ID for the inner IP addresses. The basis for
a 
possible Mobile IP solution to handle private addresses, but not all
detailed 
Mobile IP extensions are outline in the draft. PIPE does not provide for:

How to cooperate with existing RFC 2002 MIP agent/node 
Solution for other types of tunnels (GRE, etc)
Address translation/NAT functions for private addresses

This PIPE protocol introduces a VPN Identifier, which is a 3 byte OUI and a 
4 byte index. OUI is an IEEE managed identifier. See 
http://standards.ieee.org/regauth/oui/index.html for more information. The 
VPN index is a value for network or address realm, allocated by owner of 
VPN-OUI. IANA could use its own OUI, and allocate space from the VPN Index.

The author would like to move PIPE towards an Experimental RFC for the time 
being, and possibly consider the P bit and the work in RFC2344-bis in the 
future. The AD asked whether this proposal would work with RSIP?  The answer
is:

RSIP will be augmented with the capability to handle mobile ip with
some private address support as per rfc2344-bis with IPinIP and GRE
tunneling,
but *NOT* to handle PIPE tunneling. so, PIPE support for RSIP is not
planned.

The AD wanted to know whether the allocation of a new IP protocol
 from IANA for a short-term fix was appropriate. The answer is that a number
is 
already allocated. Someone made a note that this is not IP in IP, since it 
introduces a new IP protocol type. Another comment was made that RSIP could
not 
work because this is not IPinIP.

15. Mobile IP in 3gWireless, draft-ietf-mobileip-3Gwireless-ext-02.txt
Yingchun Xu

This was already presented in the previous IETF, so only the changes will be

discussed.

Managing BTS Handoff (within access network)
Managing PDSN Handoff
Managing RNN Handoff

This draft borrows Mobile IP messages and extensions, and defines a new 
Extension that is session specific. This draft makes use of GRE payload 
tunneling. There are two messages for tunnel teardown.

There have been revisions from the last version:
        Different UDP port for RP interface
Adding IANA section to identify the well known UDP port, and the new 
extension and messages.
Defining a new Mobile ID type within session specific extension to identify 
IMSI coded in ASCII.
Minor changes of registration acknowledge message format.

The only pending issue is the new GRE format draft.


16. Route Optimization, draft-ietf-mobileip-optim-09.txt Charles Perkins

This is an update on the new draft. The basic features are 4 messages to 
handle binding updates, smooth hand-off, a new advertisement bit and the 
handling of mobility unaware IPv4 nodes.

Changes:
·       Use of generalized authentication extension subtypes instead of 
        separate type numbers
·       Introduces smooth handoff authentication subtype (needed since
foreign 
        agent is source address, not mobile node)
·       Introduced a binding warning extension to registration request with 
        type number.
The Home Agent MAY send binding updates whe na mobile node moves.

Issues:
·       Binding update should be used instead of registration messages in 3G
·       Interoperability testing.


17. Registration Keys draft, draft-ietf-mobileip-regkeys-01.txt Charles
Perkins

Security associations are needed between the FA and the HA, this can be done

via PKI for FA or mobile node, Diffie Hellman. AAA is not considered, but 
Mobile IP and smooth handoff should be able to work in absence of AAA.

The use of the MIER Generalized Key distribution extension is now used. 
Elliptic curve is now a default. Diffi-Hellman between the FA and the HA. 
Advertise digestified D-H computed value, and includes opaque date handover 
in algorithm.

Issues?
Source code for elliptic curve (are there patents?)
Interoperability testing?
Should HA know the Mobile Node's public key?
Using derived keys
Non-default D-H parameters?
Better challenge handling for more man in the middle cases?

18. Universal Mobile IP, draft-wang-mobileip-umip-00.txt John Wang

The 3G vision is to make use of Mobile IP, and the idea is to have cheap 
devices. Best effort quality of service is not good enough for Mobile IP. 
2G are incompatible, not integrated and not efficient. 3G needs an
integrated, 
efficient, ubiquitous solution that includes user mobility and has high QOS.

The existing IP solutions for user mobility have negative impacts, such as
time 
delays, jitters, network efficiency, QOS and cost. 

UMIP has a simplified, low cost and long battery life solution. UMIP
proposes a 
location chain setup process, and makes use of a hierarchical approach.

19. Generalized NAI, draft-mkalil-gnaie-00.txt Pat Calhoun

This draft introduces a MIER-style extension, that allow sub-types to be
used 
to specify NAIs. This draft will become a WG work item if there are no
issues 
on the mailing list.

20. Mobile IP Session Identifier Extension, draft-ietf-mobileip-optim-09.txt
Pete McCann

There are a couple of problems with the current Home Address allocation 
schemes, and this draft attempts to solve them. It also allows multiple 
bindings, such as two interfaces on the same host. The Session ID extension,

hold an identification string for the session. The HA uses it to make
address 
allocation decisions.  The Identification field cannot be used because it is

used to identify retransmissions. When you return home, you should be
allowed 
to keep that address, so this draft defines how that can be achieved.