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-03.txt < prev    next >
Text File  |  1997-08-20  |  51KB  |  1,400 lines

  1.  
  2.  
  3.  
  4. Internet Engineering Task Force                    G. Montenegro, Editor
  5. INTERNET DRAFT                                    Sun Microsystems, Inc.
  6.                                                          August 10, 1997
  7.  
  8.                     Reverse Tunneling for Mobile IP
  9.                draft-ietf-mobileip-tunnel-reverse-03.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
  42.    network, and assumes that routing is independent of source address.
  43.    When 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 February 10, 1998                [Page 1]
  56.  
  57. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  58.  
  59.  
  60. Table of Contents
  61.  
  62. 1. Introduction ...................................................    3
  63. 1.1. Terminology ..................................................    4
  64. 1.2. Assumptions ..................................................    4
  65. 1.3. Justification ................................................    4
  66. 2. Overview .......................................................    5
  67. 3. New Packet Formats .............................................    5
  68. 3.1. Mobility Agent Advertisement Extension .......................    5
  69. 3.2. Registration Request .........................................    6
  70. 3.3. Encapsulating Delivery Style Extension .......................    7
  71. 3.4. Cookie Extensions ............................................    8
  72. 3.4.1 Mobile-Foreign Cookie Extension .............................    8
  73. 3.4.2 Foreign-Home Cookie Extension ...............................   10
  74. 3.5. New Registration Reply Codes .................................   11
  75. 4. Changes in Protocol Behavior ...................................   12
  76. 4.1. Mobile Node Considerations ...................................   12
  77. 4.1.1. Sending Registration Requests to the Foreign Agent .........   12
  78. 4.1.2. Receiving Registration Replies from the Foreign Agent ......   13
  79. 4.2. Foreign Agent Considerations .................................   14
  80. 4.2.1. Receiving Registration Requests from the Mobile Node .......   14
  81. 4.2.2. Relaying Registration Requests to the Home Agent ...........   15
  82. 4.3. Home Agent Considerations ....................................   16
  83. 4.3.1. Receiving Registration Requests from the Foreign Agent .....   16
  84. 4.3.2. Sending Registration Replies to the Foreign Agent ..........   17
  85. 5. Mobile Node to Foreign Agent Delivery Styles ...................   18
  86. 5.1. Direct Delivery Style ........................................   18
  87. 5.1.1. Packet Processing ..........................................   18
  88. 5.1.2. Packet Header Format and Fields ............................   18
  89. 5.2. Encapsulating Delivery Style .................................   19
  90. 5.2.1 Packet Processing ...........................................   20
  91. 5.2.2. Packet Header Format and Fields ............................   20
  92. 5.3. Support for Broadcast and Multicast Datagrams ................   21
  93. 5.4. Selective Reverse Tunneling ..................................   22
  94. 6. Security Considerations ........................................   22
  95. 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks .......   22
  96. 6.2. Ingress Filtering ............................................   23
  97. 7. Acknowledgements ...............................................   24
  98. References ........................................................   24
  99. Editor and Chair Addresses ........................................   24
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111. Montenegro             Expires February 10, 1998                [Page 2]
  112.  
  113. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  114.  
  115.  
  116. 1. Introduction
  117.  
  118.    Section 1.3 of the Mobile IP specification [1] lists the following
  119.    assumption:
  120.  
  121.       It is assumed that IP unicast datagrams are routed based on the
  122.       destination address in the datagram header (i.e., not by source
  123.       address).
  124.  
  125.    Because of security concerns (e.g. IP spoofing attacks), and in
  126.    accordance with the IAB [8] and CERT [3] advisories to this effect,
  127.    routers that break this assumption are increasingly more common.
  128.  
  129.    In the presence of such routers, the source and destination IP
  130.    address in a packet must be topologically correct. The forward
  131.    tunnel complies with this, as its endpoints (home agent address and
  132.    care-of address) are properly assigned addresses for their
  133.    respective locations. On the other hand, the source IP address of a
  134.    packet transmitted by the mobile node does not correspond to the
  135.    network prefix from where it emanates.
  136.  
  137.    This document discusses topologically correct reverse tunnels.
  138.  
  139.    Mobile IP does dictate the use of reverse tunnels in the context of
  140.    multicast datagram routing and mobile routers. However, the source
  141.    IP address is set to the mobile node's home address, so these
  142.    tunnels are not topologically correct.
  143.  
  144.    Notice that there are several uses for reverse tunnels regardless of
  145.    their topological correctness:
  146.  
  147.       - Mobile routers: reverse tunnels obviate the need for recursive
  148.         tunneling [1].
  149.  
  150.       - Multicast: reverse tunnels enable a mobile node away from home
  151.         to (1) join multicast groups in its home network, and (2)
  152.         transmit multicast packets such that they emanate from its home
  153.         network [1].
  154.  
  155.       - The TTL of packets sent by the mobile node (particularly when
  156.         sends packets to other hosts in its home network) may be so low
  157.         that they might expire before reaching their destination.  A
  158.         reverse tunnel solves the problem as it represents a TTL
  159.         decrement of one [5].
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167. Montenegro             Expires February 10, 1998                [Page 3]
  168.  
  169. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  170.  
  171.  
  172. 1.1. Terminology
  173.  
  174.    The discussion below uses terms defined in the Mobile IP
  175.    specification.  Additionally, it uses the following terms:
  176.  
  177.       Forward Tunnel
  178.  
  179.          A tunnel that shuttles packets towards the mobile node. It
  180.          starts at the home agent, and ends at the mobile node's
  181.          care-of address.
  182.  
  183.       Reverse Tunnel
  184.  
  185.          A tunnel that starts at the mobile node's care-of address and
  186.          terminates at the home agent.
  187.  
  188.  
  189. 1.2. Assumptions
  190.  
  191.    Mobility is constrained to a common IP address space (e.g. the
  192.    routing fabric between, say, the mobile node and the home agent is
  193.    not partitioned into a "private" and a "public" network).
  194.  
  195.    This document does not attempt to solve the firewall traversal
  196.    problem. Rather, it assumes one of the following is true:
  197.  
  198.       - There are no intervening firewalls along the path of the
  199.         tunneled packets.
  200.  
  201.       - Any intervening firewalls share the security association
  202.         necessary to process any authentication [6] or encryption [7]
  203.         headers which may have been added to the tunneled packets.
  204.  
  205.    The reverse tunnels considered here are symmetric, that is, they use
  206.    the same configuration (encapsulation method, IP address endpoints)
  207.    as the forward tunnel. IP in IP encapsulation [2] is assumed unless
  208.    stated otherwise.
  209.  
  210.    Route optimization [4] introduces forward tunnels initiated at a
  211.    correspondent host.  Since a mobile node may not know if the
  212.    correspondent host can decapsulate packets, reverse tunnels in that
  213.    context are not discussed here.
  214.  
  215.  
  216.  
  217. 1.3. Justification
  218.  
  219.    Why not let the mobile node itself initiate the tunnel to the home
  220.  
  221.  
  222.  
  223. Montenegro             Expires February 10, 1998                [Page 4]
  224.  
  225. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  226.  
  227.  
  228.    agent?  This is indeed what it should do if it is already operating
  229.    with a topologically correct co-located care-of address.
  230.  
  231.    However, one of the primary objectives of the Mobile IP
  232.    specification is not to require this mode of operation.
  233.  
  234.    The mechanisms outlined in this document are primarily intended for
  235.    use by mobile nodes that rely on the foreign agent for forward
  236.    tunnel support. It is desirable to continue supporting these mobile
  237.    nodes, even in the presence of filtering routers.
  238.  
  239.  
  240.  
  241. 2. Overview
  242.  
  243.    A mobile node arrives at a foreign network, listens for agent
  244.    advertisements and selects a foreign agent that supports reverse
  245.    tunnels.  It requests this service when it registers through the
  246.    selected foreign agent.  At this time, and depending on how the
  247.    mobile node wishes to deliver packets to the foreign agent, it also
  248.    requests either the Direct or the Encapsulating Delivery Style
  249.    (section 5).
  250.  
  251.    In the Direct Delivery Style, the mobile node designates the foreign
  252.    agent as its default router and proceeds to send packets directly to
  253.    the foreign agent, i.e., without encapsulation.  The foreign agent
  254.    intercepts them, and tunnels them to the home agent.
  255.  
  256.    In the Encapsulating Delivery Style, the mobile node encapsulates
  257.    all its outgoing packets to the foreign agent.  The foreign agent
  258.    decapsulates and re-tunnels them to the home agent, using the
  259.    foreign agent's care-of address as the entry-point of this new
  260.    tunnel.
  261.  
  262.  
  263.  
  264. 3. New Packet Formats
  265.  
  266.  
  267. 3.1. Mobility Agent Advertisement Extension
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279. Montenegro             Expires February 10, 1998                [Page 5]
  280.  
  281. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  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      |    Length     |        Sequence Number        |
  288.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  289.    |           Lifetime            |R|B|H|F|M|G|V|T|  reserved     |
  290.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  291.    |                  zero or more Care-of Addresses               |
  292.    |                              ...                              |
  293.  
  294.    The only change to the Mobility Agent Advertisement Extension [1] is
  295.    the additional 'T' bit:
  296.  
  297.       T        Agent offers reverse tunneling service.
  298.  
  299.    A foreign agent that sets the 'T' bit MUST support the two delivery
  300.    styles currently supported: Direct and Encapsulating Delivery Style
  301.    (section 5).
  302.  
  303.    Using this information, a mobile node is able to choose a foreign
  304.    agent that supports reverse tunnels. Notice that if a mobile node
  305.    does not understand this bit, it simply ignores it as per [1].
  306.  
  307.  
  308.  
  309. 3.2. Registration Request
  310.  
  311.    Reverse tunneling support is added directly into the Registration
  312.    Request by using one of the "rsvd" bits.  If a foreign or home agent
  313.    that does not support reverse tunnels receives a request with the
  314.    'T' bit set, the Registration Request fails. This results in a
  315.    registration denial (failure codes are specified in section 3.5).
  316.  
  317.    Most home agents would not object to providing reverse tunnel
  318.    support, because they "SHOULD be able to decapsulate and further
  319.    deliver packets addressed to themselves, sent by a mobile node"
  320.    [1].  In the case of topologically correct reverse tunnels, the
  321.    packets are not sent by the mobile node as distinguished by its home
  322.    address.  Rather, the outermost (encapsulating) IP source address on
  323.    such datagrams is the care-of address of the mobile node.
  324.    Nevertheless, home agents  probably already support the required
  325.    decapsulation and further forwarding.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335. Montenegro             Expires February 10, 1998                [Page 6]
  336.  
  337. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  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      |S|B|D|M|G|V|T|-|          Lifetime             |
  344.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  345.    |                          Home Address                         |
  346.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  347.    |                           Home Agent                          |
  348.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  349.    |                        Care-of Address                        |
  350.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  351.    |                         Identification                        |
  352.    |                                                               |
  353.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.    | Extensions ...
  355.    +-+-+-+-+-+-+-+-
  356.  
  357.    The only change to the Registration Request packet is the additional
  358.    'T' bit:
  359.  
  360.       T        If the 'T' bit is set, the mobile node asks its home
  361.                agent to accept a reverse tunnel from the care-of
  362.                address. Mobile nodes using a foreign agent care-of
  363.                address ask the foreign agent to reverse-tunnel its
  364.                packets.
  365.  
  366.  
  367.  
  368. 3.3. Encapsulating Delivery Style Extension
  369.  
  370.    The Encapsulating Delivery Style Extension MAY be included by the
  371.    mobile node in registration requests to further specify reverse
  372.    tunneling behavior. It is expected to be used only by the foreign
  373.    agent.  Accordingly, the foreign agent MUST consume this extension
  374.    (i.e. it must not relay it to the home agent or include it in
  375.    replies to the mobile node).  As per Section 3.6.1.3 of [1], the
  376.    mobile node MUST include the Encapsulating Delivery Style Extension
  377.    after the Mobile-Home Authentication Extension, and before the
  378.    Mobile-Foreign Authentication Extension, if present.
  379.  
  380.    Encapsulating Extension MUST NOT be included if the 'T' bit is not
  381.    set in the Registration Request.
  382.  
  383.    If this extension is absent, Direct Delivery is assumed.
  384.    Encapsulation is done according to what was negotiated for the
  385.    forward tunnel (i.e., IP in IP is assumed unless specified
  386.    otherwise). For more details on the delivery styles, please refer to
  387.    section 5.
  388.  
  389.  
  390.  
  391. Montenegro             Expires February 10, 1998                [Page 7]
  392.  
  393. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  394.  
  395.  
  396.     0                   1
  397.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  398.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  399.    |     Type      |     Length    |
  400.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  401.  
  402.       Type
  403.  
  404.         128
  405.  
  406.       Length
  407.  
  408.         0
  409.  
  410.  
  411.  
  412. 3.4. Cookie Extensions
  413.  
  414.    In the absence of mobility security associations, Cookie Extensions
  415.    are used by mobile nodes, foreign agents and home agents to provide
  416.    some level of protection against reverse tunnel hijacking and denial
  417.    of service attacks (see Section 6). Cookies are not needed if the
  418.    mobile node operates in co-located mode since the two entities
  419.    involved (mobile node and home agent) MUST have a mobility security
  420.    association in place [1].
  421.  
  422.    The Mobile-Foreign Cookie Extension is used only between the mobile
  423.    node and the foreign agent.  Similarly, use of the Foreign-Home
  424.    Cookie Extension is limited to registration traffic between the
  425.    foreign agent and the home agent.
  426.  
  427.    If a Registration Request with the 'T' bit on includes a Cookie
  428.    Extension, the corresponding successful (code 0) Registration Reply
  429.    MUST include one as well.
  430.  
  431.  
  432.  
  433. 3.4.1 Mobile-Foreign Cookie Extension
  434.  
  435.    Mobile nodes and foreign agents MAY include a Mobile-Foreign Cookie
  436.    Extension in Registration Requests and Replies, subject to the
  437.    conditions detailed in Sections 4.1 and 4.2.
  438.  
  439.    The foreign agent MUST consume this extension (i.e. it MUST NOT
  440.    relay it to the home agent).
  441.  
  442.    If the Mobile-Foreign Cookie Extension is present, as per Sections
  443.    3.6.1.3 and 3.7.3.2 of [1], the mobile node and the foreign agent
  444.  
  445.  
  446.  
  447. Montenegro             Expires February 10, 1998                [Page 8]
  448.  
  449. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  450.  
  451.  
  452.    MUST include it after the Mobile-Home Authentication Extension.
  453.  
  454.    For further details about the processing of this extension, at the
  455.    mobile node and the foreign agent, refer to Sections 4.1 and 4.2,
  456.    respectively.
  457.  
  458.     0                   1                   2                   3
  459.     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
  460.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461.    |     Type      |    Length     |        Reserved               |
  462.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  463.    |                 Current Cookie                                |
  464.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  465.    |                 Previous Cookie                               |
  466.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  467.  
  468.  
  469.       Type
  470.  
  471.         130
  472.  
  473.       Length
  474.  
  475.         10
  476.  
  477.       Reserved
  478.  
  479.         0
  480.  
  481.       Current Cookie
  482.  
  483.         In Registration Requests, it is a value generated randomly by
  484.         the mobile node.
  485.  
  486.         In Registration Replies, the foreign agent sets it to the value
  487.         sent by the mobile node as the "Current Cookie" in the
  488.         corresponding Registration Request.
  489.  
  490.       Previous Cookie
  491.  
  492.         Set to 0 by the foreign agent in Registration Replies.
  493.  
  494.         Set to 0 by the mobile node in initial Registration Requests.
  495.  
  496.         In re-registrations, the mobile node sets this field to the
  497.         "Current Cookie" field of the Mobile-Foreign Cookie Extension
  498.         in the last successful (code 0) Registration Reply.
  499.  
  500.  
  501.  
  502.  
  503. Montenegro             Expires February 10, 1998                [Page 9]
  504.  
  505. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  506.  
  507.  
  508. 3.4.2 Foreign-Home Cookie Extension
  509.  
  510.    Foreign agents and home agents MAY include a Foreign-Home Cookie
  511.    Extension in Registration Requests and Replies, subject to the
  512.    conditions detailed in Sections 4.2 and 4.3.
  513.  
  514.    If the Foreign-Home Cookie Extension is present, as per Sections
  515.    3.7.3.2 and 3.8.3.3 of [1], the foreign agent and the home agent
  516.    MUST include it after the Mobile-Home Authentication Extension.
  517.  
  518.    For further details about the processing of this extension, at the
  519.    foreign agent and the home agent, refer to Sections 4.2 and 4.3,
  520.    respectively.
  521.  
  522.     0                   1                   2                   3
  523.     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
  524.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  525.    |     Type      |    Length     |        Reserved               |
  526.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  527.    |                 Current Cookie                                |
  528.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  529.    |                 Previous Cookie                               |
  530.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  531.  
  532.  
  533.       Type
  534.  
  535.         131
  536.  
  537.       Length
  538.  
  539.         10
  540.  
  541.       Reserved
  542.  
  543.         0
  544.  
  545.       Current Cookie
  546.  
  547.         In Registration Requests, it is a value generated randomly by
  548.         the foreign agent.
  549.  
  550.         In Registration Replies, the home agent sets it to the value
  551.         sent by the foreign agent as the "Current Cookie" field of the
  552.         Foreign-Home Cookie Extension in the corresponding Registration
  553.         Request.
  554.  
  555.       Previous Cookie
  556.  
  557.  
  558.  
  559. Montenegro             Expires February 10, 1998               [Page 10]
  560.  
  561. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  562.  
  563.  
  564.         Set to 0 by the home agent in Registration Replies.
  565.  
  566.         Set to 0 by the foreign node in initial Registration Requests.
  567.  
  568.         In re-registrations, the foreign agent sets this field to the
  569.         "Current Cookie" field of the Foreign-Home Cookie Extension in
  570.         the last Registration Reply.
  571.  
  572.  
  573.  
  574. 3.5. New Registration Reply Codes
  575.  
  576.    Foreign and home agent registration replies MUST convey if the
  577.    reverse tunnel request failed.  These new reply codes are defined:
  578.  
  579.       Service denied by the foreign agent:
  580.  
  581.       74 requested reverse tunnel unavailable
  582.       75 reverse tunnel is mandatory and 'T' bit not set
  583.       76 bad cookie
  584.       77 bad cookie from home agent
  585.       78 mobile node too distant
  586.  
  587.    and
  588.  
  589.       Service denied by the home agent:
  590.  
  591.       137 requested reverse tunnel unavailable
  592.       138 reverse tunnel is mandatory and 'T' bit not set
  593.       139 requested encapsulation unavailable
  594.       140 bad cookie
  595.  
  596.    In response to a Registration Request with the 'T' bit set, mobile
  597.    nodes may receive (and MUST accept) code 70 (poorly formed request)
  598.    from foreign agents and code 134 (poorly formed request) from home
  599.    agents. However, foreign and home agents that support reverse
  600.    tunneling MUST use codes 74 and 137, respectively.
  601.  
  602.    Absence of the 'T' bit in a Registration Request MAY elicit denials
  603.    with codes 75 and 138 at the foreign agent and the home agent,
  604.    respectively.
  605.  
  606.    Forward and reverse tunnels are symmetric, i.e. both are able to use
  607.    the same tunneling options negotiated at registration.  This implies
  608.    that the home agent MUST deny registrations if an unsupported form
  609.    of tunneling is requested (code 139).  Notice that Mobile IP [1]
  610.    already defines the analogous failure code 72 for use by the foreign
  611.    agent.
  612.  
  613.  
  614.  
  615. Montenegro             Expires February 10, 1998               [Page 11]
  616.  
  617. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  618.  
  619.  
  620.    In response to a Registration Request with the 'T' bit set, mobile
  621.    nodes may receive (and MUST accept) codes 76 (bad cookie), 77 (bad
  622.    cookie from home agent) and 78 (mobile node too distant).  from
  623.    foreign agents. Similarly, foreign agents MUST accept code 140 (bad
  624.    cookie) from home agents, and then relay it to mobile nodes.  These
  625.    codes are sent as response to the absence of an expected Cookie
  626.    Extension, or if the values in the fields are unexpected.
  627.  
  628.  
  629.  
  630. 4. Changes in Protocol Behavior
  631.  
  632.    Reverse tunnels must be handled appropriately by the different
  633.    mobility entities. Differences in protocol behavior with respect to
  634.    the Mobile IP specification are specified in the subsequent
  635.    sections.
  636.  
  637.  
  638. 4.1. Mobile Node Considerations
  639.  
  640.    This section describes how the mobile node handles registrations
  641.    that request a reverse tunnel.
  642.  
  643.  
  644.  
  645. 4.1.1. Sending Registration Requests to the Foreign Agent
  646.  
  647.    In addition to the considerations in [1], a mobile node sets the 'T'
  648.    bit in its Registration Request to petition a reverse tunnel.
  649.  
  650.    If registering via a separate foreign agent, it MUST use either one
  651.    of the following:
  652.  
  653.          a. If the mobile node has a security association with the
  654.             foreign agent, it MUST use it as specified in [1].
  655.  
  656.          b. Otherwise, it MUST append a Mobile-Foreign Cookie Extension
  657.             to the Registration Request after the Mobile-Home
  658.             Authentication Extension. The "Current Cookie" field MUST
  659.             be generated randomly by the mobile node using guidelines
  660.             similar to those used in generating nonces.
  661.  
  662.    If using a Mobile-Foreign Cookie Extension, the mobile node MUST set
  663.    the TTL field of the IP header to 255. This is meant to limit a
  664.    denial of service attack introduced by the use of Cookie Extensions
  665.    (Section 6).
  666.  
  667.    The mobile node MAY optionally include an Encapsulating Delivery
  668.  
  669.  
  670.  
  671. Montenegro             Expires February 10, 1998               [Page 12]
  672.  
  673. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  674.  
  675.  
  676.    Style Extension.
  677.  
  678.  
  679.  
  680. 4.1.2. Receiving Registration Replies from the Foreign Agent
  681.  
  682.    If the mobile node included a Mobile-Foreign Cookie Extension in its
  683.    Registration Request, the Registration Reply MUST also include one.
  684.    If it doesn't, the mobile node MUST ignore the reply.  If such an
  685.    extension is present, the mobile node MUST verify that the value of
  686.    the "Current Cookie" field in the reply is equal to that in the
  687.    request. If it isn't, the mobile node MUST ignore this reply.  The
  688.    mobile node SHOULD treat flag either of these two conditions as
  689.    security exceptions.
  690.  
  691.    Possible valid responses are:
  692.  
  693.       - A registration denial issued by either the home agent or the
  694.         foreign agent:
  695.  
  696.          a. The mobile node follows the error checking guidelines in
  697.             [1], and depending on the reply code, MAY try modifying the
  698.             registration request (for example by eliminating the
  699.             request for alternate forms of encapsulation), and issuing
  700.             a new registration.
  701.  
  702.          b. Depending on the reply code, the mobile node MAY try
  703.             zeroing the 'T' bit, eliminating the Encapsulating Delivery
  704.             Style Extension (if one was present), and issuing a new
  705.             registration.
  706.  
  707.          c. The foreign agent returns code 76 ("bad cookie"). If
  708.             reissuing the Registration Request, the mobile node MUST
  709.             set the "Previous Cookie" to the appropriate value. If the
  710.             mobile node ignores this value, it can (a) wait for the
  711.             current binding at the foreign agent to expire, (b) attempt
  712.             registering using another foreign agent.
  713.  
  714.          d. The foreign agent returns codes 77 (bad cookie from home
  715.             agent) or 78 (mobile node too distant). The mobile node MAY
  716.             try issuing a new registration via another foreign agent or
  717.             registering with another home agent. It SHOULD also flag
  718.             this event as a security exception.
  719.  
  720.          e. The foreign agent relays code 140 ("bad cookie") from the
  721.             home agent. The mobile node MAY try issuing a new
  722.             registration via another foreign agent. It SHOULD also flag
  723.             this event as a security exception.
  724.  
  725.  
  726.  
  727. Montenegro             Expires February 10, 1998               [Page 13]
  728.  
  729. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  730.  
  731.  
  732.       - The home agent returns a Registration Reply indicating that the
  733.         service will be provided.
  734.  
  735.    In this last case, the mobile node has succeeded in establishing a
  736.    reverse tunnel between its care-of address and its home agent.  If
  737.    the mobile node is operating with a co-located care-of address, it
  738.    MAY encapsulate outgoing data such that the destination address of
  739.    the outer header is the home agent. This ability to selectively
  740.    reverse-tunnel packets is discussed further in section 5.4.
  741.  
  742.    If the care-of address belongs to a separate foreign agent, the
  743.    mobile node MUST employ whatever delivery style was requested
  744.    (Direct or Encapsulating) and proceed as specified in section 5.
  745.  
  746.    A successful registration reply is an assurance that both the
  747.    foreign agent and the home agent support whatever alternate forms of
  748.    encapsulation (other than IP in IP) were requested. Accordingly, the
  749.    mobile node MAY use them at its discretion.
  750.  
  751.    If a valid Mobile-Foreign Cookie Extension is present in the
  752.    Registration Reply, the mobile node MUST record the value reported
  753.    by the foreign agent in the "Current Cookie" field. This value MUST
  754.    be used to set the "Previous Cookie" field of the Mobile-Foreign
  755.    Cookie Extension in a subsequent re-registration. Failure to do so
  756.    will result in a registration denial. Of course, after the
  757.    registration expires at the foreign agent the mobile node may
  758.    register with a "Previous Cookie" set to 0.
  759.  
  760.    In order to re-register after rebooting, a mobile node MAY choose to
  761.    record a Registration Reply's "Current Cookie" field in non-volatile
  762.    storage. Alternatively, it MAY request a sufficiently short lifetime
  763.    in its registration (e.g. comparable to the time the mobile node
  764.    takes to reboot).
  765.  
  766.  
  767.  
  768. 4.2. Foreign Agent Considerations
  769.  
  770.    This section describes how the foreign agent handles registrations
  771.    that request a reverse tunnel.
  772.  
  773.  
  774.  
  775. 4.2.1. Receiving Registration Requests from the Mobile Node
  776.  
  777.    A foreign agent that receives a Registration Request with the 'T'
  778.    bit set processes the packet as specified in the Mobile IP
  779.    specification [1], and determines whether it can accomodate the
  780.  
  781.  
  782.  
  783. Montenegro             Expires February 10, 1998               [Page 14]
  784.  
  785. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  786.  
  787.  
  788.    forward tunnel request. If it cannot, it returns an appropriate
  789.    code. In particular, if the foreign agent is unable to support the
  790.    requested form of encapsulation it MUST return code 72.
  791.  
  792.    The foreign agent MAY reject Registration Requests without the 'T'
  793.    bit set by denying them with code 75 (reverse tunnel is mandatory
  794.    and 'T' bit not set).
  795.  
  796.    A foreign agent expects a Registration Request with 'T' bit on to be
  797.    secured by either of these:
  798.  
  799.          a. Mobile-Foreign Authentication Extension (preferred), or
  800.  
  801.          b. Mobile-Foreign Cookie Extension.
  802.  
  803.    If neither of the above is present, the foreign agent MUST reject
  804.    the registration with code 76 (bad cookie).
  805.  
  806.    If the Registration Request includes a Mobile-Foreign Extension, the
  807.    foreign agent MUST verify that the TTL field of the IP header is set
  808.    to 255. Otherwise, it MUST reject the registration with code 78
  809.    (mobile node too distant). The foreign agent MUST record the value
  810.    of the "Current Cookie" field. This value MUST match the "Previous
  811.    Cookie" field in subsequent re-registrations issued by the same
  812.    mobile node. A mismatch MUST result in the foreign agent's denying
  813.    the registration with code 76 (bad cookie).
  814.  
  815.    As a last check, the foreign agent verifies that it can support a
  816.    reverse tunnel with the same configuration. If it cannot, it MUST
  817.    return a Registration Reply denying the request with code 74
  818.    (requested reverse tunnel unavailable).
  819.  
  820.  
  821.  
  822. 4.2.2. Relaying Registration Requests to the Home Agent
  823.  
  824.    Otherwise, the foreign agent MUST relay the Registration Request to
  825.    the home agent. The foreign agent MUST use either of these:
  826.  
  827.          a. Foreign-Home Authentication Extension (preferred), or
  828.  
  829.          b. Foreign-Home Cookie Extension.
  830.  
  831.    If the foreign agent receives a denial with code 140 (bad cookie)
  832.    from the home agent, it MUST relay it to the mobile node.
  833.  
  834.    If the foreign agent included a Foreign-Home Cookie Extension when
  835.    it relayed the Registration Request, the Registration Reply MUST
  836.  
  837.  
  838.  
  839. Montenegro             Expires February 10, 1998               [Page 15]
  840.  
  841. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  842.  
  843.  
  844.    also include one.  If it doesn't, the foreign agent MUST send a
  845.    denial to the mobile node with code 77 (bad cookie from home
  846.    agent).  If such an extension is present, the foreign agent MUST
  847.    verify that the value of the "Current Cookie" field in the reply is
  848.    equal to that in the request. If it isn't, the foreign agent MUST
  849.    send a denial to the mobile node with code 77 (bad cookie from home
  850.    agent).  The foreign agent SHOULD flag either of these two
  851.    conditions as security exceptions.
  852.  
  853.    If the reply includes a Foreign-Home Authentication Extension, the
  854.    foreign agent MUST record the value of the "Current Cookie" field.
  855.    This value must be used to set the "Previous Cookie" field when
  856.    relaying a subsequent re-registration from the same mobile node.
  857.  
  858.    Upon receipt of a Registration Reply that satisfies validity checks,
  859.    the foreign agent MUST update its visitor list, including indication
  860.    that this mobile node has been granted a reverse tunnel and the
  861.    delivery style expected (section 5).
  862.  
  863.    The foreign agent MUST then relay the Registration Reply to the
  864.    mobile node, including either a Mobile-Foreign Authentication
  865.    Extension or Mobile-Foreign Cookie Extension, whichever was present
  866.    in the corresponding Registration Request. In the latter case, the
  867.    value of the "Current Cookie" MUST be equal to that in the same
  868.    field of the corresponding request.
  869.  
  870.    While this visitor list entry is in effect, the foreign agent MUST
  871.    process incoming traffic according to the delivery style,
  872.    encapsulate it and tunnel it from the care-of address to the home
  873.    agent's address.
  874.  
  875.  
  876.  
  877. 4.3. Home Agent Considerations
  878.  
  879.    This section describes how the home agent handles registrations that
  880.    request a reverse tunnel.
  881.  
  882.  
  883.  
  884. 4.3.1. Receiving Registration Requests from the Foreign Agent
  885.  
  886.    A home agent that receives a Registration Request with the 'T' bit
  887.    set processes the packet as specified in the Mobile IP specification
  888.    [1] and determines whether it can accomodate the forward tunnel
  889.    request.  If it cannot, it returns an appropriate code. In
  890.    particular, if the home agent is unable to support the requested
  891.    form of encapsulation it MUST return code 139.
  892.  
  893.  
  894.  
  895. Montenegro             Expires February 10, 1998               [Page 16]
  896.  
  897. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  898.  
  899.  
  900.    The home agent MAY reject registration requests without the 'T' bit
  901.    set by denying them with code 138 (reverse tunnel is mandatory and
  902.    'T' bit not set).
  903.  
  904.    A home agent expects a Registration Request with 'T' bit on to be
  905.    secured by either of these:
  906.  
  907.          a. Foreign-Home Authentication Extension (preferred), or
  908.  
  909.          b. Foreign-Home Cookie Extension.
  910.  
  911.    If neither of the above is present, the home agent MUST reject the
  912.    registration with code 140 (bad cookie).
  913.  
  914.    If the Registration Request includes a Foreign-Home Extension, the
  915.    home agent MUST record the value of the "Current Cookie" field. This
  916.    value MUST match the "Previous Cookie" field in subsequent
  917.    re-registrations relayed by the foreign agent on behalf of the same
  918.    mobile node. A mismatch MUST result in the home agent's denying the
  919.    registration with code 140 (bad cookie).
  920.  
  921.    As a last check, the home agent determines whether it can support a
  922.    reverse tunnel with the same configuration as the forward tunnel. If
  923.    it cannot, it MUST send back a registration denial with code 137.
  924.  
  925.    Upon receipt of a Registration Reply that satisfies validity checks,
  926.    the home agent MUST update its mobility bindings list to indicate
  927.    that this mobile node has been granted a reverse tunnel and the type
  928.    of encapsulation expected.
  929.  
  930.  
  931.  
  932. 4.3.2. Sending Registration Replies to the Foreign Agent
  933.  
  934.    In response to a valid Registration Request, a home agent MUST issue
  935.    a Registration Reply to the mobile node, including either a
  936.    Foreign-Home Authentication Extension or a Foreign-Home Cookie
  937.    Extension, whichever was present in the corresponding Registration
  938.    Request. In the latter case, the value of the "Current Cookie" MUST
  939.    be equal to that in the same field of the corresponding request.
  940.  
  941.    After a successful registration, the home agent may receive
  942.    encapsulated packets addressed to it. For each such packet it MAY
  943.    search for a mobility binding whose care-of address is the source of
  944.    the outer header, and whose mobile node address is the source of the
  945.    inner header. If no such binding is found, or if the packet uses an
  946.    encapsulation mechanism that was not negotiated at registration the
  947.    home agent MUST silently discard the packet and SHOULD log the event
  948.  
  949.  
  950.  
  951. Montenegro             Expires February 10, 1998               [Page 17]
  952.  
  953. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  954.  
  955.  
  956.    as a security exception.
  957.  
  958.    While the registration is in effect, a home agent MUST process each
  959.    valid reverse tunneled packet (as determined by checks like the
  960.    above) by decapsulating it, recovering the original packet, and then
  961.    forwarding it on behalf of its sender (the mobile node) to the
  962.    destination address (the correspondent host).
  963.  
  964.  
  965.  
  966. 5. Mobile Node to Foreign Agent Delivery Styles
  967.  
  968.    This section specifies how the mobile node sends its data traffic
  969.    via the foreign agent. In all cases, the mobile node learns the
  970.    foreign agent's link-layer address from the link-layer header in the
  971.    agent advertisement.
  972.  
  973.  
  974. 5.1. Direct Delivery Style
  975.  
  976.    This delivery mechanism is very simple to implement at the mobile
  977.    node, and uses small (non-encapsulated) packets on the link between
  978.    the mobile node and the foreign agent (potentially a very slow
  979.    link).  However, it only supports reverse-tunneling of unicast
  980.    packets, and does not allow selective reverse tunneling (section
  981.    5.4).
  982.  
  983.  
  984. 5.1.1. Packet Processing
  985.  
  986.    The mobile node MUST designate the foreign agent as its default
  987.    router. Not doing so will not guarantee encapsulation of all the
  988.    mobile node's outgoing traffic, and defeats the purpose of the
  989.    reverse tunnel. The foreign agent MUST:
  990.  
  991.       - detect packets sent by the mobile node, and
  992.  
  993.       - modify its forwarding function to encapsulate them before
  994.         forwarding.
  995.  
  996.  
  997. 5.1.2. Packet Header Format and Fields
  998.  
  999.    This section shows the format of the packet headers used by the
  1000.    Direct Delivery style. The formats shown assume IP in IP
  1001.    encapsulation [2].
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007. Montenegro             Expires February 10, 1998               [Page 18]
  1008.  
  1009. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1010.  
  1011.  
  1012.    Packet format received by the foreign agent (Direct Delivery
  1013.    Style):
  1014.  
  1015.        IP fields:
  1016.          Source Address = mobile node's home address
  1017.          Destination Address = correspondent host's address
  1018.        Upper Layer Protocol
  1019.  
  1020.    Packet format forwarded by the foreign agent (Direct Delivery
  1021.    Style):
  1022.  
  1023.        IP fields (encapsulating header):
  1024.          Source Address = foreign agent's care-of address
  1025.          Destination Address = home agent's address
  1026.          Protocol field: 4 (IP in IP)
  1027.        IP fields (original header):
  1028.          Source Address = mobile node's home address
  1029.          Destination Address = correspondent host's address
  1030.        Upper Layer Protocol
  1031.  
  1032.    These fields of the encapsulating header MUST be chosen as follows:
  1033.  
  1034.       IP Source Address
  1035.  
  1036.          Copied from the Care-of Address field within the Registration
  1037.          Request.
  1038.  
  1039.       IP Destination Address
  1040.  
  1041.          Copied from the Home Agent field within the Registration
  1042.          Request.
  1043.  
  1044.       IP Protocol Field
  1045.  
  1046.          Default is 4 (IP in IP [2]), but other methods of
  1047.          encapsulation MAY be used as negotiated at registration time.
  1048.  
  1049.  
  1050. 5.2. Encapsulating Delivery Style
  1051.  
  1052.    This mechanism requires that the mobile node implement
  1053.    encapsulation, and explicitly directs packets at the foreign agent
  1054.    by designating it as the destination address in a new outermost
  1055.    header.  Mobile nodes that wish to send either broadcast or
  1056.    multicast packets MUST use the Encapsulating Delivery Style.
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063. Montenegro             Expires February 10, 1998               [Page 19]
  1064.  
  1065. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1066.  
  1067.  
  1068. 5.2.1 Packet Processing
  1069.  
  1070.    The foreign agent does not modify its forwarding function.
  1071.    Rather, it receives an encapsulated packet and after verifying that
  1072.    it was sent by the mobile node, it:
  1073.  
  1074.       - decapsulates to recover the inner packet,
  1075.  
  1076.       - re-encapsulates, and sends it to the home agent.
  1077.  
  1078.    If a foreign agent receives an un-encapsulated packet from a mobile
  1079.    node which had explicitly requested the Encapsulated Delivery Style,
  1080.    then the foreign agent MUST NOT reverse tunnel such a packet and
  1081.    rather MUST forward it using standard, IP routing mechanisms.
  1082.  
  1083.  
  1084. 5.2.2. Packet Header Format and Fields
  1085.  
  1086.    This section shows the format of the packet headers used by the
  1087.    Encapsulating Delivery style. The formats shown assume IP in IP
  1088.    encapsulation [2].
  1089.  
  1090.    Packet format received by the foreign agent (Encapsulating Delivery
  1091.    Style):
  1092.  
  1093.        IP fields (encapsulating header):
  1094.          Source Address = mobile node's home address
  1095.          Destination Address = foreign agent's address
  1096.          Protocol field: 4 (IP in IP)
  1097.        IP fields (original header):
  1098.          Source Address = mobile node's home address
  1099.          Destination Address = correspondent host's address
  1100.        Upper Layer Protocol
  1101.  
  1102.  
  1103.    The fields of the encapsulating IP header MUST be chosen as
  1104.    follows:
  1105.  
  1106.       IP Source Address
  1107.  
  1108.          The mobile node's home address.
  1109.  
  1110.       IP Destination Address
  1111.  
  1112.          The address of the agent as learned from the IP source address
  1113.          of the agent's most recent registration reply.
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119. Montenegro             Expires February 10, 1998               [Page 20]
  1120.  
  1121. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1122.  
  1123.  
  1124.       IP Protocol Field
  1125.  
  1126.          Default is 4 (IP in IP [2]), but other methods of
  1127.          encapsulation MAY be used as negotiated at registration time.
  1128.  
  1129.  
  1130.    Packet format forwarded by the foreign agent (Encapsulating Delivery
  1131.    Style):
  1132.  
  1133.        IP fields (encapsulating header):
  1134.          Source Address = foreign agent's care-of address
  1135.          Destination Address = home agent's address
  1136.          Protocol field: 4 (IP in IP)
  1137.        IP fields (original header):
  1138.          Source Address = mobile node's home address
  1139.          Destination Address = correspondent host's address
  1140.        Upper Layer Protocol
  1141.  
  1142.    These fields of the encapsulating IP header MUST be chosen as
  1143.    follows:
  1144.  
  1145.       IP Source Address
  1146.  
  1147.          Copied from the Care-of Address field within the Registration
  1148.          Request.
  1149.  
  1150.       IP Destination Address
  1151.  
  1152.          Copied from the Home Agent field within the Registration
  1153.          Request.
  1154.  
  1155.       IP Protocol Field
  1156.  
  1157.          Default is 4 (IP in IP [2]), but other methods of
  1158.          encapsulation MAY be used as negotiated at registration time.
  1159.  
  1160.  
  1161. 5.3. Support for Broadcast and Multicast Datagrams
  1162.  
  1163.    If a mobile node is operating with a co-located care-of address,
  1164.    broadcast and multicast datagrams are handled according to Sections
  1165.    4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a
  1166.    foreign agent care-of address MAY have their broadcast and multicast
  1167.    datagrams reverse-tunneled by the foreign agent.  However, any
  1168.    mobile nodes doing so MUST use the encapsulating delivery style.
  1169.  
  1170.    This delivers the datagram only to the foreign agent.  The latter
  1171.    decapsulates it and then processes it as any other packet from the
  1172.  
  1173.  
  1174.  
  1175. Montenegro             Expires February 10, 1998               [Page 21]
  1176.  
  1177. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1178.  
  1179.  
  1180.    mobile node, namely, by reverse tunneling it to the home agent.
  1181.  
  1182.  
  1183. 5.4. Selective Reverse Tunneling
  1184.  
  1185.    Packets destined to local resources (e.g. a nearby printer) might be
  1186.    unaffected by ingress filtering. A mobile node with a co-located
  1187.    care-of address MAY optimize delivery of these packets by not
  1188.    reverse tunneling them.  On the other hand, a mobile node using a
  1189.    foreign agent care-of address MAY use this selective reverse
  1190.    tunneling capability by requesting the Encapsulating Delivery Style,
  1191.    and following these guidelines:
  1192.  
  1193.       Packets NOT meant to be reversed tunneled:
  1194.  
  1195.          Sent using the Direct Delivery style. The foreign agent
  1196.          MUST process these packets as regular traffic:  they MAY be
  1197.          forwarded but MUST NOT be reverse tunneled to the home agent.
  1198.  
  1199.       Packets meant to be reverse tunneled:
  1200.  
  1201.          Sent using the Encapsulating Delivery style. The foreign agent
  1202.          MUST process these packets as specified in section 5.2: they
  1203.          MUST be reverse tunneled to the home agent.
  1204.  
  1205.  
  1206.  
  1207. 6. Security Considerations
  1208.  
  1209.    The extensions outlined in this document are subject to the security
  1210.    considerations outlined in the Mobile IP specification [1].
  1211.    Essentialy, creation of both forward and reverse tunnels involves an
  1212.    authentication procedure, which reduces the risk for attack.
  1213.  
  1214.  
  1215.  
  1216. 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks
  1217.  
  1218.    Once the tunnel is set up, a malicious node could hijack it to
  1219.    inject packets into the network. Reverse tunnels might exacerbate
  1220.    this problem, because upon reaching the tunnel exit point packets
  1221.    are forwarded beyond the local network. This concern is also present
  1222.    in the Mobile IP specification, as it already dictates the use of
  1223.    reverse tunnels for certain applications.
  1224.  
  1225.    Unauthenticated exchanges involving the foreign agent allow a
  1226.    malicious node to pose as a valid mobile node and re-direct an
  1227.    existing reverse tunnel to another home agent, perhaps another
  1228.  
  1229.  
  1230.  
  1231. Montenegro             Expires February 10, 1998               [Page 22]
  1232.  
  1233. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1234.  
  1235.  
  1236.    malicious node. The best way to protect against these attacks is by
  1237.    employing the Mobile-Foreign and Foreign-Home Authentication
  1238.    Extensions defined in [1]. If the necessary mobility security
  1239.    associations are not available, Cookie Extensions (Section 3.4) MUST
  1240.    be used to protect against off-the-path attacks.
  1241.  
  1242.    The Mobile-Foreign Cookie Extension enables a foreign agent to
  1243.    distinguish between a mobile node for which it has a current visitor
  1244.    list entry and an off-the-path attacker. The Foreign-Home Cookie
  1245.    Extension enables a foreign agent to distinguish between the home
  1246.    agent for a mobile node currently in a visitor list entry and an
  1247.    off-the-path attacker.
  1248.  
  1249.    However, cookies are unauthenticated state, and as such, may be used
  1250.    to launch denial-of-service attacks. For example, a malicious node
  1251.    may register via a foreign agent using another malicious node as its
  1252.    home agent. The existence of this visitor list entry at the foreign
  1253.    agent effectively blocks the real mobile node from registering.  As
  1254.    a consequence, the mobile node SHOULD cache the cookies in permanent
  1255.    storage, otherwise it will be unable to register in the event of a
  1256.    reboot as long as it has a valid visitor list entry at the foreign
  1257.    agent. Alternatively, the mobile node MAY request appropriately
  1258.    short lifetimes in its Registration Requests.
  1259.  
  1260.    This document also introduces other mechanisms to reduce the range
  1261.    and effectiveness of the attacks. Requiring a TTL value of 255 in
  1262.    the IP headers of Registration Requests received at the foreign
  1263.    agent prevents malicious nodes more than one hop away from posing as
  1264.    valid mobile nodes. Additional codes for use in registration denials
  1265.    make those attacks that do occur easier to track.
  1266.  
  1267.  
  1268.  
  1269. 6.2. Ingress Filtering
  1270.  
  1271.    There has been some concern regarding the long-term effectiveness of
  1272.    reverse-tunneling in the presence of ingress filtering. The
  1273.    conjecture is that network administrators will target
  1274.    reverse-tunneled packets (IP in IP encapsulated packets) for
  1275.    filtering. The ingress filtering recommendation spells out why this
  1276.    is not the case [8]:
  1277.  
  1278.       Tracking the source of an attack is simplified when the source is
  1279.       more likely to be "valid."
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287. Montenegro             Expires February 10, 1998               [Page 23]
  1288.  
  1289. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1290.  
  1291.  
  1292. 7. Acknowledgements
  1293.  
  1294.    The encapsulating style of delivery was proposed by Charlie
  1295.    Perkins.  Jim Solomon has been instrumental in shaping this document
  1296.    into its present form.
  1297.  
  1298.  
  1299. References
  1300.  
  1301.     [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996.
  1302.  
  1303.     [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October
  1304.         1996.
  1305.  
  1306.     [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
  1307.         and Hijacked Terminal Connections", CA-95:01, January 1995.
  1308.         Available via anonymous ftp from info.cert.org in
  1309.         /pub/cert_advisories.
  1310.  
  1311.     [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP --
  1312.         work in progress, draft-ietf-mobileip-optim-06.txt, July 1997.
  1313.  
  1314.     [5] Manuel Rodriguez, private communication, August 1995.
  1315.  
  1316.     [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
  1317.  
  1318.     [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
  1319.         August 1995.
  1320.  
  1321.     [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending
  1322.         Against IP Source Address Spoofing -- work in progress,
  1323.         draft-ferguson-ingress-filtering-02.txt, July 1997.
  1324.  
  1325.  
  1326. Editor and Chair Addresses
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343. Montenegro             Expires February 10, 1998               [Page 24]
  1344.  
  1345. INTERNET DRAFT      Reverse Tunneling for Mobile IP          August 1997
  1346.  
  1347.  
  1348.  
  1349.    Questions about this document may be directed at:
  1350.  
  1351.           Gabriel E. Montenegro
  1352.           Sun Microsystems, Inc.
  1353.           an Antonio Road
  1354.           Mailstop UMPK 15-214
  1355.           Mountain View, California 94303
  1356.  
  1357.           Voice:  +1-415-786-6288
  1358.           Fax:    +1-415-786-6445
  1359.  
  1360.           E-Mail: gabriel.montenegro@eng.sun.com
  1361.  
  1362.  
  1363.  
  1364.    The working group can be contacted via the current chairs:
  1365.  
  1366.           Jim Solomon
  1367.           Motorola, Inc.
  1368.           1301 E. Algonquin Rd. - Rm 2240
  1369.           Schaumburg, IL  60196
  1370.  
  1371.           Voice:  +1-847-576-2753
  1372.           Fax:    +1-847-576-3240
  1373.           E-Mail: solomon@comm.mot.com
  1374.  
  1375.  
  1376.           Erik Nordmark
  1377.           Sun Microsystems, Inc.
  1378.           901 San Antonio Road
  1379.           Mailstop UMPK17-202
  1380.           Mountain View, California 94303
  1381.  
  1382.           Voice:  +1-415-786-5166
  1383.           E-Mail: erik.nordmark@eng.sun.com
  1384.  
  1385.  
  1386.  
  1387.  
  1388.  
  1389.  
  1390.  
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399. Montenegro             Expires February 10, 1998               [Page 25]
  1400.