Last Modified: 2003-10-07
Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track.
Work expected to be done by the MIP4 WG as proposed by this charter is as follows:
1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be progressed towards DS.
2. Key exchange using AAA infrastructures for setting up security associations defined in RFC3344 will be completed.
3. The AAA WG, which is currently dealing with the Diameter Mobile IP application, requires the AAA NAI for Mobile IPv4. This work will be completed by the WG. The MIP4 WG will also work with the AAA WG to ensure that the Diameter Mobile IP application is aligned with WG requirements.
4. Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task.
5. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism), low-latency handover draft to experimental status and the completion of the MIB for the revised base Mobile IP specification (2006bis).
6. The MIP4 WG will also complete the work on Mobile IPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for Mobile IPv4 operation in the presence of IPsec VPN's.
7. Experimental message types and extensions for Mobile IPv4 in accordance with draft-narten-iana-experimental-allocations-03.txt has been proposed in draft-patel-mobileip-experimental-messages-01.txt. The work group will take on and complete this specification.
Other potential work items may be identified in the future but will require an appropriate recharter.
Aug 03 | AAA Keys for MIPv4 to IESG | |
Sep 03 | MIPv4 VPN interaction problem statement to IESG | |
Oct 03 | Low latency handover to experimental | |
Oct 03 | Revised MIPv4 Challenge/Response (3012bis) to IESG | |
Oct 03 | Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard | |
Nov 03 | Revised MIB for MIPv4 to IESG | |
Dec 03 | Revised MIPv4 specification to IESG for Draft Standard | |
Jan 04 | Dynamic Home Agent assignment protocol solution to IESG | |
Jan 04 | MIPv4 experimental extensions and message draft to IESG | |
Feb 04 | MIPv4 VPN Solution to IESG |
IETF58 mip4 Working Group Minutes ================================= Monday, November 10, 2003 1300 to 1500 Chairs: Henrik Levkowetz, Pete McCann Thanks to Sami Vaarala and Eva Gustafsson for taking great notes. - unclear things marked with XXX - '???' refers to one and the same person who commented on the mike but whose name i did not get mobile ipv4 agenda (henrik levkowetz and pete mccann) ----------------------------------------------------- introductions and agenda (pete) preliminaries (henrik) - work status web page http://www.mip4.org/ - draft status draft-ietf-mip4-aaa-nai-00 - reviewed by iesg, comments addressed in new text - one new issue by Bjorn Andersson - not re-submitted yet draft-ietf-mip4-vpn-problem-statement-00 - pretty much done, needs writeup by chairs, will send to iesg draft-ietf-mobileip-lowlatency-handoffs-07 - waiting for writeup, then to iesg draft-ietf-mip4-rfc2006bis-01 - waiting for mivp4 specific mib review - after that, mib doctor review, finally iesg draft-ietf-mobileip-vpn-problem-solution-03 - all comments addressed in latest version - but document needs peer review to go forward - wg chair review to be done soon - charlie perkins - what happened to the regional registration draft? - seems that since it is done, should be sent to iesg? - Defer this question a bit while chairs confer with ADs aaa key draft (pete mccann) ---------------------------- draft-ietf-mip4-aaa-key-01 - editorial mistake corrected in -01 - revisions from draft-ietf-mobileip-aaa-key-13 - clarify: for ipv4, not ipv6 - terminology cleanup - clarified what happens if reg. reply fails - iana considerations clarified - explicit security requirements for aaa key distribution infratstructure - next steps - one more ietf last call, then to iesg - charlie perkins - thought review was a response to iesg comments? - pete mccan - these were informal comments from iesg - alpesh patel - any work to support radius attributes? - pete mccann - There is ongoing work on the Diameter MIP4 application in aaa WG - mip4 not the place for RADIUS extensions, perhaps radiusext could take that work on experimental messages (alpesh patel) ----------------------------------------------- draft-patel-mobileip-experimental-messages-02 - problem statement - defines an experimental message, extensions and error code - used to aid interoperability before standardization - avoids overlap with reserved numbers - status -- -02 published - experimenteral message, extensions and error codes for mipv4 - where do we go from here? - henrik levkowetz - this problem has been added to charter, question is whether this is the proper solution for the problem - hum vote on whether this should be a work item => no hums in either direction - hand voting => no hands for or against - thomas narten - is there interest in this work, do people know the issue? - alpesh patel - recap of motivation for the draft - this is a problem, practical feedback from partners - charlie perkins - could not personally vote either way because had not read the draft - is this experimental? sometimes you want to experiment with two things, does the draft have subextensions - alpesh patel - yes, experimental - thomas narten - need to be able to experiment with protocols; chicken-and-egg problem, need codepoints but iana won't give you experimental allocations - alpesh patel - what if we need multiple numbers (e.g. two or three message types?) - thomas narten - you could need requests and responses to be experimental - alpesh patel - you can also use experimental extensions etc - henrik levkowetz - we already have subtypes for extensions - actually good to not reserve too many experimental numbers, because you want to limit the number of extension numbers you take for one single application - thomas narten - balance, you don't want to reserve too many, so that numbers don't become permanent. if number is small enough, numbers cannot become permanent - mobile ip has a history of having allocated without talking to iana, sometimes problems in standardization because numbers already iana - idea here is that for experimentation and testing you can do it the right way - henrik levkowetz - who's read the draft? ==> same hands that had an opinion - we'll need more feedback on this - please read the draft, chairs will post the question on the list in a couple of weeks issues with rfc 3344 (charlie perkins) -------------------------------------- - tracker for issues - issue 9: fa should not reject rrq with error code 136 - conflicts with language describring the use of code 136 - straightforward solution: new error code - this also provides the solution for issue 18? (no discussion) - issue 17: enhanced registration request processing at the home agent - what is the motivation for the proposed text? - error #129 is non-specific, #132 would do - idea: what the ha is allowed to do if it gets a rrq to a unicast address the ha does not own? - can't remember discussion why this would be interesting - pete mccann - some deployments where rrq might arrive at the ha maybe after being forwarded from another home agent, so the home agent address may not be set to any unicast address of the (final) home agent - in those case, proposal was to allow ha to process that request and return a success indication but fill in its own address in the reply - propose that we reject the issue - charlie perkins - agree, lot of recent discussion about ha failover in mipv6 context, starts to look like some sort of failover operation - also propose reject it - rejected - issue 18: the fa is rejecting with error code 137 which is meant for the home agent - proposal: create a new error code in range 64-127, which will then be a valid fa error code (no discussion -- accepted?) - issue 19: multiple authorization-enabling extensions should be permitted - suggestion: relax current restriction, we have multiple types of authorization-enabling extensions now - problem: what if one fails but other does not? - possiblity: the ha checks until it finds one that is verifiable? - proposal: table the issue unless motivation increases or problem is solved - what is the motivation? - which scenario is this a solution to? - not personally favoring changes to do this, introduces problems - no strong feeling about this - pete mccann - there are cases where mn has both mn-ha and aaa extensions out in the field today, should be ok to append more than one extension, might be to authenticate yourself to two different nodes in the network - charlie perkins - aaa authenticates use of charge card, and mn-ha authenticates mobility, for instance - pete mccann - reasonable use case - charlie perkings - can we require that all need to be verified, and must be rejected if any extension does not verify, different codes for different authentication failures - charlie perkins: - any other comments? (=> no) - will take to the list - issue 20: missing description - fa rejection code when mn-ha auth ext invalid - proposal: fa does not requre the existence of mn-ha extension, nor reject the reg req if it is absent - for this reason, related to issue 21 - is there a need for the fa to check "formatting" of the rrq? - the packet will be rejected anyway by the ha - rare case, imposing new requirements on the fa - suggest fa does not need to check the mn-ha extension (XXX) (no discussion) - issue 21: mn-aaa ext. not considered in fa-to-ha forwarding rules - proposal. reword to use "authentication-enabling" language instead - observation: if, in future, more such authentication-enabling extensions are defined, the fa may not be able to identify those extensions as enabling - suggestion: make sure that draft allows forwarding even when fa does not understand some new auth extension - want to avoid the situation where future authentication extensions would not work in the specified model (no discussion) challenge extensions (revised) (jayshree bharatia) -------------------------------------------------- draft-ietf-mip4-rfc3012bis-00 - changes from mobileip-rfc2013bis-06 - terminology changes, error codes renamed - defined/clarified order of mn-aaa auth ext when coexists with mn-ha existing in rfc 3344 - handling of solicited agent adv. at the fa is clarified - suggestions are added to security considerations to prevent invalidation of challenges caused by large number of agent soliciations pr bogus registration requests - editorial changes based on feedback from list - issue 1: potential deadlock for slow reg. replies associated with small (re)transmit rate at mn - occurs when mn is busy downloading some large file and trying to re-reg at the same time - first identification field is old when first rrp arrives (mn already sent a new rrq with new identification field) - proposals: 1. introduce retransmitted challenge whose value equal the challenge value used in the last req reg + some constant value, and let fa accept this retransmitted challenge as valid => potential security issues 2. reconfigure timer value at mn - pete mccann - this has been discussed on the mailing list - root cause is link buffer that is getting full - probably forward direction link towards the mn - timer X has been set too short; rfc 3344 says, rexmit should be longer than roundtrip time - proposal 2 used in the field, seems lower cost solution, least impact on standards - one implementation trick: keep context around for the old request; if you get a response to an old request, you can accept it if this is valid; this would also not affect the standards - should consider lower cost alternatives - charlie perkins - consider handheld device case, chances of (end user) reconfiguring the timer in a mn are slim; most people would not do that even if option offered - would like to see fa oriented solution - pete mccann - just increasing challenge window does not solve the problem; same challenge would not work? - charlie perkins - it makes sense, does not seem like a big security problem (XXX did not quite catch this) - jayshree bharatia - (XXX jayshree commented about the challenge being retransmitted, did not catch this) - pete mccann - because identifier changes it looks like a different request - maybe we want to relax fa so that even if challenge previously used, it would still be ok - we need to be careful with security considerations - don't think this is a matter of user configuration of the timer, more manufacturer problem so that the manufacturer configures the proper timer (e.g. 4 seconds), don't think that manufacturers are doing that correctly - jayshree bharatia - trade-off situation, rare scenario, the mn will most likely recover even without changes - henrik levkowetz - option 2 as a way to go? - charlie perkins - comment was just made that this is a fatal error and is recoverable - thrust of pete's argument is that depending on traffic, the timer should be done by the manufacturer to antipicate these problems - charlie agrees - issue 2: processing of the invalid challenge at the fa upon receipt of a registration reply from the ha - MN => FA: reg req, chal = x - FA => HA: reg req, chal = x - HA => FA: reg rep, chal = z - FA => MN: reg rep, chal = y - proposals 1. add text in sec. cons. regarding invalidation of the data supplied by the ha 2. discard received reg rep and send the reg rep with an appropriate error code once the time waiting for the valid response expires - charlie perkins - just wanted to expand on what the fa might do if it has bad format - for a long time we had problem that if fa messes with code in reg rep, so was wondering whether we might have an extension where the fa could say "dont want to change reg rep code, but here's the code i would like to use") - could have the original authentication data still verifiable, but still get the same data - henrik levkowetz - seems like the cleanest solution I heard so far - in favor of charlie's proposal - jayshree bharatia - (XXX take on the list?) vendor specific round up (henrik levkowetz) ------------------------------------------- - new possible charter item, currently a number of vendor specific extensions for mipv4, which is good - purposes of round-up - catalogue v-s extensions found in the wild - document purpoases and details of the messages - understand why necessary - see if there are commnon needs which new standard mipv4 extensions should be defined - not work on - v-s extensions that vendor does not want to share - link specific v-s extensions - is this a wortwhile effort for the wg to take on? - espen klovning - catalog would be nice, not aware of any actual vendor specific extensions - thomas narten - I initiated this - long time in ppp there was a similar situation, having a document that listed the extensions useful in debugging - simply provide information to people, but not necessarily take the work on - henrik levkowetz - we should add the debugging aspect - charlie perkins - might interact with iana work? Individuals might get assignments that they would not have gotten otherwise - thomas narten: - good question, if people are using same numbers improperly - charlie perkins: (XXX: did not get this) - pete mccann - clarification: charlie, are you talking about people who didn't use v-s extensions, but used the standards-track extension space without asking? - charlie perkins - yes - henrik levkowetz - since these are vendor specific, they are orthogonal to each other, no collisions, are and will continue to be owned by the respective vendors; if we standardize, we need to go through the normal routine and iana process - pete mccann - should not be a problem with iana - thomas narten - theory is that having more information is better than not having information - ??? - practically every protocol has vendor specific options, not sure if this is useful - thomas narten - not necessarily, if its useful they do it, if not, they don't - ??? - not ietf's job to find variations from vendors - pete mccann - will take cooperation of vendors, not a polling exercise to get extensions, vendors will need to volunteer - ??? - how we actually do this? - pete mccann - will need to use our contacts in the industry - ??? - the effort will be incomplete - pete mccann - some items are specificallty excluded, there is no intention to get a comprehensive list - alpesh patel - vendors can add proprietary information to messages - why would vendors tell that information? - henrik levkowetz - maybe they wont - alpesh patel - if vendors think extensions add value, vendor should try to standardize the extensions themselves, the working group should not do it - pete mccann - this effort could be best seen as a way to facilitate the process - thomas narten - are there interoperabilty issues here, e.g. people need to implement vendor specific stuff to make things work, sometimes vendor specific extension becomes de facto standard, so vendors just need to implement - not useful to have "the definitive list", but still might be a useful effort - henrik levkowetz - does the wg feel this is a wortwhile exercise? - for: a few, opposed: a few - no clear consensus => won't go into this at this time - pete mccann - if more interest in the list, might pick up later - thomas narten - do people feel there are issues with vendor specific extensions? - pete mccann - any examples? - ??? - example with a test suite vendor who has test suites for vendor specific extensions; ietf has nothing to do with it - henrik levkowetz - at my company, we have only had problems in this area only once, where we came across a v-s ext and could not handle it correctly; the ext was skippable, so the processing was fixed to skip - having skippable extensions makes this a non-issue for interoperability - pete mccann - we'll put this on the shelf for now, unless there is more interst on the mailing list dynamic ha assignment (alpesh patel) ------------------------------------ draft-kulkarni-mobileip-dynamic-assignment-02 - status - version 02 published - major changes from 01 to 02 - active interest from vendors - at least 2 working implementations - resolved issues / changes in 02 - terminology and editorial - loop free routing of rrq - load balancing by rejecting the rrq with special code and suggesting an ha - security consiederations - terminology and editorial - requested/assigned ha -- denote a single ha, indicates the meaning depending on the message type - redirected ha -- new ha that is being referred to for load balancing, administrative policies etc, when the reply message carries a special error code (TBD by IANA) - changed text to take care of "outside the scope" as in -01 - loop free routing of rrq - no ha redirection in network (as in version 01), ha could forward rrq to another ha - ha receiving rrq (assigned ha) may reject the request and point to a redirected ha - since ha does not forward rrq in network, no chance of same rrq looping in the network - also fixes a nat traversal problem - load balancing - requested ha can suggest an alternate ha to use by rejecting with special error code and redirected ha address in extension - if special error code is present, the extension carrying redirect ha address must be present - security considerations - since there is no redirection in network, fa receives rrp from the ha it fowraded to rrq (no address mismatch) - statement that "mn and all has may share same sa" removed - mn and ha can derive dynamic seucrity association - open issues - in extension carrying redirected ha address, including public and pricate ha ip address if available - would like to get feedback on this - questions ? - ??? - question regarding redirection, how do you redirect without knowing the status of the target ha? Could be redirecting into a black hole - alpesh patel - this is outside the scope, could be a heartbeat protocol, whatever - ??? - suppose that redirections start "bouncing" - alpesh patel - not enforcing that, management layer in mn could detect - ??? - protocol should take care of reconfiguration - alpesh patel - can be built on client side, mn can simply keep state of registration attempts and redirections - ??? - have to build state for each registration in the client, loop can be longer - henrik levkowetz - sounds like an earlier version of the draft, there is no forwarding of the rrq in the draft - pete mccann - i think the draft now puts mn in control of every reg retransmits, mn can decide what to do, much more in line with the end-to-end principle, and can detect config errors - henrik levkowetz - who has read the draft? (=> a few hands) - henrik levkowetz - the issue is within the wg charter, sooner or later we need to decide whether this draft is a good solution to the accepted problem in the charter - with the few readers who read, will not do this now - will solicit a few more people to read, then get feedback from list ipv6 in mipv4 tunnels (scott corson) ------------------------------------ Representing George Tsirtsis & Hesham Soliman draft-tsirtsis-v4v6-mipv4-00 draft-tsitrsis-v4v6-mipv4-00 draft-soliman-v4v6-mipv4-00 (incorrect file) - the problem - 1 - mipv4 allows ipv4 node to move in ipv4 networks - same for mipv6 (for mipv6 networks) - but internet is a micture of ipv4, ipv6, and dual stack networks, interop issues - best case scenario today - what works and what doesn't? - mipv4 => IPv4 and dual stack - mipv6 => IPv6 and dual stack - mn supports mipv4 and mipv6 => ipv4, ipv6, dual stack okay - but e.g. v4 => to v6 handover does not work => undesirable overhead, unpredictable connectivity - the problem - 2 - double overheads - inability maintaining sessions when doing v4/v6 handovers - mobility micromanagement impossible - solution: ds-mip - use mip as a v4/v6 migration tool - use the tunneling capaibility of mip to forward both ipv4 and ipv6 traffic over the same mip created tunnel - mipv4 extension - allow ipv4 and ipv6 hoas to bind to an ipv4 coa - mipv6 extensions - similarly - mn can use either ds-mipv4 only (initially), or ds-mipv6 only (future) (XXX?) - scenarios - ds-mipv4 scenario - ipv4 dominant - ds-mipv6 scenario - ipv6 dominant - ds-mipv4 and ds-mipv6 solution works with both ipv4 and ipv6 networks - james kempf - draft looks ugly, but maybe the problem is that the problem is ugly and requires an ugly solution - not too common to wander from network to another and change from v4 to v6 or vice versa - haven't seen a solution that looks nice - pete mccann - suggest that we adopt ipv6 everywhere? (:-) - james kempf - of course - would like to see more thought on this, alternative solutions - alpesh patel - couple of years ago there was a relevant contribution - draft from Pat Calhoun & others - pete mccann - participated in the draft, no interest at the time - i think the ds-mip approach solves some problems not in the previous draft - pete mccann - first exercise: do we want to add this to the charter? - henrik levkowetz - we will not make any decisions now - we'd still like to see who thinks this is an interesting problem to look at? - for: ~10 ? against: none (XXX) filters for mobile ipv4 bindings (carsten bormann) -------------------------------------------------- draft-nomad-mobileip-filters-05 - motivation - simultaneous use of multiple points of attachments on a single mobile device - mobile ipv4 - simultaneous binding, s-bit, duplicates traffic - if duplication is unwanted, only one poa can be active - one hand-off affects all flows - not enough ip addresses for multihoming - filtering for mobile ip bindings (nomad) - simultanous use of multiple points of attachment with a single home ip addresses without duplicating traffic - distribution of multiple flows / single flow - flow rejection - applications - load balancing - network management (flow mgmt initiated by core network) - enchanged terminal mobility (partial/smoothed handoffs) => better utilization of available network resources - idea: send filters from mn to ha, mn can specify which parts of data flow should be sent through which interfaces / points of attachment - mode of operation (slide illustrating modes of operation with different filters) - may have "competing" filter specifications, e.g. same filter but can specify that 20% to interface 1, 80% to interface 2 - also weights - dynamic format filters - nine types of filter modules, OR and AND between predicates - conclusions - do we want to do this work in this working group? - ??? - good idea, but have fundamental problems - how will you stop from requesting a large number of flows? - very complex filter policies, will affect traffic to every other device - carsten bormann - this is between mn and ha - ??? - no, can affect other mns, e.g. huge number of filters - carsten bormann - you can work around this - ??? - although theory is novel, not practical? - james kempf - i think this is a really bad idea; home agent is a convenient middle box, so we can do all nice things in the middle box [is often thought] - you don't have some of this information in the ip layer to do this, relevant information may be in the transport layer - i don't see any real usefulness - carsten bormann - several things in the question; are you addressing the case where one transport is through multiple connections, or several transports through multiple connections - james kempf - any case where you use multiple interfaces for other than sending traffic through them - don't think this is the right way to deal with the problem - pete mccann - i see some good motivations for doing this thing, we have many interface types which are suitable for different things; e.g. voice over 3g, data over wlan. if application can distinguish those things, app could control routing - but, not convinced that mobile ipv4 is the right way to do it, what if all interfaces are at home? Then there is no home agent to do the filtering, and we need another solution. - a bit confusing, not sure what is the right solution, should perhaps be independent of mipv4 - carsten bormann - many situations where you want someone in the network to do something for you, addresses james's comments as well. would be nice to have a general architectural approach for having this, a "friend" in the network to do this for you. - rsvp does something similar but is a one connection protocol. nsis is doing something similar. - if you have an identifiable thing in the network where to do this work, it might be a good place to do the changes; you could also have a completely separate protocol for doing this. seems to me that mobile ipv4 would be a good match for this problem. - henrik levkowetz - i have a couple of issues; first, basic idea of route appropriate flows over appropriate channels; i think really belongs in the end nodes, the appropriate would be to let applications select which interface to use - second, if you want to go down this road, you want to do this for other things than mobile ipv4 (signaling), this is completely incomplete as long as you don't have a way for applications to signal their needs and then some transport with filtering capability - multiple interfaces with multiple capabilities, don't do anything except in end node - carsten bormann - counter-argument is that much depends on the mobile node actually moving, so the characterization of an interface changes as the mobile node moves; not clear that you want to involve correspondent node architecturally - can you put this into one domain and without changing the correspondent node? from protocol point of view, ha seems like a good choice - i think there are good arguments for considering mobility aspects - james kempf - there are other possibilties in transport area for instance - point is that it's not wise to complicate the home agent by putting this functionality in; it's not clear that you get the necessary nformation at the ip layer to do this - one could consider another mechanism separate from mipv4 - henrik levkowetz - some aspects are enticing, but feel that there are good things but not sure it has "landed" completely yet - bof tonight - any more comments? (=> no) ----------------------------- - henrik levkowetz - agenda done, any more issues? - charlie perkins - loose question about the regional registration draft - henrik levkowetz - when mobile ip split to three groups, no-one took the draft - merit to go forward? - charlie perkins - several people asked, several requests on the mailing list - henrik levkowetz - true - charlie perkins - expectation was this would be published - thomas narten - should take this off-line, the document was expired and appeared to be dead when documents were divided - henrik levkowetz - we're done |