home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mobileip-tunnel-reverse-00.txt < prev    next >
Text File  |  1997-01-31  |  25KB  |  728 lines
  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                            G. Montenegro
  5. INTERNET DRAFT                                    Sun Microsystems, Inc.
  6.                                                         January 31, 1996
  7.  
  8.                     Reverse Tunneling for Mobile IP
  9.                draft-ietf-mobileip-tunnel-reverse-00.txt
  10.  
  11. Status of This Memo
  12.  
  13.    This document is a submission by the Mobile IP Working Group of the
  14.    Internet Engineering Task Force (IETF). Comments should be submitted
  15.    to the Working Group mailing list at "mobile-ip@SmallWorks.COM".
  16.  
  17.    Distribution of this memo is unlimited.
  18.  
  19.    This document is an Internet-Draft.  Internet-Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working groups.  Note that other groups may also distribute
  22.    working documents as Internet-Drafts.
  23.  
  24.    Internet-Drafts are draft documents valid for a maximum of six
  25.    months and may be updated, replaced, or obsoleted by other documents
  26.    at any time.  It is inappropriate to use Internet- Drafts as
  27.    reference material or to cite them other than as ``work in
  28.    progress.''
  29.  
  30.    To learn the current status of any Internet-Draft, please check the
  31.    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
  32.    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  33.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  34.    ftp.isi.edu (US West Coast).
  35.  
  36.  
  37. Abstract
  38.  
  39.    Mobile IP uses tunneling from the home agent to the mobile node's
  40.    care-of address, but rarely in the reverse direction.  Usually, a
  41.    mobile node sends its packets through a router on the foreign net,
  42.    and assumes that routing is independent of source address.  When
  43.    this assumption is not true, it is convenient to establish a
  44.    topologically correct reverse tunnel from the care-of address to the
  45.    home agent.
  46.  
  47.    This document proposes backwards-compatible extensions to Mobile IP
  48.    in order to support topologically correct reverse tunnels.  This
  49.    document does not attempt to solve the problems posed by firewalls
  50.    located between the home agent and the mobile node's care-of
  51.    address.
  52.  
  53.  
  54.  
  55. Montenegro               Expires July 31, 1997                  [Page 1]
  56.  
  57. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  58.  
  59.  
  60. 1. Introduction
  61.  
  62.    Section 1.3 of the Mobile IP specification [1] lists the following
  63.    assumption:
  64.  
  65.       It is assumed that IP unicast datagrams are routed based on the
  66.       destination address in the datagram header (i.e., not by source
  67.       address).
  68.  
  69.    Because of security concerns (e.g. IP spoofing attacks), and in
  70.    accordance with the IAB [8] and CERT [3] advisories to this effect,
  71.    routers that break this assumption are increasingly more common.
  72.  
  73.    In the presence of such routers, the source and destination IP
  74.    address in a packet must be topologically correct. The forward
  75.    tunnel complies with this, as its endpoints (home agent address and
  76.    care-of address) are properly assigned addresses for their
  77.    respective locations. On the other hand, the source IP address of a
  78.    packet transmitted by the mobile node does not correspond to the
  79.    location from where it emanates.
  80.  
  81.    This document discusses topologically correct reverse tunnels.
  82.  
  83.    Mobile IP does dictate the use of reverse tunnels in the context of
  84.    multicast datagram routing and mobile routers. However, the source
  85.    IP address is set to the mobile node's home address, so these
  86.    tunnels are not topologically correct.
  87.  
  88.    Notice that there are several uses for reverse tunnels regardless of
  89.    their topological correctness:
  90.  
  91.       - Mobile routers: reverse tunnels obviate the need for recursive
  92.         tunneling [1].
  93.  
  94.       - Multicast: reverse tunnels enable a mobile node away from home
  95.         to (1) join multicast groups in its home network, and (2)
  96.         transmit multicast packets such that they emanate from its home
  97.         network [1].
  98.  
  99.       - The TTL of packets sent by the mobile node (particularly when
  100.         it addresses other hosts in its home network) may be so low
  101.         that they may expire before reaching their destination.  A
  102.         reverse tunnel solves the problem as it represents a TTL
  103.         decrement of one [5].
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. Montenegro               Expires July 31, 1997                  [Page 2]
  112.  
  113. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  114.  
  115.  
  116. 1.1. Terminology
  117.  
  118.    The discussion below uses terms defined in the Mobile IP
  119.    specification.  Additionally, it uses the following terms:
  120.  
  121.       Forward Tunnel
  122.  
  123.          A tunnel that shuttles packets towards the mobile node. It
  124.          starts at the home agent, and ends at the mobile node's
  125.          care-of address.
  126.  
  127.       Reverse Tunnel
  128.  
  129.          A tunnel that starts at the mobile node's care-of address and
  130.          terminates at the home agent.
  131.  
  132.       Light-weight mobile node
  133.  
  134.          A mobile node that relies on a separate foreign agent for
  135.          tunneling services (i.e. the care-of address belongs to the
  136.          foreign agent).
  137.  
  138.  
  139. 1.2. Assumptions
  140.  
  141.    Mobility is constrained to one IP address space (e.g. the routing
  142.    fabric between, say, the mobile node and the home agent is not
  143.    partitioned into a "private" and a "public" network).
  144.  
  145.    This document does not attempt to solve the firewall traversal
  146.    problem. Rather, it assumes one of the following is true:
  147.  
  148.       - There are no intervening firewalls along the path of the
  149.         tunneled packets.
  150.  
  151.       - Any intervening firewalls share the security association
  152.         necessary to process any authentication [6] or encryption [7]
  153.         headers which may have been added to the tunneled packets.
  154.  
  155.    The reverse tunnels considered here are symmetric, that is, they use
  156.    the same configuration (encapsulation method, IP address endpoints)
  157.    as the forward tunnel. IP in IP encapsulation [2] is assumed unless
  158.    stated otherwise.
  159.  
  160.    Route optimization [4] introduces forward tunnels initiated at a
  161.    correspondent host.  Since a mobile node cannot know if the
  162.    correspondent host can decapsulate packets, reverse tunnels in that
  163.    context are not discussed here.
  164.  
  165.  
  166.  
  167. Montenegro               Expires July 31, 1997                  [Page 3]
  168.  
  169. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  170.  
  171.  
  172. 1.3. Justification
  173.  
  174.    Why not let the mobile node itself initiate the tunnel to the home
  175.    agent?  This is indeed what it should do if it is already operating
  176.    with a topologically significant co-located address.
  177.  
  178.    However, one of the primary objectives of the Mobile IP
  179.    specification is to not *require* this mode of operation.
  180.  
  181.    The mechanisms outlined in this document are primarily intended for
  182.    use by mobile nodes that rely on the foreign agent for forward
  183.    tunnel support. It is desirable to continue supporting these
  184.    "lightweight" mobile nodes, even in the presence of filtering
  185.    routers.
  186.  
  187.  
  188. 2. Overview
  189.  
  190.    A light-weight mobile node arrives at a foreign net, listens for
  191.    advertisements and selects a foreign agent that supports reverse
  192.    tunnels. It requests this service when it registers through the
  193.    selected foreign agent. At this time, and depending on how the
  194.    mobile node wishes to deliver packets to the foreign agent, it also
  195.    requests either the lightweight or the encapsulating style of
  196.    delivery (section 5).
  197.  
  198.    In the lightweight delivery style, the mobile node designates the
  199.    foreign agent as its default router and proceeds to send packets as
  200.    usual. The foreign agent intercepts them, and tunnels them to the
  201.    home agent.
  202.  
  203.    In the encapsulating delivery style, the mobile node encapsulates
  204.    all its outgoing packets to the foreign agent.  The foreign agent
  205.    decapsulates and tunnels again, this time, directly to the home
  206.    agent.
  207.  
  208.  
  209. 3. New Packet Formats
  210.  
  211.  
  212. 3.1. Agent Advertisements: Mobile Service Extension
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Montenegro               Expires July 31, 1997                  [Page 4]
  224.  
  225. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  226.  
  227.  
  228.     0                   1                   2                   3
  229.     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
  230.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  231.    |     Type      |    Length     |        Sequence Number        |
  232.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  233.    |           Lifetime            |R|B|H|F|M|G|V|T|  reserved     |
  234.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  235.    |                  zero or more Care-of Addresses               |
  236.    |                              ...                              |
  237.  
  238.    The only change to the Mobile Service Extension [1] is the
  239.    additional 'T' bit:
  240.  
  241.       T        Agent offers reverse tunneling service.
  242.  
  243.    A foreign agent that sets the 'T' bit MUST support the two delivery
  244.    styles currently supported (section 5).
  245.  
  246.    Using this information, a mobile node is able to choose a foreign
  247.    agent that supports reverse tunnels. Notice that if a mobile node
  248.    does not understand this bit, it simply ignores it.
  249.  
  250.  
  251. 3.2. Registration Request
  252.  
  253.    Reverse tunneling support is added directly into the Registration
  254.    Request by using one of the "rsvd" bits.  If a foreign or home agent
  255.    that does not support reverse tunnels receives a request with the
  256.    'T' bit set, the Registration Request fails. This results in a
  257.    registration denial (failure codes are specified in section 3.4).
  258.  
  259.    Most home agents would not object to providing reverse tunnel
  260.    support, because they "SHOULD be able to decapsulate and further
  261.    deliver packets addressed to themselves, sent by a mobile node"
  262.    [1].  In the case of topologically correct reverse tunnels, the
  263.    packets are not sent by the mobile node as distinguished by its home
  264.    address.  Rather, the outermost (encapsulating) IP source address on
  265.    such datagrams is the care-of address of the mobile node.
  266.    Nevertheless, home agents  probably already support the required
  267.    decapsulation and further forwarding.
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279. Montenegro               Expires July 31, 1997                  [Page 5]
  280.  
  281. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  282.  
  283.  
  284.     0                   1                   2                   3
  285.     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
  286.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  287.    |     Type      |S|B|D|M|G|V|T|-|          Lifetime             |
  288.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  289.    |                          Home Address                         |
  290.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  291.    |                           Home Agent                          |
  292.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  293.    |                        Care-of Address                        |
  294.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  295.    |                         Identification                        |
  296.    |                                                               |
  297.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.    | Extensions ...
  299.    +-+-+-+-+-+-+-+-
  300.  
  301.    The only change to the Registration Request packet is the additional
  302.    'T' bit:
  303.  
  304.       T        If the 'T' bit is set, the mobile node asks its home
  305.                agent to accept a reverse tunnel from the care-of
  306.                address. Lightweight mobile nodes ask the foreign
  307.                agent to reverse-tunnel its packets.
  308.  
  309. 3.3. Reverse Tunnel Extension
  310.  
  311.    The Reverse Tunnel Extension is used to further specify reverse
  312.    tunneling behavior. Currently, it is only possible to request the
  313.    encapsulating style of delivery, but future behavior may be
  314.    defined.  The Reverse Tunnel Extension MUST NOT be included if the
  315.    'T' bit is not set in the Registration Request.
  316.  
  317.    If this extension is absent, or if no style is explicitly requested,
  318.    the Lightweight Delivery is assumed.  Besides the latter, currently
  319.    only the Encapsulating style is defined (section 5).
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335. Montenegro               Expires July 31, 1997                  [Page 6]
  336.  
  337. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  338.  
  339.  
  340.     0                   1                   2                   3
  341.     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
  342.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  343.    |     Type      |     Length    |E|          reserved           |
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.  
  346.       Type     128
  347.  
  348.       Length   2
  349.  
  350.       E        Encapsulating style of delivery. Encapsulation is done
  351.                according to what was negotiated for the forward tunnel
  352.                (i.e., IP in IP is assumed unless specified otherwise).
  353.  
  354.       reserved Ignored upon reception. Must be set to zero when
  355.                transmitting.
  356.  
  357.  
  358. 3.4. New Registration Reply Codes
  359.  
  360.    Foreign and home agent replies must convey if the reverse tunnel
  361.    request failed.  Four new reply codes are defined. The use of codes
  362.    74 and 137 is preferred over code 70 for foreign agents and code 134
  363.    for home agents [1]:
  364.  
  365.       Service denied by the foreign agent:
  366.  
  367.       74 requested reverse tunnel unavailable
  368.       75 reverse tunnel is mandatory and 'T' bit not set
  369.  
  370.    and
  371.  
  372.       Service denied by the home agent:
  373.  
  374.       137 requested reverse tunnel unavailable
  375.       138 reverse tunnel is mandatory and 'T' bit not set
  376.  
  377.  
  378. 4. Changes in Protocol Behavior
  379.  
  380.    Reverse tunnels must be handled appropriately by the different
  381.    mobility entities. Differences in protocol behavior with respect to
  382.    the Mobile IP specification are:
  383.  
  384.  
  385. 4.1. Mobile Node Considerations
  386.  
  387.    A mobile node sets the 'T' bit in its Registration Request to
  388.  
  389.  
  390.  
  391. Montenegro               Expires July 31, 1997                  [Page 7]
  392.  
  393. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  394.  
  395.  
  396.    petition a reverse tunnel. It may optionally also include a
  397.    Reverse Tunnel Extension. Possible outcomes are:
  398.  
  399.       - The foreign agent returns a registration denial. Depending on
  400.         the reply code and following the error checking guidelines in
  401.         [1], the mobile node MAY try zeroing the 'T' bit, eliminating
  402.         the Reverse Tunnel Extension (if one was present), and issuing
  403.         a new registration.
  404.  
  405.       - The home agent returns a registration denial. Depending on the
  406.         reply code and following the error checking guidelines in [1],
  407.         the mobile node MAY try zeroing the 'T' bit, eliminating the
  408.         Reverse Tunnel Extension (if one was present), and issuing a
  409.         new registration.
  410.  
  411.       - The home agent returns a Registration Reply indicating that the
  412.         service will be provided.
  413.  
  414.    In this last case, the mobile node has succeeded in establishing a
  415.    reverse tunnel between its care-of address and its home agent.  If
  416.    the mobile node is operating with a co-located address, it SHOULD
  417.    encapsulate all outgoing data such that the destination address of
  418.    the outer header is the home agent. Not doing so does not
  419.    necessarily preclude data transmission, but it defeats the purpose
  420.    of the reverse tunnel.
  421.  
  422.    If the care-of address belongs to a separate foreign agent, the
  423.    mobile node MUST employ whatever delivery style was requested
  424.    (lightweight or encapsulated) and proceed as specified in section
  425.    5.
  426.  
  427.  
  428. 4.2. Foreign Agent Considerations
  429.  
  430.    A foreign agent that receives a Registration Request with the 'T'
  431.    bit set MAY either:
  432.  
  433.       - Return a Registration Reply denying the request. Valid return
  434.         codes are 74 (requested reverse tunnel unavailable) or 70
  435.         (poorly formed request). Code 74 is preferred.
  436.  
  437.       - Verify the packet according to [1] and then relay it to the
  438.         home agent.
  439.  
  440.    Upon receipt of a Registration Reply that satisfies validity checks,
  441.    it MUST update its visitor list, including indication that this
  442.    mobile node has been granted a reverse tunnel and the delivery style
  443.    expected (section 5).
  444.  
  445.  
  446.  
  447. Montenegro               Expires July 31, 1997                  [Page 8]
  448.  
  449. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  450.  
  451.  
  452.    While this visitor list entry is in effect, the foreign agent MUST
  453.    process incoming traffic according to the delivery style,
  454.    encapsulate it and tunnel it from the care-of address to the home
  455.    agent's address.
  456.  
  457.  
  458. 4.3. Home Agent Considerations
  459.  
  460.    A home agent that receives a Registration Request with the 'T' bit
  461.    set processes the packet as specified in the Mobile IP specification
  462.    [1]. As a result, it determines if it can accomodate the forward
  463.    tunnel request. As a last check, the home agent verifies that it can
  464.    support a reverse tunnel with the same configuration.
  465.  
  466.    If it can, the home agent sends back a Registration Reply with code
  467.    0 or 1. A registration denial should send back code 137 (requested
  468.    reverse tunnel unavailable) or 134 (poorly formed Request).  Code
  469.    137 is preferred.
  470.  
  471.    After a successful registration, the home agent will receive
  472.    encapsulated packets addressed to it. For each such packet it MAY
  473.    search for a mobility binding whose care-of address is the source of
  474.    the outer header, and whose mobile node address is the source of the
  475.    inner header.
  476.  
  477.    The home agent MUST decapsulate, recover the original packet, and
  478.    then forward it on behalf of its sender (the mobile node) to the
  479.    destination address (the correspondent host).
  480.  
  481.  
  482. 5. Mobile Node to Foreign Agent Delivery Styles
  483.  
  484.  
  485. 5.1. Lightweight Delivery Style
  486.  
  487.    This delivery mechanism is very simple to implement, and uses small
  488.    (non-encapsulated) packets on the link between the mobile node and
  489.    the foreign agent (potentially a very slow link).  However, it only
  490.    supports reverse-tunneling of unicast packets.
  491.  
  492.    It is achieved by the mobile node's designating the foreign agent as
  493.    its default router Not doing so will not guarantee encapsulation of
  494.    all the mobile node's outgoing traffic, and defeats the purpose of
  495.    the reverse tunnel. The foreign agent must modify its forwarding
  496.    function to detect packets sent by the mobile node, and
  497.    re-encapsulate before forwarding.
  498.  
  499.  
  500.  
  501.  
  502.  
  503. Montenegro               Expires July 31, 1997                  [Page 9]
  504.  
  505. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  506.  
  507.  
  508.    Packet format received by the foreign agent (lightweight delivery):
  509.  
  510.        Data Link fields:
  511.          Source Address = mobile node's MAC address
  512.          Destination Address = foreign agent's MAC address
  513.        IP fields:
  514.          Source Address = mobile node's home address
  515.          Destination Address = correspondent host's address
  516.        Upper Layer Protocol
  517.  
  518.    Packet format forwarded by the foreign agent (lightweight delivery):
  519.  
  520.        Data Link fields:
  521.          Source Address = foreign agent's MAC address
  522.          Destination Address = next hop router's MAC address
  523.        IP fields (encapsulating header):
  524.          Source Address = foreign agent's address
  525.          Destination Address = home agent's address
  526.          Protocol field: 4 (IP in IP)
  527.        IP fields (original header):
  528.          Source Address = mobile node's home address
  529.          Destination Address = correspondent host's address
  530.        Upper Layer Protocol
  531.  
  532.  
  533. 5.2. Encapsulating Delivery Style
  534.  
  535.    This mechanism requires that the mobile node implement
  536.    encapsulation. The mobile node explicitly directs packets at the
  537.    foreign agent by designating it as the destination address in a new
  538.    outermost header.  Mobile nodes that wish to send either broadcast
  539.    or multicast packets MUST use encapsulating delivery.
  540.  
  541.    The foreign agent does not have to modify its forwarding function.
  542.    Rather, it receives the encapsulated packets and after verifying
  543.    that they were sent by the mobile node, recovers the inner packets,
  544.    re-encapsulates them and sends them to the home agent.
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Montenegro               Expires July 31, 1997                 [Page 10]
  560.  
  561. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  562.  
  563.  
  564.    Packet format received by the foreign agent (encapsulated delivery):
  565.  
  566.        Data Link fields:
  567.          Source Address = mobile node's MAC address
  568.          Destination Address = foreign agent's MAC address
  569.        IP fields (encapsulating header):
  570.          Source Address = mobile node's address
  571.          Destination Address = foreign agent's address
  572.          Protocol field: 4 (IP in IP)
  573.        IP fields (original header):
  574.          Source Address = mobile node's home address
  575.          Destination Address = correspondent host's address
  576.        Upper Layer Protocol
  577.  
  578.    Packet format forwarded by the foreign agent (encapsulated delivery):
  579.  
  580.        Data Link fields:
  581.          Source Address = foreign agent's MAC address
  582.          Destination Address = next hop router's MAC address
  583.        IP fields (encapsulating header):
  584.          Source Address = foreign agent's address
  585.          Destination Address = home agent's address
  586.          Protocol field: 4 (IP in IP)
  587.        IP fields (original header):
  588.          Source Address = mobile node's home address
  589.          Destination Address = correspondent host's address
  590.        Upper Layer Protocol
  591.  
  592.  
  593. 5.3. Support for Broadcast and Multicast Datagrams
  594.  
  595.    If a mobile node is operating with a co-located address, broadcast
  596.    and multicast datagrams are handled according to Sections 4.3 and
  597.    4.4 of the Mobile IP specification [1]. Light-weight mobile nodes
  598.    MAY have their broadcast and multicast datagrams reverse-tunneled by
  599.    the foreign agent.  However, this requires the use of the the
  600.    encapulating delivery style.
  601.  
  602.    This delivers the datagram only to the foreign agent.  The latter
  603.    decapsulates it and then processes it as any other packet from the
  604.    mobile node, namely, by reverse tunneling it to the home agent.
  605.  
  606.  
  607. 6. Security Considerations
  608.  
  609.    The extensions outlined in this document are subject to the security
  610.    considerations outlined in the Mobile IP specification [1].
  611.    Essentialy, creation of both forward and reverse tunnels involves an
  612.  
  613.  
  614.  
  615. Montenegro               Expires July 31, 1997                 [Page 11]
  616.  
  617. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  618.  
  619.  
  620.    authentication procedure, which reduces the risk for attack.
  621.  
  622.    However, once the tunnel is set up, a malicious user could hijack it
  623.    to inject packets into the network. Reverse tunnels might exacerbate
  624.    this problem, because upon reaching the tunnel exit point packets
  625.    are forwarded beyond the local network. This concern is also present
  626.    in the Mobile IP specification, as it already dictates the use of
  627.    reverse tunnels for certain applications.
  628.  
  629.    There has been some concern regarding the long-term effectiveness of
  630.    reverse-tunneling in the presence of ingress filtering. The
  631.    conjecture is that network administrators will target
  632.    reverse-tunneled packets (IP in IP encapsulated packets) for
  633.    filtering. The ingress filtering recommendation spells out why this
  634.    is not the case [8]:
  635.  
  636.       Tracking the source of an attack is simplified when the source is
  637.       more likely to be "valid."
  638.  
  639.  
  640. 7. Acknowledgements
  641.  
  642.    The encapsulating style of delivery was proposed by Charlie Perkins.
  643.  
  644.  
  645. References
  646.  
  647.     [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996.
  648.  
  649.     [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October
  650.         1996.
  651.  
  652.     [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
  653.         and Hijacked Terminal Connections", CA-95:01, January 1995.
  654.         Available via anonymous ftp from info.cert.org in
  655.         /pub/cert_advisories.
  656.  
  657.     [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP --
  658.         work in progress, draft-ietf-mobileip-optim-05.txt, November
  659.         1996.
  660.  
  661.     [5] Manuel Rodriguez, private communication, August 1995.
  662.  
  663.     [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
  664.  
  665.     [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
  666.         August 1995.
  667.  
  668.  
  669.  
  670.  
  671. Montenegro               Expires July 31, 1997                 [Page 12]
  672.  
  673. INTERNET DRAFT      Reverse Tunneling for Mobile IP         January 1996
  674.  
  675.  
  676.     [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending
  677.         Against IP Source Address Spoofing -- work in progress,
  678.         draft-ferguson-ingress-filtering-01.txt, February 1996
  679.  
  680. Author's Address
  681.  
  682.           Gabriel E. Montenegro
  683.           Sun Microsystems, Inc.
  684.           2550 Garcia Avenue
  685.           Mailstop UMPK 15-214
  686.           Mountain View, California 94043-1100
  687.  
  688.           Tel: (415)786-6288
  689.           Fax: (415)786-6445
  690.  
  691.           gab@eng.sun.com
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727. Montenegro               Expires July 31, 1997                 [Page 13]
  728.