home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-97aug.txt < prev    next >
Text File  |  1997-10-10  |  9KB  |  249 lines
  1. Minutes of the IP Routing for Wireless/Mobile Hosts (MOBILEIP) Working
  2. Group
  3.  
  4. Reported by: Steve Silverman and Steve Parker. Edited by Erik Nordmark.
  5.  
  6. Mobile IPv4 - Wednesday, Aug 13, 1997 
  7. -------------------------------------
  8.  
  9. 1. Dave Johnson reminded everyone about MobiCom 1997 September 26-30 
  10. Budapest, Hungary
  11.  
  12. 2. Jim Solomon reported that the PPP IPCP Mobile IP Option draft
  13. has passed WG last call in the PPPEXT working group.
  14.  
  15. 3. RFC 2002 errors and ambiguities:
  16. Presented by Jim Solomon, Motorola.
  17. The issues were sent to the mailing list prior to the meeting.
  18. The largest unclear issue is whether the SPI field included in authentication
  19. calculation.
  20. Charlie to issue a draft with bug fixes which will move to an updated RFC.
  21. The issue of the document name was brought up.  The document should
  22. probably have IPv4 in the name.
  23. There is no update needed for RFC 2003.
  24. The issue of supporting multiple Care Of Addresses is something that
  25. will not be addressed by the new draft. It could be included in a new
  26. version of mobile IP.
  27.  
  28. 4. RFC 2006 (MIB) errors and ambiguities:
  29. Presented by David Cong, Lucent.
  30. New ID to be issued, to hold info but not sent out for RFC.
  31. Will issue a new RFC when both RFC 2002 and 2006 are ready for draft standard.
  32. Most fixes are because of fixes in 2002.  
  33. Editorial changes like adding a Table of Contents and
  34. fixing the default values and range definitions for various mib 
  35. variables to be consistent with RFC 2002.
  36. The clarification of SPI in RFC 2002 implies that security is unidirectional
  37. which implies some clarifications to the security tables in the MIB.
  38. Clarification that the R bit is per interface, not per agent.
  39. Consensus that the maximum registration time configuration 
  40. (maxAdvMaxRegLifetime) should be per mobile node.
  41.  
  42. Need implementations of the MIB. One exists but not publicly available.
  43. Many people are interested (over 3) so testing can happen.
  44.  
  45.  
  46. 5. Interoperability & Deployment Experience:
  47.  
  48. Dave Johnson, Carnegie Mellon Univ.:
  49. No experience to report yet, but expected soon.  Will deploy
  50. transparent switching to/from CDPD, Wavelan, and Ethernets.
  51. Intend to cover all campus except some dorms.
  52. Number of mobiles remains to be seen.
  53.  
  54. David Reeder,  Portland State Univ.:
  55. Installed.
  56. Several HAs.  One is in a classroom without physical connection,
  57. demos CAD.  HA mostly for research and experimenting.
  58. Wavelan, each corner of building has transmitter.  Can hear multiple
  59. FAs, choose best.
  60. Used over WAN.  DARPA conference in Feb, FA running there, and
  61. some mobile nodes running off of that.  Tunneled back to PSU.
  62. No filtering problems, since foreign had no filtering capability.
  63. Right now two HAs enough, small user pool (7 - 15 professors. Some
  64. grad students using it heavily.)
  65.  
  66. 6. Firewall traversal experience:
  67. Presented by Gabriel Montenegro, Sun.
  68. Reported on a firewall traversal and reverse tunneling (without FA)
  69. interoperability test between Sun and Toshiba. 
  70. The firewall traversal was using SKIP and not IPsec.
  71.  
  72. 7. Reverse Tunneling security issues:
  73. Presented by Gabriel Montenegro, Sun.
  74. ID not submitted in time but mailed to list.  
  75.  
  76. Problem:
  77.     An intruder can send a registration request to a FA with a fake
  78.     Home Agent address. When using reverse tunneling this can cause all
  79.     the MNs packets to be sent to a fake Home Agent.
  80.     This can be used by attackers to either capture all the content
  81.     of the packets sent by the MN or as a denial of service attack
  82.     against the MN.
  83.  
  84.     Two variants depending on if the intruder sends the registration
  85.     before or after the MN has sent its real registration to the FA.
  86.     
  87. Several alternatives to introduce cookies in the protocol:
  88.  - Sender-initiated Cookies
  89.    Send current & previous cookies in registration request to prevent hijacks.
  90.    Requires that the either MN has stable storage to retain the previous
  91.    cookie or the MN when rebooting can not register until the previous
  92.    cookie has timed out.
  93.  
  94.  - Receiver-Initiated Cookies
  95.    FA sends in advertisements.
  96.    Use cookie extension in registration reply.
  97.    Prevents off-subnet nodes from registering with FA.
  98.  
  99.  - Constant HA
  100.    Reregister only on same HA.
  101.    Might prevent failover to other HA.
  102.  
  103. Consensus to use TTL=255 for the registration request (when registering
  104. for reverse tunneling) to limits attacks to local nodes.
  105.  
  106. 8. Tunnel Setup Protocol (TSP):
  107. Presented by Gabriel Montenegro, Sun.
  108.  
  109. 9. Tunnel Establishment Protocol (TEP):
  110. Presented by Pat Calhoun, 3com, and Charlie Perkins, Sun.
  111.  
  112. Features:
  113.  - Provides support for multi-protocol encapsulation
  114.  - Provides hierarchical registration
  115.  
  116. draft to come: draft-calhoun-tep-01.txt
  117.  
  118. New terminology:
  119.  - Targeted Tunnel Agent (like a HA)
  120.  - Requesting Tunnel Agent  (like a FA)
  121.  - PDU receiver (like a mobile node)
  122.  
  123. Issues:
  124.  - Problem with security using hierarchical registrations.
  125.  
  126.  - Transitivity of Trust. Need point of trusted contract.  
  127.  
  128.  - Topology is not synonymous with security hierarchy.  Nets might be
  129.    willing to disclose the latter but not the former.
  130.  
  131.  
  132. 10. Security-Oriented Extension to Mobile IP (SOMIP)
  133. MC Chuah  (Lucent) YZ Li (Bay) presented by Milo Osric.
  134.  
  135. Goals:
  136.  - Want to reduce frequent distant registrations.
  137.  - Prevent illegal use  of routing service.
  138.  - Easier to handle security (more scalable)
  139.  - Interoperable with RFC2002.
  140.  - Separate registration and routing functions.
  141.  
  142.  
  143. Mobile IPv6 - Thursday, Aug 14, 1997 
  144. ------------------------------------
  145.  
  146. 11. Announcement re: firewall traversal
  147. Steve Glass has an interesting idea for solving the problem of firewalls.
  148. Will send it to the list.
  149.  
  150. 12. Route Optimization in Mobile IP
  151. draft-ietf-mobileip-optim-06.txt
  152. Presented by Charlie Perkins, Sun.
  153.  
  154. Binding Cache Maintenance
  155. Smooth Handoff
  156.  - MN supplies Binding Update to previous FA to forward "packets in flight".
  157.  - Short timeout
  158.  - Registration Key required for secure operation.
  159.  
  160. Registration Key Acquisition
  161.  - Want to use SA's or public keys 
  162.  - Diffie Hellman as a last resort
  163.  - Man-in-the-middle attacks - HA acts as KDC to prevent Bad FAs.
  164.  
  165. Discussion of various problems:
  166.  - Is HA the one to send Binding Update?  Or FA?
  167. Comment: We should use IPSEC.  
  168. Special Tunnels: to avoid routing loop, old FA tunnels packet to HA.. 
  169. Algorithm at Foreign Agent
  170.     Advertise "S" bit for smooth-handoff-enabled
  171.     Algorithm presented.
  172. Few people have tried to implement this.
  173.  
  174. 13. Recent Changes in Mobile IPv6
  175. draft-ietf-mobileip-ipv6-03.txt  
  176. Presented by David Johnson, CMU.
  177.  
  178. One implementation (CMU)
  179. In addition 2 implementations barely started.
  180.  
  181. Overview of the resolved open issues.
  182.  
  183. Dynamic Home Agent Address Discovery
  184.  - Home-Agents Anycast address for home subnet.
  185.  - One home agent is reached with the anycast and it returns an error code
  186.    indicating that the MN should send another message with a specific address.
  187.  
  188. Issue: MN might need the addresses of all the HAs in case one of them
  189. is overloaded and will fail the registration attempt.
  190.  - Solve by having the HA that receives the anycast multicast to
  191.    all the HAs on the link.
  192.  - Make it clear that the HA only relays valid and authenticated binding
  193.    updates and not acts as a general forwarder of packets destined to the
  194.    home agent anycast address.
  195.  
  196. The IANA and the IPNGWG have been asked for a well-known anycast suffix.
  197.  
  198. Uses IPSEC for replay protection.
  199.  - Sequence counter used for reordering of binding updates.
  200.  - Sequence counter 16 bits not 32.
  201.  
  202. New home agent address option:
  203.  - Binding Update must be authenticated.
  204.  - Home Address Option Security
  205.     Home Address option does not need authentication unless the binding
  206.     update option is already included in the packet.
  207.  
  208. Comment: Draft needs all exact packet formats with respect to the
  209. Home Address option to make it clear what the packet looks like
  210. when the transport pseudo header checksum is computed and when the AH
  211. computation is performed.
  212.  
  213. Comment: Home address option header (144 bits) will be compressible
  214. by IPv6 header compression.
  215.  
  216. Movement Detection Timing
  217.  - MN needs to know when it missed a router advertisement.
  218.  - Add indicator of Router Advertisement broadcast interval (missing in
  219.    -03 draft)
  220.  
  221. Note: On Thursday there was consensus in the IPNGWG meeting on the
  222. use of the new home agent anycast address and requiring that all
  223. IPv6 nodes process the Home Address option.
  224.  
  225. 14. Changes in IPv6 that might impact Mobile IPv6.
  226. Jim Solomon.
  227. The IPng WG is considering
  228.  - Increasing the minimum link MTU to 1500-epsilon (enough to fit some
  229.    encapsulation headers with AH/ESP)
  230.  - Add text specifying that the routing header MAY be reversed if
  231.    authenticated.
  232.  - No consensus on "strict" routing header.  Loose is what is left.
  233. Asked the WG to consider the impact (if any) on Mobile IPv6.
  234.  
  235. 15. Mobile IP vs. NAT (Native Address Translation) Boxes
  236. Issue brought up by Charlie Perkins.
  237. NAT BOF last night.  NAT boxes are selling well.  
  238. Home addresses are losing their meaning.  Implications for Mobile IP? 
  239. One view: NAT may preclude full functionality.
  240.  
  241. 16. Layer 2 Tunneling Protocol (L2TP)
  242. Issue brought up by Charlie Perkins.
  243. Should this be considered?  Only affects IPv4.  2003 is only being used by MIP.
  244.  Chairs pointed out that a new WG is being formed to look at all tunneling
  245. (except IPv6 tunneling). Perhaps issues relating to L2TP should
  246. be discussed in that WG.
  247.  
  248.  
  249.