home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mobileip / mobileip-minutes-95oct.txt < prev    next >
Text File  |  1995-12-02  |  15KB  |  293 lines
  1. Editor's note: These minutes have not been edited.
  2.  
  3. Date: Mon, 27 Nov 95 10:54:35 EST
  4. Subject: Mobile-IP testing meeting minutes
  5. From: Frank Kastenholz <kasten@ftp.com>
  6.  
  7.  
  8. Reported by Frank Kastenholz 
  9.  
  10.  
  11. The Mobile IP Testathon was held the week of 23-28 October at FTP
  12. Software in North Andover Mass, USA.
  13.  
  14. Seven organizations attended the testathon. The following matrix shows
  15. the interoperability that was achieved:
  16.  
  17.    | FA                                              
  18. HA |   1    |   2    |   3    |   4    |   5    |   6
  19. ---+--------+--------+--------+--------+--------+--------
  20.  1 | 123567 | .2.... | 1..5.. | ...... | 1.35.7 | 1....7
  21.  2 | .23... | .2.... | ...... | ...... | ...... | ......
  22.  3 | 1..5.7 | ...... | ...... | .....7 | 1..5.7 | ......
  23.  4 | 1....7 | ...... | ...... | 1....7 | ...... | 1.....
  24.  5 | 1.35.. | ...... | ...5.. | ...... | 1235.7 | ......
  25.  6 | 1.35.7 | ...... | ...... | ...... | 1.35.. | ......
  26.  
  27. Note that we didn't start keeping detailed records of who
  28. interoperated with whom until the third day. Also, organization #2
  29. has to leave early and their interoperability record was mostly
  30. reconstructed from memory.
  31.  
  32. Organization #4 did not have mobile nodes; they had only agents.
  33.  
  34. Organization #7 did not have mobile agents, only nodes.
  35.  
  36. Organization #4 had only one machine they could work on so
  37. interoperability with them playing two or three roles (eg their home
  38. and foreign agent and someone else's mobile node) could not be tested.
  39.  
  40.  
  41. Even though there are many holes in the above matrix, all tests at
  42. interoperability succeeded. That is to say, the holes are not
  43. failures to interoperate, they are cases that were not tested. Since
  44. all attempted tests were successful we believe that the demonstrated
  45. interoperability was very high.
  46.  
  47. =============================================================================
  48.  
  49. Many issues arose during testing that we provisionally solved. It is,
  50. of course, up to the working group to decide on final solutions for
  51. these issues. All of the proposed solutions have some implementation
  52. experience behind them.
  53.  
  54. 1. Some stacks insist on padding ICMP packets to be an even number of
  55.    bytes long. This affects router advertisements with Mobility and
  56.    Address Mask Length extensions. Fortunately these stacks seem
  57.    to pad only with bytes of 0.
  58.  
  59.    The proposed solution is to allow padding of up to byte of '0' to be
  60.    added to the end of the advertisement packet to accomodate this.
  61.  
  62.    Some of the attendees believe that a 0 padding byte should be allowed
  63.    anywhere in the packets. Others do not. This is a matter that the
  64.    working group should resolve.
  65.  
  66. 2. The order of the Source and Destination addresses in the Minimal
  67.    encapsulation header were swapped at some point in time. The order
  68.    should be:
  69.  
  70.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  71.    |                 Original Destination Address                  |
  72.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  73.    :                    Original Source Address                    :
  74.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  75.  
  76.    and not
  77.  
  78.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  79.    |                   Original Source Address                     |
  80.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  81.    :                 Original Destination Address                  :
  82.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  83.  
  84.  
  85. 3. The specifications should say that the TTL of router advertisements
  86.    unicast to a Mobile Node (as a response to a solicitation) must be 1
  87.    to prevent routing of the advertisement.
  88.  
  89. 4. If a FA is sending an IP unicast response to a router solicitation,
  90.    it MUST be sent to the hardware address of the sender of the
  91.    solicitation.
  92.  
  93. 5. Router discovery solicitation must have a TTL of 1.
  94.  
  95. 6. The specification should say that it is invalid for a router
  96.    advertisement with both the FA and HA bits 0 (i.e. at least one of
  97.    the bits MUST be set). In addition, the Registration Required and
  98.    Busy bits MUST NOT be set unless the FA bit is also set.
  99.  
  100. 7. The specifications should say that, with two exceptions, if a
  101.    registration request or response contains an authentication 
  102.    extension then that extension MUST be checked before any other fields
  103.    of the packet are examined, used, or acted upon. The first exception
  104.    is that if the packet is a registration resopnse AND the code field
  105.    is one of the authentication-failure codes; this case indicates that
  106.    there probably is a failure in the key-management and that the two
  107.    parties are using different keys, algorithms, or spis.
  108.  
  109.    The second exception is when the error code is one of the FA error
  110.    codes and the Mobile Node and FA do not share a security association.
  111.  
  112. 8. Foreign Agents as Routers. 
  113.    After much talking and hacking of code, we've come up with the following
  114.    proposals:
  115.  
  116.    Advertisement code 16 means that the FA will not route common traffic
  117.    but _may_ route traffic for the MNs. The router-advertisement will
  118.    contain 0 or more IP addresses. The following rules apply:
  119.    - If the advertisement contains no addresses then the FA MUST
  120.      be able to act as a router. In this case, the source IP Address
  121.      of the packet is used as a router-address.
  122.    - If the FA can not act as a router then the advertisement MUST contain
  123.      one or more IP addresses and these IP Addresses are the addresses of
  124.      one or more routers that the MN can use.
  125.    - A MN SHOULD prefer IP Addresses advertised in the router-discovery
  126.      advertisement packet.
  127.    - IF a FA can act as a router, there should be a configuration switch
  128.      to turn this on or off.
  129.    Note that the addresses in the router-discovery part of the packet 
  130.    might not be the addresses of the FA itself That is, the FA is allowed
  131.    to "proxy advertise" for other routers, such as those that do not
  132.    partake of router-disco (such as the router we were using during the
  133.    testathon :-)
  134.  
  135.    The general intent is that the FA *MUST* _be_ _able_ _to_ serve as
  136.    a first-hop router; the MN *SHOULD* pick the highest preference
  137.    router address listed in the RFC1256 portion (else the IP source
  138.    address of the FA's advertisment) as its default router. This 
  139.    is somewhat in conflict with the second point in the preceeding
  140.    paragraph but my notes are a bit confused on this point and
  141.    the working group must make some decisions to clarify things.
  142.  
  143.    An additional point is that including 0 addresses in the router 
  144.    advertisement is functionally identical to including 1 address and
  145.    having that address be the address of the FA's interface on the foreign
  146.    subnet. The latter preserves the semantics of RFC1256 while not 
  147.    sacrificing any functionality (though at the expense of a slightly
  148.    larger advertisement packet). The working group should decide which of
  149.    the two techniques to specify.
  150.  
  151. 9. If the FA does not include subnet masks in the advertisements then the
  152.     MN basically assumes a mask of 0xffffffff and the FA MUST provide
  153.     routing services. If the FA can not do routing then it MUST
  154.     include subnet masks in the advertisement and MUST have >0 routers
  155.     in the router advertisement.
  156.  
  157. 10. Having the FA do VJ header compression is desireable for slow
  158.    links (such as some radio types). Additions should be made to
  159.    the router advertisement to allow the FA to indicate that it
  160.    supports VJ Header Compression. 
  161.  
  162.    The working group should develop a general-purpose compression
  163.    extension to allow the FA to advertise this capability to the MNs.
  164.    The extension should advertise any parameters needed to properly
  165.    use the compression techniques.
  166.  
  167.    When the MN transmits, VJ header compression is only possible if
  168.    all of the MN's packets first go to a single 'decompressing' node;
  169.    for example, FA if it always acts as the first-hop router.
  170.  
  171. 11. The agents must check the registration requests to ensure that
  172.    the COA and HA are different. Recursive tunneling can result.
  173.    We found this out the hard way.
  174.  
  175. 12. The protocol specification says that the length of the prefix length
  176.    extension is 2. This is incorrect.
  177.  
  178.    The prefix length extension should have one prefix-length per
  179.    router address in the router advertisement (i.e. RFC1256)
  180.    part of the advertisement packet.
  181.  
  182. 13. If a MN sends an unauthenticated request and the HA or FA are
  183.    configured to require a MN-HA or MN-FA authentication then the
  184.    request should be rejected with an authentication failed error.
  185.    Same if the MN sends an authenticated request and the HA or FA
  186.    is configured to NOT do authentication (or does not have the
  187.    SPI value).
  188.  
  189.    The protocol requires that all registration requests and responses
  190.    be authenticated. Receipt of an unauthenticated request or response
  191.    while incorrect under the protocol _could_ also indicate a security
  192.    violation (eg a bad-guy trying to send phony registrations). Thus,
  193.    unauthenticated requests or responses should be treated as an 
  194.    authentication failure which would indicate a possible security
  195.    breach.
  196.  
  197. 14. Issues surrounding the 'lifetime' of router advertisements arose.
  198.    The technique which we all seemed to settle on was that the lifetime
  199.    in the router-advertisement part of the agent-advertisement was the
  200.    life of the agent advertisement -- that is, a mobile node would
  201.    delete the entry from its list of known agents in that amount of time.
  202.    The FA advertisement period should be 1/3 of the lifetime -- that is
  203.    the time between fa advertisements should be 1/3 of the advert lifetime,
  204.    so 3 advertisements in a row must be lost for the entry to time out.
  205.  
  206. 15. All foreign agents on a given subnet must include subnet masks
  207.     in their advertisements or none of them must include masks. Weirdness
  208.     results if things are mixed. Lots of thrashing back and forth.
  209.  
  210. 16. ARP. ARP can cause severe problems. Basically, the MN must NEVER ARP on
  211.    the foreign subnets using its Home Address as the ARP Sender Protocol
  212.    Address. If that IP address gets stuck in some node's ARP cache on the
  213.    foreign subnet then bad things could happen. Consider the following
  214.    topology:
  215.  
  216.                          Mobile        Foreign
  217.                           Node          Agent
  218.                            |              |
  219.     ===='foreign subnet'=====================================================
  220.        \                                                 |
  221.        Router                                       File Server
  222.        /                                                 |
  223.     ===='home subnet'========================================================
  224.                          |
  225.                         Home
  226.             agent
  227.  
  228.    First, if the router gets the real MAC address of the MN in its cache
  229.    it might send packets addressed to the MN to the foreign subnet. As long
  230.    as he MN is on that subnet it's ok. If the MN moves someplace else
  231.    (eg a third subnet not in the picture) AND packets that should be sent
  232.    to it go through the router then it won't work. The packets will go
  233.    to the foreign subnet, not to the home subnet where the HA can relay them.
  234.  
  235.    Furthermore, if the MN broadcasts an ARP request, the File Server will put
  236.    an entry in its ARP cache for the MN's IP address and MAC Address. Then
  237.    whenever it sends a packet to the MN, it will route those packets to an
  238.    interface based on the destination address of the packet (i.e. pick the
  239.    home subnet interface) and use the MAC address from the ARP cache
  240.    (i.e. the MAC address of the MN). but the MN is not on that subnet.
  241.    The HA should receive the packets to relay them, but if the packets
  242.    have the MN's MAC address, the HA won't receive them....
  243.  
  244.    Also there is the gratuitous startup ARP problem. Lots of nodes send
  245.    an ARP with their own source and destination IP address to do duplicate
  246.    address detection. Lots of other nodes might place entries in their
  247.    ARP cache based on this ARP. this leads to the problems described above.
  248.  
  249.    We've come up with the following possible solution:
  250.    1) Mobile Nodes never ARP with their own IP Address as the source address
  251.       when they are on the foreign subnet, they should always send packets
  252.       to the FA who will then relay the packets to the right spot.
  253.    2) The FA must never send a redirect to the MN since the MN might then ARP
  254.       for whatever the target of the redirect is.
  255.    3) When sending the gratuitous startup duplicate address detect ARP, a node
  256.       should use a 'well known' source address that no one will ever receive
  257.       on. For example, 255.255.255.254. For duplicate address detection, this
  258.       well known source address will mean 'this is a duplicate address
  259.       detection packet for the IP Address in the target address'. All nodes
  260.       will respond to this ARP 'properly'. If a node is not modified to
  261.       understand the significance of this address then that node will not
  262.       know of a duplicate on the network (this is a disadvantage). But the
  263.       node sending the ARP will know that there's a duplicate since someone
  264.       will respond. if the receiving node knows that this address means
  265.       "Duplicate ARP Detect" then both the receiver and the transmitter
  266.       will know.
  267.  
  268.     4) If a node must send an ARP request when mobile, it should use a
  269.       second well known and ignorable IP Address as the source, suggest
  270.       255.255.255.253. This src address prevents the receiver of the request
  271.       from saying 'duplicate address in use'
  272.  
  273.    This technique means that entries for the well-known addresses will be
  274.    placed in the ARP caches of nodes receiving the requests. However, these
  275.    addresses are not the address of the mobile node, nor any other node on
  276.    the network so no one will ever try to send a packet to them so none of
  277.    the problems with respect to the mobile node stuff will appear, and all
  278.    the old stuff will continue to work (with the exception of a part of the
  279.    duplicate address detection stuff....)
  280.  
  281.    Aside, some implementations might check the source ip address and reject
  282.    the arp request if the address is not a class a/b/c address. if this
  283.    is true then we'll have to reserve some 'valid' class a/b/c address (maybe
  284.    pull from net 10, maybe just allocate a class-c net...)
  285.  
  286.  
  287.    If this idea is accepted by the WG, Dave Johnson and I will write up a
  288.    brief note explaining this and submit it for RFC-hood. We figure that
  289.    a separate RFC is probably preferred since this technique might find uses
  290.    in other areas.
  291.  
  292.  
  293.