home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  9KB  |  207 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5.                  38th IETF Meeting Minutes (Memphis)
  6.                        Reported by Frank Ciotti
  7.                        (edited by Jim Solomon)
  8.  
  9. I) Mobile IPv4 -- 4/7/97 0930
  10.  
  11.  1. Dave Johnson reminded everyone about MobiCom '97
  12.     Sept 26-30  Budapest, Hungary
  13.  
  14.  2. Jim Solomon -- PPP IPCP Mobile IP Option draft
  15.     <draft-ietf-pppext-ipcp-mip-00.txt> 
  16.  
  17.      Main benefits:
  18.        1. allows FA's to be deployed which have no means for assigning
  19.           unique addresses to MNs.
  20.        2. Less wasteful of IP addr space - no unique IP addr
  21.           assignment to MN unless one is required.
  22.  
  23.      Issues:
  24.       - Co-located COA assignment mechanism might be redundant with
  25.         the IP-Address option semantics.  Jim and Steve to
  26.         investigate whether the IP-Address option can be used instead.
  27.     
  28.      Jim to present to PPPEXT working group and to move the draft
  29.      forward.
  30.     
  31.  3. Jim Solomon on behalf of Gabriel Montenegro -- Reverse Tunneling
  32.     draft <draft-ietf-mobileip-tunnel-reverse-01.txt>
  33.  
  34.     Issues:
  35.       - MN *MUST* use FA as ONLY rtr, not simply default router.
  36.       - Major security hole with reverse tunneling: Bad Guy can
  37.         conspire to get an FA to reverse tunnel the packets generated
  38.         by a Good Guy to a bogus location [possibly causing a routing
  39.         loop -- ed.]  Gabriel to address security concerns before this
  40.         document moves forward.
  41.       - Things to clarify in the draft:
  42.         + Why use 16 bits for a 1-bit field in the Delivery Style
  43.           Extension?  Why not just use a "boolean" extension?
  44.         + Should the Registration Reply contain a list of the types of
  45.           encapsulation supported (IPIP vs MIN vs GRE)?
  46.         + If the MN is a router and is forwarding pkts, the MN should
  47.           encapsulate the datagrams itself before sending them to the FA.
  48.         + The draft states that the HA should only accept reverse
  49.           tunneled packets from the MN's COA.  This is incompatible
  50.           with generic IP in IP encapsulation (e.g., tunnels unrelated
  51.           to mobility) and provides no security since the COA can be
  52.           spoofed anyway.
  53.  
  54.     Chairs expressed concern that, despite numerous requests, these
  55.     issues had not been brought up on the mailing list before the
  56.     meeting.
  57.     
  58.  4. Vipul Gupta -- Firewall Traversal draft
  59.     <draft-ietf-mobileip-firewall-trav-00.txt> 
  60.     
  61.     Goals: Enable use of Mobile IP in the presence of multiple IPSEC
  62.            firewalls & private addresses.
  63.     
  64.     Issues:
  65.       - MTU can go to zero if there are large numbers of firewalls but
  66.         usually there will only be one or two.
  67.       - In future, all ESP transforms will have authentication too.
  68.       - We should keep the requirement that the FW is not necessarily
  69.         the HA and vice-versa.        
  70.       - IPv6 provides site-local addresses which perpetuates the
  71.         "private address" problem.  We should not drop "private
  72.         addresses" as a requirement.
  73.       - MIP is really first "consumer" of IPSEC services and IPSEC
  74.         doesn't really address policy concerns which is why all of
  75.         these issues are coming up.
  76.       - The AFT working group is wrestling with internal nodes getting
  77.         out through the firewall -- not external (authorized) nodes
  78.         getting inside the firewall.
  79.  
  80.     Open Issues:
  81.       - how does MN discover all firewalls?
  82.       - how does MN detect that it is "inside" versus "outside" the
  83.         firewalls. 
  84.     
  85.     CONCLUSION: we need to continue this exercise to see what develops
  86.     in terms of requirements, particularly with regard to policy, for
  87.     MNs, HAs, and firewalls.  Whether the MOBILEIP working group goes
  88.     beyond this, by specifying packet formats and message sequences,
  89.     is unclear.  This latter activity might be performed by the IPSEC
  90.     group.  The chairs have requested help from the Security Area to
  91.     assist in the firewall-traversal effort.
  92.  
  93.  5. Steve Glass -- FTP Software Interoperability Testathon Results
  94.  
  95.      - 18 attendees
  96.      - 10 implementations (6 corporations, 4 universities)
  97.      - 4 days of testing (lost 1 day due to Winter storm)
  98.      - 14 HA's, 13 FA's, 10 MN's
  99.      - co-located COAs obtained by manual configuration
  100.      - 'R' bit tested with co-located MNs
  101.      - reverse tunneling demonstrated
  102.      - Jim Solomon and Frank Kastenholz put together a list of issues
  103.        and will post them to the mailing list.
  104.      - Steve Glass will post more detailed results to the mailing
  105.        list.
  106.  
  107.     To get to draft standard we need:    
  108.      - Significant campus type deployment experience (at least "a
  109.        few" campuses with "many" people actually using MIP).
  110.      - Traversal over public network required.
  111.  
  112. II) Mobile IPv6 -- 4/8/97 1300
  113.  
  114.  Dave Johnson -- Mobility Support in IPv6
  115.  <draft-ietf-mobileip-ipv6-02.txt>
  116.  
  117.  Issues:
  118.  
  119.  1. Dynamic HA address discovery
  120.     - no directed broadcasts in IPv6;
  121.     - IPng wg does not like the multicast-in-anycast tunnel
  122.       discussed in San Jose because of denial-of-service attack;
  123.     - IPng wg prefers a change which requires *all* IPv6 routers
  124.       to recognize a "HA Discovery Anycast Packet" and emit it
  125.       as an all-nodes multicast on home link.
  126.     - authentication isn't an issue cuz all HAs *reject* this
  127.       anyway which, by definition, means they don't modify
  128.       behavior as a result.
  129.     - Is this an ICMP?  Destination Option?  UDP?  Other?
  130.       + Use of ICMP for HA Discover packet would make it easy for
  131.         routers to process since they must already implement
  132.         support for ICMP.
  133.  
  134.  2. How will a MN find an HA on its home network if its home
  135.     network is renumbered while it is away?  The general consensus
  136.     here was that this was an administrative issue since the Home
  137.     Address configured in the MN itself will also need to be
  138.     modified at the time the Home Network is renumbered.
  139.  
  140.  3. Replay protection for Binding Updates
  141.  
  142.     - We cannot use replay protection provided by IPSEC because
  143.       Binding Updates *must* be applied *only* in order.
  144.     - Choices:
  145.       a. Do our own replay protection.
  146.       b. Convince IPSEC wg to modify their replay protection 
  147.          to allow us to select an in-order option.
  148.       c. Use IPSEC replay prot *and* our own sequence number.
  149.       The best choice seems to be #3
  150.        + Lets IPSEC worry about re-keying before wrap around.
  151.        + Lets us worry only about sequencing.
  152.        + Similar to TCP seq # when using IPSEC replay protection.
  153.       Most people agreed with this choice.
  154.  
  155.  4. Multiple Routers on the Foreign Network
  156.  
  157.     Issues:
  158.      - MN can really only do neighbor unreachability detection with
  159.        its default router
  160.  
  161.     Solutions:
  162.      - Route packet to specific router:
  163.        + Use a routing header to first go to the correct rtr, then to
  164.          the COA.
  165.        + somewhat reintroduces the concept of FAs.
  166.      - Fix the problem outside of Mobile IP:
  167.        + This is a wireless problem, not a Mobile IP problem.
  168.        + Most likely a problem together w/mip, though.
  169.  
  170.     Consensus:  This is a wireless problem that needs to be fixed but
  171.     not in the Mobile IP working group.  Also, if this is an issue,
  172.     don't architect the system such that transceivers on the *same*
  173.     subnet have coverage overlap (i.e., make them separate links).
  174.  
  175.  5. Movement Detection Timing
  176.  
  177.     Proposal: Add a field (e.g., a Nominal Advertisement Interval
  178.     field) that lets MN know *exactly* how often the router is
  179.     advertising such that the MN can know *exactly* when it has missed
  180.     one.
  181.  
  182.     There were some concerns, but overall feeling was to submit the
  183.     proposal to the IPng working group.
  184.  
  185.  6. Other issues
  186.  
  187.     a. PROBLEM: If router B does not support sending a Binding Update
  188.        to router A after the MN moves from A to B, packets may be
  189.        dropped.
  190.  
  191.        SOLUTION: The spec should be changed to say the lifetime of the
  192.        Binding Update MUST (not SHOULD) be <= the registration
  193.        lifetime.
  194.  
  195.     b. PROBLEM:  Ingress Filtering might prevent MN from sending pkt
  196.        w/src addr = home address.
  197.  
  198.        PROPOSAL: Both the MN and the CH use the care-of address
  199.        instead of the MN's home addr.  The MN also sends a router
  200.        header to the CH to indicate the route back to MN home addr.
  201.        If the CH ever loses the routing information (power loss), the
  202.        CH will send the pkt to the care-of address, not the home
  203.        address.  The MN can detect it received the packet via its
  204.        care-of addr, not home addr, and send a routing header to the CH.
  205.  
  206.        Continue discussion on mailing list.
  207.