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.