NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
Phil Roberts <phil.roberts@motorola.com>
Basavaraj Patil <basavaraj.patil@nokia.com>
David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>
David Oran <oran@cisco.com>
General Discussion:mobile-ip@sunroof.eng.sun.com
To Subscribe: mobile-ip-request@sunroof.eng.sun.com
In Body: (un)subscribe
Archive: http://www.nortelnetworks.com/standards
The Mobile IP Working Group has developed routing support to permit IP nodes (hosts and routers) using either IPv4 or IPv6 to seamlessly "roam" among IP subnetworks and media types. The Mobile IP method supports transparency above the IP layer, including the maintenance of active TCP connections and UDP port bindings. Where this level of transparency is not required, solutions such as DHCP and dynamic DNS updates may be adequate and techniques such as Mobile IP not needed.
The WG moving forward will focus on deployment issues in Mobile IP and provide appropriate protocol solutions to address known deficiencies and shortcomings. For example, the wireless/cellular industry is considering using Mobile IP as one technique for IP mobility for wireless data. The working group will endeavor to gain an understanding of data service in cellular systems such as GPRS, UMTS, CDMA2000, and interact with other standards bodies that are trying to adopt and deploy Mobile IP WG protocols in these contexts. In order to provide a complete solution and a set of protocols that can be used as a roadmap for widespread deployment, the following work needs to be accomplished by this WG. In the near term, the WG needs to work on:
- Use of NAIs to identify mobile users/nodes.
- Specifying how Mobile IP should use AAA functionality to support inter-domain and intra-domain mobility.
- Develop solutions for IPv4 private address spaces for the scenarios needed for deployment.
- Documenting any requirements specific to cellular/wireless networks.
In the longer term, the WG needs to address:
- QoS in the mobile IP environment using diff-serv and/or int-serv/RSVP.
- Location Privacy.
The Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively.
Done |
|
Review and approve the charter, making any changes deemed necessary. |
Done |
|
Post an Internet-Draft documenting the Mobile Hosts protocol. |
Done |
|
Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility. |
Done |
|
Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard. |
Done |
|
Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard. |
Done |
|
Submit Internet-Draft for NAI support in Mobile IP to IESG for consideration as a Proposed Standard. |
Done |
|
Review security framework requirements for Mobile IP. |
Done |
|
Review solutions and submit drafts for mobility in private address spaces. |
Done |
|
Supply AAA requirements for Mobile IP to the AAA Working Group |
Sep 00 |
|
Submit the IPv4 Mobile IP Protocol to the IESG for consideration as a Draft Standard. |
Oct 00 |
|
Review the WG charter and update as needed. |
Dec 00 |
|
Develop an access technology independent method for supporting low latency handover between access points within an administrative domain or across administrative domains. |
Jul 01 |
|
Review QoS in a Mobile IP enabled network. |
Aug 01 |
|
Submit Mobile IPv6 MIB to IESG for consideration as a Proposed Standard. |
· Route Optimization in Mobile IP
· Mobile IP Regional Registration
· AAA Registration Keys for Mobile IP
· IP Mobility Support for IPv4, revised
· Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network
· Mobile IP Extensions Rationalization (MIER)
· Generalized NAI Extension (GNAIE)
· Hierarchical MIPv6 mobility management
RFC |
Status |
Title |
RFC2005 |
PS |
Applicability Statement for IP Mobility Support |
RFC2004 |
PS |
Minimal Encapsulation within IP |
RFC2003 |
PS |
IP Encapsulation within IP |
RFC2002 |
PS |
IP Mobility Support |
RFC2006 |
PS |
The Definitions of Managed Objects for IP Mobility Support using SMIv2 |
RFC2356 |
Sun's SKIP Firewall Traversal for Mobile IP | |
RFC2794 |
PS |
Mobile IP Network Access Identifier Extension for IPv4 |
RFC2977 |
Mobile IP Authentication, Authorization, and Accounting Requirements | |
RFC3012 |
PS |
Mobile IP Challenge/Response Extensions |
RFC3024 |
PS |
Reverse Tunneling for Mobile IP, revised |
RFC3025 |
PS |
Mobile IP Vendor/Organization-Specific Extensions |
Thanks to David Frascone for providing the meeting minutes of the Mobile IP WG meeting at IETF50.
Thursday, March 22nd 2001 - 9:00 AM - 11.30 AM
----------------------------------------------
Basavaraj:
>> Agenda bashing:
Modifications to the published agenda. Steve Glass unable to make it to this meeting.
WG mailing list has been moved to a new server hosted by Sun. Archives are in the process of being transferred. Steve Glass has agreed to administer the list.
>> WG Doc status:
New RFCs: 2034 (Obsoletes 2344) - Reverse Tunneling
RFC 2035 Vendor specific extensions
Drafts: mobileip-ipv6. Blocked by IESG for security concerns.
2002bis passed last call.
mobileip-gnaie - In IESG bin.
Drafts in Limbo:
mobileip-mier.
Drafts that have completed last call:
mobileip-optim
reg-tunnel
3gwireless-ext
Drafts going to WG last call
mobileip-key-aaa
New WG documents
glass-mobileip-reg-revok
mobileip-lowlatency-handoffs-v4
mobileip-fast-mipv6
>> Milestone Review
>> IESG Security concerns with MIPv6
Thomas Narten has sent out the IESG statement to the Mobile IP mailing list which notes the issues identified w.r.t security for the Mobile IPv6 spec.
9:14 - Jeff Schiller - Security and Mobile IPv6
------------------------------------------------
Discussed the security issues from the perspective of scalability and the way IPSec is used in Mobile IP.
How can we tell the difference between legitimate updates and attackers.
IPSEC/AH?
It's an authentication protocol. Can't it be used?
Bottom line: IPSEC is not a good fit for a situation where you want to protect some packets, but not all packets.
IPSEC has a policy database to determine whether to send the packet encrypted or authenticated. It's an all or nothing type of approach.
Other bad things with IPSEC:
KEY negotiation requires several handshakes
State
No protection against man in the middle
Requires PKI based on IP addresses
And, it is not ready now . . .
No telling how long it will take to build a PKI architecture.
IPSEC is used today to build VPNs. In them, the admins usually set up a private PKI. But, how do you do a PKI on the scale of the internet?
Minimal Requirements for Security:
No security exposures beyond today's IPv4
But, why not do it better?
Man in the middle attack "ok" if launched by an attacker in the path.
Protecting against this is very hard.
We eventually have to solve this problem when wireless takes off.
PBK: One approach
Purpose Built Keys.
End point creates public key pair and EID.
EID is hash of public key.
Fixed length, reasonably short.
Send the EID to the correspondent node.
Correspondent node ACKs.
EIDs and keys change to provide privacy
Once EIDs are known, then you can authenticate any packet you want by signing the update with the private key, and transmitting the public key in the update. Since the EID has already been sent, then the binding update can be verified, and the EID can be checked by hashing the public key.
HIP (Host Identity)
Similar in ways to PBK.
Designed to solve a more broad problem.
Is an architectural shift.
Can be made to solve the binding update. . .
Security AD hat on:
No solution is particularly favored.
Security requirements must be met.
Punting security is not an option.
IESG position:
See AD position :)
For the extended debate and questions, please look at section A1 of these minutes.
Connectathon Report:
---------------------
Alper Yegin:
What Connectathon is . . .
14 mobile ip participants
9 ipv6
6 mobileip v4
3 test suites for v6
1 suite for v4
IPv6
8 correspondent nodes
6 HAs
4 nodes
IPv4
6 agents
3 nodes
Observations: Specifications on movement detection need to be looked at. Different interfaces of the same router can have the same MAC address, therefore some link-local address.
Sending Binding Update Acknowledgment. What if the COA was invalid or multicast or unspecified.
HA address discovery. We don't need to send the home address since it's the same as the destination address.
Someone: There was an agreement on the list to remove that . .
Timing issues with BUs - can be fixed in implementations.
ICMPs can delete binding cache (destinations unreachable)
Attackers can forge these, and delete all the binding cache entries.
Deregistering of Care-Of-Address.
Carl Williams:
Only had one participant implement IPv4 route optimization.
Observations: Might need a blurb that the FA may check the existence of the MN_HA Auth extension.
FA could override an error created by the HA. if the FA_HA authenti-cation is invalid, and the Home Agent was already returning an error.
Charlie: I don't know if there's anything to be done.
One implementation upon error would set the lifetime to zero.
Reverse Tunneling Private addressing - the RFC was not clear that the private address support was mandatory, since it was in the appendix.
Basavaraj: Samita is working on a draft that clarifies this.
Should Failed registration replies contain the challenge? Pat will fix the text
How does the FA track the challenge sent to MNs that solicit for advertisements?
Final coments: Issues with agent solicitation. Dynamic home address allocation -- Who should give out the addresses? AAA or HA?
Handoff Discussions
-------------------
>>George Tsirtsis(IPv6 fast handoff):
We have made changes to the design team draft. We have a new type called fast binding update. The other change is that there is a new type for advertisements.
Michael Thomas: Is this the fast v6 handoff? Brought up an issue on the seamoby list. What you are in fact doing is context transfer.
You're loosing flexibility on fast mobility. There may be cases where you don't want the routers know about each other.
If the problem is solved already, why
Someone: Your objection is to the transfer.
Design team guy (DT): The only purpose of the ICMP is to get the COA of the mobile.
Michael Thomas (MT): It is moving the state. What is being positive here is a vessel for what seamoby should be doing.
Basavaraj: The packet *could* be used for context transfer.
But, we're not doing context transfer.
MT: But now, we'll have two different messages sent to move a mobile node.
Eric Nordmark: Charter issues are not a good use of our time here.
Next steps - Face to face meeting . . . as soon as next week.
Discuss ping-pong, bucketing, resolve comments from mailing list, release a new version.
Someone: As soon as the MN gets a new layer2, it should be able to send packets right away. Currently to rely on the neighbor advertisement adds a round trip time.
George: We are looking into some optimizations.
Someone: If mobile node has packets to send, then it needs to be able to send them. Even though it can't receive yet. (Until the update is finished)
MT: There are three things going on. I think it would be very useful to decompose them so that you can choose to do any of the three, but not be required to do all three.
George: It is very tightly coupled.
Gopal: The messages are not tightly coupled . . . . or maybe they are.
>>Karim:
Low latency handoffs in ipv4
Compilation of the fast and pro-active handoffs.
Current draft is just the combination.
There are new comments from Monday design team meeting.
Requirements: Decrease L3 handoff disruption. Limit dependencies on L2s.
Two methods:
Network Assisted Mobile and Network controlled (NAMONIC)
Network Initiated, mobile Terminated (NIMOT)
Work ongoing trying to get the two methods more integrated.
Planed additions:
rewrite intro
include L2 trigger chart
Make methods independent of Regional registrations
move RR application into new section.
move bicasting to new section
NAMONIC Mobile Initiated: new extensions to roxy) Router solicitation to include L2 ID (eg. AP ID)
Michael Thomas: It would be nice if the terminology between the IPv6 and IPv4 were the same.
Jim: I think the terms should be the same, but don't merge v4 and v6 hand off documents.
Gopal: I don't think there is any need for hierarchical stuff in this draft.
Design Team(DT): This is to make IPv4 handoff faster.
Gopal: A proxy registration will also make it fast.
DT: Take it to list.
Someone: Hierarchical MIP helps you with the handoff? Is that what you said?
DT: It *could* help reduce the latency.
Someone: It doesn't go any faster than basic fast handoff
Pat: We didn't put hierarchical in the draft to make it faster, we did it to show that it could coexist.
Someone else: In bicasting, it is assumed that you know the new COA, right?
Mikael Dagermark: E-mail archive website doesn't work.
Phil: It's being worked on.
Someone: Are design teams closed?
Phil: Yes.
Pat: I don't think the V4 group is closed .. . don't even think it exists anymore.
Phil: take it to the list
>> Youngjune Gwon
L3 triggering.
L3 triggering provides the mobile with the best next future agent to send a solicitation to. L3 process may be independent of L2 information.
Why use this?
Access L2 diversity (WLAN, RAN, etc)
Changes in L1/L2 affect L3 minimally . . faster deployment
Inter-access technology handoffs
Useful if L2 triggers not possible.
Operational Summary
Network layer mobility prediction
L3 per packet latency prediction
access point selection
- next agent selected -
Architectural assumptions
Latency must be measured between MN and BTS
MN is able to listen to different Base stations simultaneously
L3 signaling is essential .. . L2 signaling is even better.
Multi L3 links to BTSs
Multiple L3 entries possible for same L2 link.
L3MP - Latency prediction
- Access point selection.
Latency measurement
Router advertisement packet
Simpler packet format using ICMP timestamp (ping)
IPHeader with agents ipaddress
authentication (optional)
Discussion at end of this report in section A3
Improving network renumbering in MIPv6
--------------------------------------
TJ Kniveton
Today's situation
Draft 13 shows how to renumber
There were some issues . . . we're going to present our solutions:
Tunneled router solicititaions are sent from the HA to the MN when the MN is autoconfiguring.
Problems: Bootstrap - The MN is autoconfiguring itself. MN should not use unspecified address - Hard to form security association.
Problems: Efficiency - Encap. seems to be a way to get around the TTL issue. Excessive info is sent to mobile node. Encap not necessary.
Available Options
Bootstrap Issue
Relax neighbor discovery TTL rule.
create a new rule for processing unicast.
or
Create new ICMP types for mobile router solicitation and router advertisement.
Recommendation
Create a new ICMP type
Other issues like flag cleanup, redefining and simplifying rules for prefix inclusion, and simplified rewording are also recommended.
Michael Thomas (MT): These sort of things (tunneling) security really does matter. You need to not ignore the security issues. [ed: TJ was flippant about the auth header being left off of his diagram]
TJ: agreed.
Charlie P: Maybe it is advisable to not use AH, but include auth data fields. (from previous sec. problems with AH)
MT: The situation between the HA and MN is not the same problem of the MN to the Correspondent Node.
Charlie: I think we agree that the MN and HA already have a sec. assoc. I was just saying that we won't be using the bit format of AH
TJ: There is a broader issue with bootstrap. If a mn boots up on a foreign network, how does it know it's HA?
HMIPv6
------
Hesham Soliman
Motivation / Requirements
Reduce mobile ip signaling load
improve mobile ip handoff delay
location privacy
route optimization for mobile networks
minimal impacts on mipv6 and or ipv6
reliability (robust routing)
scalability
Changes from last revision
Introduced load balancing
additional support for location privacy
an optimization to allow the MN to encapsulate the HA BU into the MAP's BU
General editorials
Load balancing
If across access technologies, a new sub option goes to the MAP and requests that a particular connection go to the other net. Maybe even per-packet load balancing could be useful.
We put it in, but we believe that it's not a good idea.
Detailed discussion in section A2.
>>Two more scheduled timeslots had to be cancelled as the time allocated for the WG ran out. The other two slots were:
1. Dynamic configuration of Mobile hosts (Sandy Thuel)
2. QoS Discussion (Hemant Chaskar)
============================================================================
A1: Security in MIPv6 discussion
--------------------------------
Questions:
The larger problem is address ownership.
Charlie: Likes minimal requirement :)
We should meet minimal as soon as possible. Other requirements are extremely difficult to meet. Especially when three parties are involved. Whatever we come up with we need to be fast and simple. Any key establishment we set up might be vulnerable to man in the middle.
Jeff: Agrees with Charlie in general. But, it's up to the WG to pick a proposal.
We want something that can be implemented by every correspondent node, and is easy to implement.
Jeff: Minimal requirements have a problem because we're saying a man in the middle attack is ok. Today this is the minimal requirement. In another year, it might not be the minimal requirement.
There are a number of ways of doing it, and they all have advantages and disadvantages. We need to find AN answer that meets the requirement, and go with it.
Jeff: But, if we pick one, and it turns out to be vulnerable, we might not be able to fix millions of devices who's algorithms might be in ROM.
My *oops* e-mail has an approach that meets the minimum requirements and only uses MD5.
AH comment: AH doesn't do what we want to do because we'd have to do it on every packet, only the ones with binding updates on them. I thought the SPI told you how to carry out the authentication. So, what's the problem? Maybe we just need to slightly change AH to pick out the right association and use only authenticate the proper question.
Jeff: That is not a discussion for this working group. If you receive a packet with no AH header, how do you know if you can accept it based on IPSEC. One could fix that, but it would not be soon. (See previous comments on "timely")
Someone: What's required now is a design team. That design team should include implementers, not just abstract architecture people. We need your view on what IPSEC does. How do we not misuse AH again? This is FUBAR and should not have happened. Could we do a mock last call on the rest of IPv6, we need the spec on the market. 3gpp is waiting on it.
Phil: It's already gone through last call. It's just waiting on security.
Moskowitz: HIP will allow for man in the middle protection if one of the parties is not anonymous. So, if the MN knows the HA, then it can be avoided.
Francis: Allowing for man in the middle attack makes the minimal requirements too easy. The problem of PKI is difficult problem. Perhaps we want too strong security. It's easy to avoid the man in the middle attack . . . . hard to understand.
Jeff: To guard against man in the middle you only have to authenticate strongly one side. Perhaps you should strongly authenticate the correspondent node, and put his public key into DNS. If DNS security is deployed, then we get a security upgrade, and it's protects against man in the middle.
Michael Thomas: Authorization is not the same asAuthentication. Even if we could authenticate, it does not say who is allowed to have a particular address.
Jeff: If we're not careful, we could get into a case of diminishing returns. In practice traffic re-routing is not a problem. Why would you want to send your traffic somewhere else. There is a problem if you can say "send that guys' traffic to me"
Michael: The schemes that are floating around require a reachability test. What I don't understand about PPK draft is, "What are the public keys giving you beyond what the reachability gives you?" What's the difference between that and symmetric keys.
Jeff: Correspondents don't have to store large numbers of secrets.
Michael: So, basically it's a memory vs cpu issue.
Jeff: And, the mobile node doesn't have to keep state.
Someone: I have no expertise in key exchange/generation, but I'm curious about the AH problem.
Someone else: I'm not a fan of triangular routing. I want to make sure no one has called into question the security between home agent and mobile node. We need to get this right. Don't rush it, even if 3gpp needs it now. They can live with triangular routes until we solve this problem right.
Phil: From now on, only questions specific to this point, not ways to solve the problem.
Someone: The requirements are the same ones that we had for IPv4. But, barely good enough security was considered no longer secure enough for route optimization. So, now suddenly, it's ok again?
Jeff: I can't comment on the history. If I had it my way, I'd want something much stronger than this, but I'm willing to compromise.
Someone: Mobileip is out there. It's been through several last calls.
Jeff: We need to move forward. Why rehash the past.
Someone: But, why is the IESG doing this now? Maybe that's our fault, maybe IPSEC's fault. But, we need to do it right this time. Not do all the machinications and at the last minute get held up again.
Jeff: The IESG is VERY busy. Let's not try to design process to deal with a point solution, because tomorrows problem will be different.
Gabriel: I like the PPK basic idea. What I think would make it even stronger would be to do the homework. HIP has been working for over a year. We need to do a little bit more architecture to him (and not solve the point problem) so that mobile IP and other protocols could leverage it. If you do the homework on PPK, you'll probably end up with something very much like hip.
Someone: I think cookies are sufficient.
Charlie: There are two possible ways to get done. one is to put out a ipv6 spec that doesn't require AH any more, but requires some kind of binding key. Then, release another draft on how to come up with the binding key. That way, IPv6 can go through last call, and the security will not hold it up.
Jeff: To see if security is secure, you have to do an analysis.
Charlie: But, I wasn't talking about the algorithm, I want .
Jeff: What I want is for it to be secure.
Charlie: But, what you do is put out a draft, and then decide how to make a binding key later.
Jeff: I think you have to have a complete solution.
IPSEC guy from sun: There were some comments as to whether AA was appropriate, or IPSEC was appropriate. Most implementations made tradeoffs for simplicity. Adding complexity there is not something we're interested in doing. So, not authenticating binding updates is not good enough
Phil: We will be setting up a design team.
A2: HMIPv6 Discussion
----------------------
Michael Thomas: Using terms like "Mobile Routers" is not a good idea, unless you consider hosts behind them, and mobile routers behind mobile routers.
Hesham Soliman (HS): Leaving that part out doesn't bother me.
Someone: Increasing robustness creates delay.
HS: Solution should be as robust as possible. .
Someone: In the presence of fast handoffs, this does not provide any improvements in delay.
HS: Agreed.
Jim: Charlie sent good comments to the list. I think that the load balancing really needs to go. It is dangerous. In general it needs some editorial work. There are lots of ideas in here, and probably needs to be cleaned.
HS: I think that the comment about load balancing should not be used with TCP can be removed.
Jim: There are two requirements that I didn't see there: Signaling and per packet overhead must be reduced. And, arbitrary levels of hierarchy must be possible.
HS: overhead was to be solved with header compression. We'll take that to the list.
Jim: I don't know of any evidence that header compression will work on mip packets. . .not that it won't, but it needs to be studied before we rely on it.
Jim and HS - go offline.
Someone: If you're making a routing decision on a packet or port, then it's a Layer four switch. Changing that policy dynamically (what you're suggesting) is not routing . . it's embedding single points of failure in the network.
Someone else: I agree that any level of hierarchy is bad. I want to raise a couple of issues about scalability. I fyou're using only one layer of hierarchy, your signaling the one route you choose. And if you change the route you register with all the corresponding nodes. So, this means that in the design you specified you support only one box, and you overload other functionalities like bicasting and load balancing.
HS: So, the issue is using one box? I haven't seen any other proposal that uses more than one box.
Charlie: I don't like having two modes of attaching a coa. the coa in the map, vs the coa in a little source route. I don't think the mn should have an address on a network that he knows nothing about. So, my proposal is that the basic mode be removed, and the extended go forward.
One other note is that the draft talks about too much. It doesn't need to talk about configuring the routing network, load balancing, smooth handovers, aaa, etc
HS: We just mention them, we don't discuss them.
phil: There is a lot of feedback about the draft. We need to take this to the list, and decide what really belongs in the draft.
Samita: will take her comments off line.
phil: Did not get to dynamic configuration, qos, and agenda.
A3 : draft-gwon-mobileip-l3mp-mipv4-00.txt)
-------------------------------------------
Similar to other handoffs, except it is triggered by L3 predictions.
Jim: This is not independent of the L2 access technology. All this is doing is sending a beacon. RFC2002 says that it is ok to beacon. The reason we have fast handoff discussions is because this is not fast enough. This is not L2 independent. In 802.11 you can not choose access points, you don't have control over it. This will not work on a wireless lan.
Alper: How can you map L3 latency to L2?
Youngjune Gwon (YG): All that we want to do is perform a L3 hand off based on L3 variables, such as latency.
Alper: So, your L3 tells L2 to handoff now?
YG: That's possible
Alper: The beacons have to be fast, or this won't work.
YG: that's right.
someone: I think you're describing a basic implementation of MIP. I think if you have a draft, it needs to show how it normally doesn't work with MIP.
Michael Thomas: I don't see what you're trying to do here that is not already supported by mobile ip. Can you clarify what problem you're trying to solve here that is not already solved.
Basavaraj: There may be ideas here that would be of interest to the design team.
Someone else: Are you talking about latency between the mobile and the routers. Have you considered multipath in your latency?
Phil: Take it outside . . .
Discussion curtailed as it was felt that this work was not in the current scope of the Mobile IP WG.
Agenda
Dynamic Home Addressing in Mobile IP Using Transient Tunnels
HMIPv6
Layer 3 Triggered Predictive MIPv4 Handoff
QoS Support in Mobile IPv6
Interoperability Testing Report
Improving Network Renumbering in Mobile IPv6
Low Latency Handoffs in Mobile IPv4
Fast MIPv6 Handoff
Security and Mobile Ipv6