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