Subject: [MOBILE-IP] minutes

From: Roberts Phil-QA3445 <[email-masked]>
Date: Thu, 13 Apr 2000 13:17:22 -0500

OK, here's a first draft of the minutes.  I'm still waiting for slides from
a bunch of folks.  I realize that a lot of you are just getting back from
Australia and I've heard a couple of people are having system problems, but
if you could get these out we'd really appreciate it.

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?

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
Informational appendix on limited "private" address support.
Realm identifier (similar to NAI)
Reverse tunnel Reg. Req. TTL=255 for security
HA discovery (Reg. Reply address used)

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.

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.com. 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-elmalki-soliman-hmipv4v6-00.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 [email-masked].

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, and the
answer
was that RSIP would be modified in the future and would be more compatible
with
this proposal. 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.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 14 Apr 2000 11:15:07 -0700

> lifetime field for use in both MN-HA and MN-FA key.

I also mentioned that we had proven interoperability of the draft
at the March Connectathon.

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 17 Apr 2000 09:31:29 -0700

some comments.

> Realm identifier (similar to NAI)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        this is not part of the appendix, just a discussion of possible
        future mechanisms, and it's not "similar" to nai, it's actually part
        of it (nai = user@ri already), i was just suggesting
        to expand slightly the definition of the ri.

> Session Two
                  ^^^^^
                  it's .org
> will be available at www.stardust.com.
...

> 12. GRE Key and Sequence Extension, draft-elmalki-soliman-hmipv4v6-00.txt

correct title is: draft-dommety-gre-ext-01.txt

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

...

> this proposal.

hmmm. not with this (PIPE) proposal.
i gave the answer, which i later tried to clarify, but obviously i was not
successful as what i said was something else:

        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 (that i know of).

> The AD wanted to know whether the allocation of a new IP
> protocol

this last statement is correct.

and bernhard said:

> just a minor comment related to Dave's question on PIPE and RSIP:
>
> I think my answer was that both are unrelated, since the RSIP server
> temporarily assigns a public IP address, so you do not have to cope with the
> handling of private addresses in this case.

well, with RSIP, in the most common case, there is only one public ip address
that must be shared, so the RSIP gateway must look beyond the destination
ip address in order to demultiplex. there are plans to extend RSIP to have
the gateway properly demultiplex IPinIP and GRE encapsulation, but not
PIPE encapsulation.

-gabriel