home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-93sep.txt < prev    next >
Text File  |  1994-02-08  |  27KB  |  754 lines
  1.  
  2. INTERIM_MEETING_REPORT_
  3.  
  4. Reported by Kannan Alagappan/Digital Equipment Corporation
  5.  
  6. Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
  7. (MOBILEIP)
  8.  
  9. The MOBILEIP Working Group convened for an interim meeting on September
  10. 9 and 10 in Newark, NJ. This group is charted to develop or adopt
  11. architectures and protocols to support mobility within the Internet.
  12.  
  13. In general, the two day meeting was productive.  The group reached some
  14. agreement on the major architectural issues and terminology.
  15.  
  16. The goals of the meeting were to generate a group draft, appoint an
  17. editor, and diffuse egos.
  18.  
  19.  
  20. CDPD Overview
  21.  
  22. Mark Knopper presented a brief overview of the Wireless Data Market and
  23. the CDPD architecture, protocols, services.  According to one source,
  24. 27% of the market will be for personal communications and 40% for mobile
  25. office.  CDPD is developing open specifications for air protocol
  26. (secured), carrier interoperability, and network functionality (``ISO
  27. terminology in specification, but really IP''). A-Interface (airlink)
  28. between mobile end systems and mobile database stations, E-Interface
  29. (external network) between CDPD network and external world, and
  30. I-Interface (inter-service provider) between other CDPD service
  31. providers networks.
  32.  
  33. Volumes 3 and 5 of the specification are relevant to this working group.
  34. The MNRP protocol is derived from ES-IS and seems to be between the
  35. mobile and visitor agent.  The MNLP protocol is from the visitor agent
  36. to the home agent.  The MDLP protocol is for cell switching between
  37. mobile data base stations.
  38.  
  39. Mark also handed out a paper on the CDPD Engineering Plan for IP Address
  40. Allocation, draft 1.1.  This paper proposes an allocation plan for IP
  41. addresses, and includes a justification and some discussion of the
  42. architecture and routing issues for the CDPD network.
  43.  
  44.  
  45. User/Functional Requirements
  46.  
  47. John Penners presented his requirement analysis for Mobile IP. John
  48. described hard requirements and soft requirements.  The group agreed
  49. that our solution should not preclude support for mobile segments, but
  50. mobile segments are not a hard requirement.
  51.  
  52. After some discussion, two fundamental user requirements along with a
  53. few additional soft user requirements were decided upon:
  54.  
  55.  
  56.   1. A mobile host shall be capable of continuing to communicate using
  57.      the same IP address, after it has been disconnected from the
  58.      Internet and reconnected at a different point.
  59.  
  60.   2. A mobile host shall be capable of interoperating with existing
  61.      hosts, routers, and services.
  62.  
  63.  
  64. Additional soft user requirements:
  65.  
  66.  
  67.   1. Not weaken IP security.  The general feeling is that there is none
  68.      now.  The marketing requirement is that users do not feel that
  69.      Mobile IP significantly reduces their present security.
  70.  
  71.   2. A Mobile host should be able to participate in IP multicast groups.
  72.  
  73.   3. There should be a means of hiding mobile location information from
  74.      correspondent hosts.
  75.  
  76.  
  77. Most of the other requirements in John's list were grouped as criteria
  78. for evaluating our solution.  Greg Bruell rearranged John's list based
  79. on a hierarchical approach with a weighted model.  These are metrics by
  80. which the group will judge its solution.
  81.  
  82.  
  83.    o Robustness
  84.  
  85.       -  Fault Isolation - the ability to isolate faults created by
  86.          mobile users should be considered for both individual and group
  87.          behavior.
  88.  
  89.       -  Lost Packet Operation - protocols involved in supporting
  90.          mobility should be able to maintain correct operations in the
  91.          presence of loss of packets.
  92.  
  93.       -  Robustness - support for mobile computing should provide
  94.          sufficient robustness.
  95.  
  96.       -  Failure Modes - failure modes, and specifically behavior in
  97.          presence of partioned internet should be carefully evaluated.
  98.  
  99.  
  100.    o Scalability
  101.  
  102.       -  Distributed Burden - a scheme for mobile computing should be
  103.          sufficiently flexible with respect to its capabilities of
  104.          re-distributing the burden associated with supporting mobile
  105.          computing between various entities within an internet.
  106.  
  107.       -  Incremental Overhead - the incremental overhead of supporting
  108.          mobile computing should reflect the number of entities that
  109.          benefit from mobile computing.
  110.  
  111.       -  Changes to Infrastructure - a scheme that supports mobile
  112.          computing shall assume that changes that involve most of the
  113.          components of the existing infrastructure are infeasible.
  114.  
  115.       -  Scalability and Robustness - scalability needs to be
  116.          complemented with robustness and fault isolation.
  117.  
  118.  
  119.    o Security
  120.  
  121.       -  Privacy of Location - a solution to mobile computing should be
  122.          able to allow selective suppression of location information.
  123.  
  124.       -  Security - any scheme for supporting mobile computing shall not
  125.          adversely impact available security mechanisms.
  126.  
  127.  
  128.    o Multicast/Broadcast
  129.  
  130.       -  Multicast Applications - The support for mobile computing
  131.          should allow multicast applications.  ability for a mobile host
  132.          to join a multicast group, send and receive multicast messages
  133.          must be addressed.
  134.  
  135.  
  136.    o Use of Resources
  137.  
  138.       -  Minimize Network Resources - a scheme that supports mobile
  139.          computing should attempt to minimize the use of the networking
  140.          resources (e.g., bandwidth, memory on routers, CPU on routers)
  141.          that are required to deal with mobility related issues.
  142.  
  143.       -  Additional Equipment - a scheme that supports mobile computing
  144.          should attempt to minimize the amount of additional equipment
  145.          needed.
  146.  
  147.       -  Cost of Resources - in addition to minimizing network
  148.          resources, any scheme used to support mobile computing should
  149.          be cognizant of the cost of these resources.
  150.  
  151.  
  152.    o Level of Mobility
  153.  
  154.       -  Multiple Mobile Host - a solution to mobile computing shall be
  155.          able to deal with mobile segments that contain one or more
  156.          hosts.
  157.  
  158.       -  Multiple Levels of Mobility - a mobile computing solution shall
  159.          be able to handle multiple levels of mobility.
  160.  
  161.       -  Off-line Mobility - a mobile computing solution must not
  162.          prevent upper layers from achieving off-line mobility while a
  163.          host becomes disconnected from the rest of an internet for a
  164.          prolonged period of time.
  165.  
  166.  
  167. Next, the group defined functional requirements.  After some discussion
  168. on the top-down design methodology, the group decided on three
  169. functional requirements:
  170.  
  171.  
  172.   1. Establish and dissolve association with an attachment point.
  173.   2. Tunnel packets to a mobile host.
  174.   3. Inform other entities of mobile location.
  175.  
  176.  
  177. Alan Quirt described a short-term and long-term view for mobile IP:
  178.  
  179.  
  180.    o Short-term (~2 years)
  181.  
  182.       -  Develop a solution that essentially works.
  183.       -  Some broken IP problems.
  184.       -  Mostly plug-in, dial-in model.
  185.  
  186.  
  187.    o Longer term (~5 years)
  188.  
  189.       -  Everything works.
  190.       -  New IPng.
  191.       -  True wireless mobility.
  192.  
  193.  
  194. Tunneling Discussion (Encapsulation vs.  Options)
  195.  
  196.    o Choice of tunneling protocol has an impact on location updating,
  197.      how redirects are handled, and loop detection.
  198.  
  199.    o Options have more functionality but they slow down the
  200.      infrastructure.
  201.  
  202.    o Options have a minor technical advantage, but they have a major
  203.      practical disadvantage.
  204.  
  205.    o Options are IP-specific, therefore if we use options it may be hard
  206.      to use our mobility solution with other protocols.
  207.  
  208.    o If hosts today receive a packet with an unknown option, what will
  209.      they do?  General feeling is that we should only send options to
  210.      hosts that understand our protocol.
  211.  
  212.    o Options are nice because they give entities along the path a way to
  213.      look at header.  This can also be done with encapsulation.
  214.  
  215.    o Can we recommend IP encapsulation but allow options based on where
  216.      tunnel ends?  If so, we would need some sort of negotiation
  217.      protocol to decide which one to use.  This doesn't seem like a good
  218.      idea.
  219.  
  220.    o If you really want options.  One possibility is to encapsulate your
  221.      options in the forward direction.  This needs more thought.
  222.  
  223.    o Suggestion to use existing encapsulation protocol and don't invent
  224.      a new one.
  225.  
  226.    o Having the source binding in every packet via options is a nice
  227.      idea.  If we seperate out the control packets, when do we send it?
  228.  
  229.    o We obviously don't need to send a control packet with every data
  230.      packet.
  231.  
  232.    o It doesn't make sense to support *both* encapsulation and options.
  233.  
  234.    o We should not send an encapsulation or option to CH unless we know
  235.      it understands the type of tunnel.
  236.  
  237.    o Seems like we want a separate data channel and control channel.
  238.      Therefore use encapsulation for everything.  First packet should
  239.      not carry any source binding info to a CH in the interest of
  240.      purity.
  241.  
  242.    o Network operators in general say ``don't use options''.
  243.  
  244.    o If we can make it work with encapsulation then why bother with
  245.      options.  So, propose tunneling via encapsulation for IPv4.
  246.  
  247.    o It is alright for ICMP control packets to be initiated by MHs.  MH
  248.      can send ICMP packet to CH directly.
  249.  
  250.    o Propose use UDP instead of ICMP for redirects since if CH doesn't
  251.      understand the message, it will return positive feedback (ICMP msg)
  252.      saying CH doesn't understand this port.
  253.  
  254.    o Would like to use ICMP for redirects so routers can snoop on
  255.      packets to get location updates.
  256.  
  257.    o Would like to preserve the feature of possibly adding snooping and
  258.      location updates into routers.  If we have UDP redirects, we would
  259.      be precluding this snooping.
  260.  
  261.    o What is the difference?  An unknown ICMP type or an UDP to unknown
  262.      port message both generate a packet back to sender.  It isn't clear
  263.      how this message is used.
  264.  
  265.    o Dogleg routing impacts entire Internet infrastructure.  Dogleg
  266.      impacts scalability because this type of routing more than doubles
  267.      the traffic to mobile hosts.
  268.  
  269.    o Location caching should be left to future research.
  270.  
  271.    o If correspondent host doesn't understand mobile-ip protocol, do
  272.      triangle routing.  Try to optimize later.
  273.  
  274.      Agreement was reached on:
  275.  
  276.       -  Tunneling via encapsulation
  277.       -  Dogleg routing to ignorant hosts
  278.  
  279.  
  280. During the next part of the discussion, the following terminology was
  281. used:
  282.  
  283.      HAA - Home Address Agent
  284.      COAA - Care-Of-Address Agent
  285.      CH - Correspondent Host
  286.      MH - Mobile Host
  287.  
  288. Q: Where does tunnel end?
  289. Tunnel always ends at the Care-Of-Address (COA). The COA may be on
  290. either the MH or COAA.
  291.  
  292. Q: Where does the tunnel begin?
  293. Tunnel starts at either the CH or HAA.
  294.  
  295. Q: Who sends the ICMP redirect?
  296. MH or HAA.
  297.  
  298. Q: When does MH decide to send forward pointer update to old COAA?
  299. Eager or lazy
  300.  
  301.  
  302.    o Simpler to deal with location privacy if MH sends redirect.
  303.  
  304.    o HAA, COAA, and MH can all send redirects.  However it is probably
  305.      more secure if redirects are sent by HAA or MH.
  306.  
  307.    o When a MH moves to a new COAA, the old COAA should be updated then
  308.      all the CHs.  This may be difficult since we don't know which CHs
  309.      have cached location information.
  310.  
  311.    o It is better if the new COAA updates the old COAA when a MH has
  312.      moved instead of waiting for the old entry to timeout.  This will
  313.      provide faster convergence.
  314.  
  315.    o One advantage of a HAA sending all redirects instead of a MH is
  316.      that network traffic is on the wired network.
  317.  
  318.    o If packet for a MH goes to its old COAA and the old COAA does not
  319.      have a forwarding pointer, it will send the packet to HAA
  320.  
  321.    o HAA does redirecting of packets and it maintains a location
  322.      database.
  323.  
  324.    o Hosts can choose to believe redirect messages.
  325.  
  326.  
  327. Dogleg Routing Elimination Discussion
  328.  
  329.    o There are important security issues with trying to eliminate dogleg
  330.      routing.  Hosts need to authenticate redirect messages for MHs.
  331.  
  332.    o Some people generally said that they would like to see the working
  333.      group produce a first Internet-Draft based on dogleg routing.  Once
  334.      we have more experience, we can add dogleg elimination or optimal
  335.      routing.  Another comment was if we only wanted a solution with
  336.      dogleg routing, we could have solved the problem two years ago.
  337.  
  338.    o A vote was taken:  Would you support a first Internet-Draft that
  339.      does not address dogleg routing elimination, but only addresses the
  340.      basic user requirements for mobile-ip?
  341.  
  342.      Yes - 9, No - 4 (a few abstained).
  343.  
  344.    o Another vote was taken :  Would you support an RFC that does not
  345.      address dogleg routing elimination, but only addresses the basic
  346.      user requirements for mobile-ip?
  347.  
  348.      Yes - 8, No - 5 (a few abstained).
  349.  
  350.    o Based on this tentative vote, we decided to focus the rest of the
  351.      day's discussion on getting a simple mobile IP design.
  352.  
  353.  
  354. Q: When a MH moves to a new COAA, is the old COAA told?
  355. Yes, at least the old COAA is notified that MH has unregistered.  The
  356. old COAA does not need to keep a forwarding pointer.  We may want to
  357. leave a forwarding pointer behind with a short TTL so we can capture
  358. packets in flight from HAA to the old COAA.
  359.  
  360. Q: How do we do loop elimination?
  361. If we don't try to eliminate dogleg routing, then loop elimination isn't
  362. a serious problem.
  363.  
  364. Q: What happens if packet goes to old COAA and no forwarding pointer?
  365. Old COAA forwards packet to HAA.
  366.  
  367.  
  368.    o Steve mentioned that not everyone agreed with the decision to
  369.      postpone dogleg routing elimination.  Therefore we spent some time
  370.      discussing this issue further.
  371.  
  372.       -  CP: Would like to allow possibility of adding dogleg routing
  373.          elimination in first draft.  Thought that our vote was
  374.          forbidding this possibility.
  375.  
  376.       -  SD: Our vote yesterday was based on the question, ``is it
  377.          acceptable to send out a draft without dogleg elimination?''  A
  378.          majority said that it would be okay.
  379.  
  380.       -  DD: If we distribute a first draft without a solution, then we
  381.          haven't done our job.
  382.  
  383.       -  YR: Fact that multiple solutions to dogleg routing exist
  384.          indicates that we don't know how to do it.  If people came up
  385.          with a single solution, then we can adopt it.
  386.  
  387.       -  KA: Propose adding dogleg elimination as an appendix to first
  388.          draft.
  389.  
  390.       -  PK: When taking a test, you do all the easy problems first,
  391.          then the hard ones.  Similarly, let's get a draft without
  392.          dogleg elimination first.
  393.  
  394.       -  YR: Dogleg elimination is still research.  People interested in
  395.          research should go to IRTF.
  396.  
  397.       -  SD: Let's have a basic draft and people can propose text to
  398.          solve optimal routing.
  399.  
  400.       -  PK: We need experience with mobile-ip.  We need to prototype
  401.          multiple implementations and try it out over Internet.
  402.  
  403.  
  404.    o We need one draft no matter how imperfect.  Having ten solutions
  405.      for dogleg elimination doesn't get interoperability.
  406.  
  407.       -  CP: People who care to solve optimal routing can get together
  408.          and work on it.  Let's solve first things first.
  409.  
  410.       -  YR: Eventually, we may want to move Internet-Draft to Prototype
  411.          (instead of Experimental).
  412.  
  413.  
  414. Beaconing/Registration Discussion
  415.  
  416. There was discussion on allowing multiple COAAs.  That is having one COA
  417. served by multiple routers.  For example, a set of routers on a subnet
  418. can act as a COAA for visiting MHs.  It was agreed that a COAA should
  419. not proxy ARP for guest MHs.
  420.  
  421. A registration proposal was discussed similar to CDPD. Where a MH sends
  422. a registration message to a COAA. The COAA registers the MH with the
  423. MH's HAA. The HAA returns a registration ack/nack message to the COAA.
  424. The COAA returns a ack/nack message to the MH. This simple protocol is
  425. designed to minimize the MH to COAA traffic.  However it requires trust
  426. between the COAA and HAA.
  427.  
  428.  
  429.    o Beaconing/Registration can be divided into two parts.  First, MH
  430.      discovers that a COAA exists.  Second, MH intiates registration
  431.      with COAA.
  432.  
  433.    o Advertisement should be multicast periodically so that a MH can
  434.      determine which COAA cell it is in.  If a MH doesn't hear an
  435.      advertisement after some time, it may choose to multicast a Solicit
  436.      message.  A COAA that hears a solicit message, should unicast an
  437.      advertisement to the MH.
  438.  
  439.    o Also, a MH may need to send a solicit message if it is attached to
  440.      the network via an access point that filters incoming multicast
  441.      packets.
  442.  
  443.      Agreement was reached on:
  444.  
  445.       -  Advertisement/Solicitation/Registration model
  446.       -  Solicit responses are unicast
  447.  
  448.  
  449.    o The term COAA will now be referred to as BASE in order to avoid the
  450.      confusion between COA and COAA.
  451.  
  452.    o BASE Advertisement message contains the following information.
  453.  
  454.      Agreement was reached on:
  455.  
  456.      BASE Advertisement
  457.       -  type,code,checksum
  458.       -  COA address
  459.       -  [BASE address] ?
  460.       -  base incarnation number
  461.       -  advertisement interval
  462.       -  MAC address (in MAC header)
  463.  
  464.  
  465.    o We may not need a base incarnation number since the HAA can tell
  466.      the BASE that a MH is in its cell.
  467.  
  468.    o One reason for having a BASE address and a COA address in the
  469.      advertisement is that they may be different if we allow multiple
  470.      BASE stations to advertise the same COA address.
  471.  
  472.    o We got into a discussion where a domain propagates host routes
  473.      inside.  A MH registers with one BASE and it can move transparently
  474.      around the domain without having to send any additional location
  475.      updates to its HAA. Thus, this is one proposal for dampening
  476.      traffic back to a HAA.
  477.  
  478.    o Another suggestion was to allow level 2 advertisement information
  479.      to be sufficient to support registration.  This may not be possible
  480.      since the advertisement will need to pass along level 3 information
  481.      like the COA address.
  482.  
  483.    o It may be necessary to have two addresses in the advertisement for
  484.      multi-homed BASE stations.
  485.  
  486.    o MH Solicit message contains the following information.
  487.  
  488.      Agreement was reached on:
  489.  
  490.      MH Solicit
  491.       -  type,code,checksum
  492.       -  MH's IP address (in IP header)
  493.       -  MAC address (in MAC header)
  494.  
  495.  
  496.    o The Registration protocol consists of 4 messages.  First, is a
  497.      MH-BASE registration message, second is a BASE-HAA registration
  498.      message, third is a HAA-BASE ack/nack message, and finally a
  499.      BASE-MH ack/nack message.
  500.  
  501.    o The MH-BASE registration message contains the following
  502.      information.
  503.  
  504.      Agreement was reached on:
  505.  
  506.      MH-BASE Registration
  507.       -  type,code,checksum
  508.       -  HAA's address
  509.       -  sequence number (from MH to HAA)
  510.       -  previous COA address
  511.       -  [previous BASE address] ?
  512.       -  MH authenticator to HAA
  513.       -  MH authenticator to BASE ?
  514.       -  MH's IP address (in IP header)
  515.       -  MAC address (in MAC header)
  516.  
  517.  
  518.    o We need the HAA's address because when a MH moves from its home
  519.      subnet to a foreign subnet, the MH's HAA will not proxy ARP for the
  520.      MH until it has been notified.  Therefore the registration message
  521.      must be sent directly to the HAA.
  522.  
  523.    o In terms of security, we recognize that eavesdropping can occur
  524.      along the path.  We want to prevent eavesdropping by someone on
  525.      another network.  Adopt a weak security model for now.  Add strong
  526.      security in the future.
  527.  
  528.    o The BASE-HAA registration message contains the following
  529.      information.
  530.  
  531.      Agreement was reached on:
  532.  
  533.      BASE-HAA Registration
  534.       -  type,code,checksum
  535.       -  COA address
  536.       -  [BASE address] ?
  537.       -  sequence number (from MH to HAA)
  538.       -  MH authenticator to HAA
  539.  
  540.    o The HAA-BASE ack/nack message contains the following information.
  541.  
  542.      Agreement was reached on:
  543.  
  544.      HAA-BASE ACK/NACK
  545.       -  type,code,checksum
  546.       -  MH's IP address
  547.       -  sequence number
  548.       -  COA address
  549.       -  location_cache expiration time (from HAA to MH)
  550.  
  551.  
  552.    o The BASE-MH ack/nack message contains the following information.
  553.  
  554.    o Default value for location_cache expiration timeout is infinity.
  555.      HAA specifies a timeout value.
  556.  
  557.      Agreement was reached on:
  558.  
  559.      BASE-MH ACK/NACK
  560.       -  type,code,checksum
  561.       -  MH's IP address (in IP header)
  562.       -  sequence number
  563.       -  cookie value
  564.       -  location_cache expiration timer (from HAA to MH)
  565.       -  cell expiration timer (from BASE to MH)
  566.  
  567.  
  568.    o We need to write down the risk assumptions for weak security and
  569.      strong security.
  570.  
  571.      Agreement was reached on:
  572.  
  573.       -  We are aiming for weak security at least.  Strong security in
  574.          the future.  Weak security doesn't protect against snoopers.
  575.          People who can eavesdrop when a packet takes the intended path
  576.          can break security.  But we protect against a random person
  577.          anywhere breaking the security.
  578.  
  579.       -  Steve Bellovin is our security consultant for mobile-ip.  We
  580.          need to get him more involved.
  581.  
  582.       -  We need a liason between mobile-ip WG and a router company in
  583.          order to check our ideas.  Greg Bruell volunteered.  (Not clear
  584.          exactly what this means yet.)
  585.  
  586.       -  We need a liason between mobile-ip WG and a NOS company in
  587.          order to check our ideas.  Steve Parker volunteered.  (Not
  588.          clear exactly what this means yet.)
  589.  
  590.  
  591.    o Advertisement interval can be configured depending on the link
  592.      layer technology.  There is a tradeoff between the advertisement
  593.      interval and the amount of bandwidth consumed.
  594.  
  595.    o Next we discussed what should happen when a data packet is tunneled
  596.      to a BASE station that doesn't know where a MH is located.
  597.  
  598.    o Two possibilities are 1) a CH tunnels a packet to a old BASE
  599.      station that doesn't have a forwarding pointer and 2) HAA tunnels a
  600.      packet to the correct BASE station, but the BASE station has
  601.      forgotten that it contains the MH.
  602.  
  603.    o In the first case, the old BASE station should send the packet to
  604.      the MH's IP address.  There is an issue of how we make sure that
  605.      this packet doesn't get rerouted.  If the MH is remote, the HAA
  606.      will receive the packet and forward it to the correct BASE.
  607.  
  608.    o In the second case, the BASE has been told that the MH is in its
  609.      cell.  The BASE searches locally for the MH. One possibility is
  610.      that the BASE sends out an advertisement message so that the MH
  611.      will register.  Since an advertisement message may be lost we may
  612.      want to send this message periodically.
  613.  
  614.    o BASE should be able te authoritatively say that 'a MH is not here'
  615.      to HAA.
  616.  
  617.    o In our model, the BASE is handling reregistration with HAA.
  618.      Therefore we may need a `force through' bit so that BASE will
  619.      reregister with HAA. Also, we may want reregistration to come from
  620.      MH through BASE since we want a fresh authenticator.  This needs
  621.      more thought.
  622.  
  623.    o When a MH moves to a new BASE, the old BASE should at least be told
  624.      that the MH has moved.
  625.  
  626.    o The unregister message contains the following information.
  627.  
  628.      Agreement was reached on:
  629.  
  630.      BASE-OLD_BASE UNREGISTER
  631.       -  type,code,checksum
  632.       -  MH's IP address
  633.       -  MH's cookie for old BASE
  634.       -  new COA address
  635.       -  [new BASE address] ?
  636.       -  forward_pointer hold tiem (upper bound)
  637.  
  638.  
  639.    o If we want to do dogleg elimination, this message may need to be
  640.      ack'ed.
  641.  
  642.      Agreement was reached on:
  643.  
  644.       -  We need to look more carefully at how a MH behaves in home
  645.          network vs.  MH in foreign network
  646.  
  647.  
  648.    o It is still an open on the exact packet formats and the protocol
  649.      used in Advertisement/Solicit/Registration.  If the protocol is
  650.      UDP, then we need to decide on a well-known port number.
  651.  
  652.  
  653.  
  654. Dogleg Eliminators Gave a Simple Dogleg Elimination Proposal
  655.  
  656. Alan Quirt and Andrew Myles put up a slide each with an analysis of
  657. dogleg elimination.  (Packet flow with ``='' indicates that packet is
  658. tunneled.)
  659.  
  660.  
  661.    o For security, redirects must come from MH or HAA
  662.  
  663.    o Only HAA sees dogleg information without requiring an extra
  664.      protocol.
  665.  
  666.    o Therefore redirects should be handled by HAA.
  667.  
  668.    o Dogleg routes packets as follows.
  669.  
  670.      CH ---> HAA ==> BASE ---> MH
  671.      CH <--- BASE <--- MH
  672.  
  673.    o Optionally, a BASE can send a redirect to CH to get optimal
  674.      routing.  Since this redirect isn't authenticated, the CH would
  675.      issue a challenge/response with the MH. Challenge/Response is a
  676.      random number that is returned unmodified.
  677.  
  678.      CH <--- BASE (ICMP Redirect)
  679.      CH ---> HAA ==> BASE ---> MH (ICMP Redirect challenge)
  680.      CH <--- BASE <--- MH (ICMP Redirect response)
  681.  
  682.    o Now CH has a location binding for MH at the BASE address.  So
  683.      packets from CH to MH take an optimal path.
  684.  
  685.      CH ==> BASE ---> MH
  686.      CH <--- BASE <--- MH
  687.  
  688.    o Since the redirect message is never trusted, it doesn't matter who
  689.      sends the redirect to the CH.
  690.  
  691.  
  692.  
  693. Terminology
  694.  
  695. The group agreed on the following terminology.
  696.  
  697.  
  698.    o Mobile Host
  699.    o 1Correspondent Host
  700.    o Ignorant Host
  701.    o Home Subnet
  702.    o Foreign Subnet
  703.    o Home Agent (was HAA/Location Server)
  704.    o Foreign Agent (was COAA/Base Station)
  705.    o Triangle Routing (was Dogleg Routing)
  706.    o Care-Of-Address (Address of Foreign Agent)
  707.  
  708.  
  709. The group needs to define the following terms.
  710.  
  711.  
  712.    o Weak Security
  713.    o Tunnel (v)
  714.  
  715.  
  716. Document Editor
  717.  
  718. Charlie Kunzinger has volunteered as editor.  He does not have a stake
  719. in any proposals.  He is an experienced editor and tends to have a short
  720. turn around time.
  721.  
  722.  
  723. Instructions for Liaison activities (802.11)
  724.  
  725. Charlie Perkins is the liaison between The MOBILEIP Working Group and
  726. the IEEE 802.11 subcommittee.  It would be useful if the 802.11 could
  727. provide an indication of MAC address when a MH switches cells.  Also, if
  728. 802.11 can provide cell arrival signals and cell departure signals we
  729. may be able to exploit them.
  730.  
  731.  
  732. Attendees
  733.  
  734. Kannan Alagappan         kannan@dsmail.lkg.dec.com
  735. Gregory Bruell           gob@wellfleet.com
  736. Stephen Deering          deering@parc.xerox.com
  737. Daniel Duchamp           djd@cs.columbia.edu
  738. Jari Hamalainen          jah@rctre.nokia.com
  739. David Johnson            dbj@cs.cmu.edu
  740. Phil Karn                karn@qualcomm.com
  741. Mark Knopper             mak@merit.edu
  742. Charles Kunzinger        kunzinger@vnet.ibm.com
  743. Brian Marsh              marsh@mitl.com
  744. Greg Minshall            minshall@wc.novell.com
  745. Andrew Myles             andrew@mpce.mg.edu.au
  746. Steve Parker             sparker@ossi.com
  747. John Penners             jpenners@advtech.uswest.com
  748. Charles Perkins          perk@watson.ibm.com
  749. Alan Quirt               aquirt@bnr.ca
  750. Yakov Rekhter            yakov@watson.ibm.com
  751. Shyhtsun Felix Wu        wu@cs.columbia.edu
  752. Ruixi Yuan               yuan@syl.dl.nec.com
  753.  
  754.