home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  11KB  |  244 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Jim Solomon/Motorola
  5.  
  6. Minutes of the IP Routing for Wireless/Mobile Hosts Working Group
  7. (MOBILEIP)
  8.  
  9.  
  10. Joint Meeting of the MOBILEIP and IPNG Working Groups
  11.  
  12. The two groups met on the morning of Tuesday, 18 July.  This meeting was
  13. co-chaired by Jim Solomon, co-chair of the MOBILEIP Working Group, and
  14. Ross Callon, co-chair of the IPNG Working Group.
  15.  
  16.  
  17. Introductory Remarks
  18.  
  19. The co-chairs took turns introducing the output produced by their
  20. respective working groups.  Jim Solomon first introduced the primary
  21. requirements of the IPv4 mobility protocol:  (1) mobile nodes must be
  22. able to communicate using only their (permanent) home IP address; and
  23. (2) mobile nodes must be able to inter-operate with the enormous
  24. installed base of (non-mobility-enhanced) IPv4 hosts and routers.  A
  25. brief outline of the architecture of IPv4 mobility was also presented.
  26.  
  27. Ross Callon then introduced IPv6, highlighting the differences between
  28. IPv4 and IPv6.  Ross noted that there is no installed base of IPv6,
  29. thereby relaxing the second criteria of IPv4 mobility and increasing the
  30. possible solution space for IPv6 mobility.  A fundamental choice for the
  31. design of IPv6 then becomes:  should IPv6 be a direct ``port'' of IPv4
  32. mobility or should IPv6 mobility be designed in such a way as to take
  33. advantage of the new functionality that IPv6 contains (as compared to
  34. IPv4).
  35.  
  36.  
  37. Presentations
  38.  
  39. Fumio Teraoka presented his proposal for IPv6 mobility; one based upon
  40. the VIP concept put forth in his IPv4 mobility proposal [1].  This
  41. proposal optimizes routing to mobile node by having routers on the path
  42. between home agent and mobile node learn and cache the (authenticated)
  43. binding between a mobile node's home address and its current location.
  44. Concerns were raised about the amount of processing required by routers
  45. in the Internet due to the presence of a hop-by-hop option in all mobile
  46. registration packets.  In particular, the routers must verify an RSA
  47. digital signature in addition to processing the contents of the packet
  48. to obtain the desired location bindings.
  49.  
  50. Dave Johnson and Charlie Perkins presented their proposal for IPv6
  51. mobility [2].  This proposal leverages off of the ``route optimization''
  52. work within the Mobile IP group for IPv4.  This proposal optimizes
  53. routing to mobile nodes by having correspondents (i.e., those host and
  54. routers actually communicating with a mobile node) cache the mobile
  55. node's current location, tunneling packets directly to the mobile node's
  56. current care-of address.  The Johnson/Perkins proposal involves using an
  57. IPv6 destination option to provide address bindings to correspondents.
  58.  
  59.  
  60.  
  61. Open Discussion
  62.  
  63. The floor was opened to comments from the community at large.  The
  64. consensus seemed to be that:
  65.  
  66.  
  67.   1. Mobility for IPv6 should leverage off of the new functionality
  68.      provided by IPv6, rather than being a ``direct port'' of IPv6.
  69.  
  70.   2. Mobile IPv6 should be ``owned'' by the MOBILEIP Working Group and
  71.      no new working group needs to be formed for Mobile IPv6.  If
  72.      necessary, the Mobile IP charter will be expanded to reflect this
  73.      decision.
  74.  
  75.   3. Due to the fact that IPv4 mobility is being delayed by patent
  76.      concerns, now would be a great time for someone with an
  77.      unencumbered proposal for IPv6 mobility to step forward.
  78.  
  79.  
  80.  
  81. Tuesday Afternoon -- Mobile IP(v4)
  82.  
  83. Based upon the results of the morning meeting (joint with the IPng
  84. Working Group), the chairs have an action item to review the Mobile IP
  85. charter and determine whether it must be expanded to include
  86. responsibility for IPv6 mobility.
  87.  
  88.  
  89.  
  90. Patent Issues
  91.  
  92. IBM has provided a statement viz.  Charlie Perkins' patent -- the terms
  93. are ``reasonable and nondiscriminatory'' as required by RFC 1602.
  94. However, the terms are neither ``free'' nor are they a flat fee.  At the
  95. request of the co-chairs, Joel Halpern (Routing Area Director) has
  96. requested funds from ISOC for legal counsel to investigate the scope of
  97. infringement of the current working group draft.  One possible outcome
  98. of this investigation is that the counsel might suggest that the amount
  99. of exposure of the mobile IP protocol could be significantly reduced by
  100. eliminating certain ``features'' of the protocol (e.g., MN de-tunneling
  101. its own packets by obtaining a local COA; and replay protection using
  102. nonces).
  103.  
  104.  
  105.  
  106. Implementation Reports
  107.  
  108. Several working group members are implementing and/or have implemented
  109. the protocol.  Anders Klemets has an implementation (MN, FA, HA),
  110. running under SunOS v4.1.3 that he is willing to provide people wishing
  111. to perform beta testing.  Contact him at <klemets@sics.se> if you would
  112. like a copy.
  113.  
  114.  
  115. Interoperability Testing Plans
  116.  
  117. When enough people have brought their implementations up to Version 11
  118. of the draft, interoperability testing will proceed (hopefully by late
  119. August).  Frank Kastenholz of FTP Software will check into the
  120. feasibility of hosting an interoperability shindig.  Otherwise, Charlie
  121. Perkins of IBM indicated a willingness to do likewise.
  122.  
  123.  
  124. Specification Issues
  125.  
  126. A) Prefixes in Agent Advertisement.  The consensus is that these are
  127. sometimes useful to MNs, thus we have decided to include them as an
  128. option in agent advertisements.  The option will contain one prefix for
  129. each router address present in the ``base'' portion (i.e., the RFC 1256
  130. portion) of the advertisement.  Tony Li will provide text for this to
  131. the editor.
  132.  
  133. B) UDP Ports viz.  authentication.  In the general case, the HA does not
  134. know the source port used by the MN for the registration request,
  135. therefore it is impossible for the HA to verify the authenticator.
  136. Furthermore, it was deemed that the threat of not including the UDP
  137. ports in the computation of the authenticator was minimal.  Thus, the
  138. authenticator(s) will now be computed over only the Mobile IP portions
  139. of the packet; equivalently, the authenticator(s) will not be computed
  140. over any portion of the UDP header.
  141.  
  142. C) TTL: Is the tunnel 1 hop or N hops?  The argument for ``1 hop'' is
  143. that it provides no loss of connectivity to a mobile node when it is
  144. away from home.  The argument against it is that making the tunnel
  145. ``1 hop'' inevitably requires placing a larger TTL in the encapsulating
  146. (outer) header than that of the original datagram.  After a long
  147. discussion, the only consensus that was reached was that Mobile IP
  148. should learn from the operational experience of the MBONE and ``do what
  149. mrouted does''.  [I suspect that the group needs more discussion about
  150. this on the mailing list.  -- Jim Solomon]
  151.  
  152. D) The working group agreed that the draft needs a ``wholesale''
  153. rewriting in order to make the draft more comprehensible to those that
  154. have not followed Mobile IP for years.  Note that the changes here are
  155. all editorial and that changes in content will only be those reflecting
  156. the consensus of the group at the meetings and on the list.
  157.  
  158. E) Gratuitous Registration Reply from HA to old FA. Anders pointed out
  159. that there is a correctness problem with the protocol in that a stale
  160. entry in an (old) FA's visitor list makes it impossible for that FA to
  161. communicate with an MN which moves to and registers with a (new) FA.
  162. Ensuing discussion revealed that there is a trivial denial-of-service
  163. attack possible by sending bogus registration replys to an FA,
  164. convincing the FA to remove the MN from its visitor list.
  165.  
  166. Thus, the group decided that gratuitous registration replies should only
  167. be sent to the old FA if the HA shares a security association with that
  168. FA, implying that the FA/HA authenticator can be used.  Similarly, the
  169. FA should ignore a registration reply that is:  (a) not prompted by a
  170. corresponding registration request; or (b) does not have a valid FA/HA
  171. authentication extension.
  172.  
  173. This restricts the potential attackers to be those devices on the media
  174. that the MN is visiting.  Several working group members pointed out
  175. that, due to the presence of protocols such as ARP, any nodes on the
  176. mobile media can wreak similar havoc using alternative mechanisms and
  177. that we are not making the problem any worse.
  178.  
  179.  
  180. Wednesday -- Mobile IP(v4)
  181.  
  182. Specification Issues -- Continued
  183.  
  184. F) The topic of MN/FA and FA/HA authentication was raised yet again in
  185. reference to eliminating these authentication extensions and using the
  186. IPSEC authentication header instead.  This proposal was rejected due to
  187. uncertainty in the time-frame for IPSEC and, perhaps more importantly,
  188. the fact that it is less work to implement the extensions once the
  189. (mandatory) MN/HA authentication extension is implemented.
  190.  
  191. G) It was proposed that an MN be able to provide a broadcast ``filter''
  192. to let the HA know which broadcasts it is interested in (e.g., a
  193. specific IPPROTO number, or a specific IPPORT number, etc.).  The group
  194. consensus was that a mechanism to support this functionality should not
  195. be part of the base specification and that those requiring this
  196. functionality should submit an Internet-Draft specifying its operation.
  197.  
  198. H) Noting that the current working group draft contains three
  199. authentication extensions, yet only one key identifier extension, the
  200. group decided that a mechanism must be provided to apply a key
  201. identifier to all of the authentication extensions.  It was decided to
  202. integrate a Security Parameter Index (4 bytes) of identical syntax and
  203. semantics to the SPI used in IPSEC into each of the respective
  204. authentication extensions.  The extensions now look as follows:
  205.  
  206.  
  207.     0                   1                   2                   3
  208.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  209.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  210.    |     Type      |     Length    |                     SPI  ....
  211.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  212.       ... SPI (cont.)              |            Authenticator ...
  213.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  214.  
  215.  
  216. See the IP Authentication Header document [3] for more information on
  217. the use of SPI's.
  218.  
  219.  
  220. Route Optimization
  221.  
  222. Dave Johnson explained his and Charlie Perkins' proposal for route
  223. optimization in IPv4 mobility [4].  The proposal involves a mechanism
  224. for distributing authentic binding information to the nodes which
  225. require it, mitigating to some extent the key-management difficulties.
  226. The authors stressed that the need for feedback on their proposal from
  227. the members of the MOBILEIP Working Group.
  228.  
  229.  
  230. References
  231.  
  232. [1]
  233. ftp://cnri.reston.va.us/internet-drafts/draft-teraoka-ipv6-mobility-sup-01.txt
  234.  
  235. [2]
  236. ftp://cnri.reston.va.us/internet-drafts/draft-perkins-ipv6-mobility-sup-02.txt
  237.  
  238. [3] 
  239. ftp://cnri.reston.va.us/internet-drafts/draft-ietf-ipsec-auth-02.txt
  240.  
  241. [4]
  242. ftp://cnri.reston.va.us/internet-drafts/draft-ietf-mobileip-optim-02.txt
  243.  
  244.