rfc1620.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,067 行 · 第 1/3 页

           | AR Sa |   | AR Sb |    | AR Sc |   | AR Sd |
           |_______|   |_______|    |_______|   |_______|


            Figure 3.  Single-Cloud Shared Medium


      Figure 3 suggests that each of the hosts Ha, ... Hd is associated
      with a corresponding AR Server "AR Sa", ..."AR Sd".

      This same scheme could be applied to the LIS model of Figure 2.
      The AR Servers would be implemented in the routers, and if the
      medium supports broadcast then the hosts would be configured for
      proxy ARP.  That is, the host would be told that all destinations



Braden, Postel & Rekhter                                       [Page 13]

RFC 1620              Shared Media IP Architecture              May 1994


      are local, so it will always issue an ARP request for the final
      destination.  The set of AR Servers would resolve this request.

      Since routing loops are a constant possibility, Heinanen's
      proposal includes the addition of a hop count to ARP requests and
      replies.

      Like all proxy ARP schemes, this one has a seductive simplicity.
      However, solving the SM problem at the LL has several costs.  It
      requires a complete round-trip time before the first datagram can
      flow.  It requires a hop count in the ARP packet.  This seems like
      a tip-off that the link layer may not be the most appropriate
      place to solve the SM problem.

   4.4  Routing Query Messages

      This scheme [Halpern93] introduces a new IP level mechanism: SM
      routing query and reply messages.  These messages are forwarded as
      IP datagrams hop-by-hop in the direction of the destination
      address.  The exit router can return a reply, again hop-by-hop,
      that finally reaches the source host as an XRedirect.  It would
      also be possible (but not necessary) to modify hosts to initiate
      these queries.

      The query/reply pair is supplying the same information that we
      would add to routing protocols under Extended Routing.  However,
      the Query/Reply messages would allow us to keep the current
      routing protocols unchanged, and would also provide the extra
      information only for the routes that are actually needed, thus
      reducing the routing overhead.  Note that the Query/Reply sequence
      can happen in parallel with forwarding the initial datagram hop-
      by-hop, so it does not add an extra round-trip delay.

   4.5  Stale Routing Information

      We must consider what happens when the network topology changes.
      The technique of extended routing (Section 4.2) is capable of
      providing sufficient assurances that stale information will be
      purged from the system within the convergence time associated with
      a particular routing protocol being used.

      However, the three other techniques (hop-by-hop redirection,
      extended Proxy ARP, and routing query messages) may be expected to
      provide minimal-hop forwarding only as long as the network
      topology remains unchanged since the time such information was
      acquired.  Changes in the topology may result in a change in the
      minimal-hop path, so that the first-hop router may no longer be
      the correct choice.  If the host that is using this first-hop



Braden, Postel & Rekhter                                       [Page 14]

RFC 1620              Shared Media IP Architecture              May 1994


      router is not aware of the changes, then instead of a minimal-hop
      path the host could be using a path that is now suboptimal,
      perhaps highly sub-optimal, with respect to the number of hops.

      Futhermore, use of the information acquired via either extended
      Proxy ARP or routing query messages to optimize routing between
      routers attached to the same SM is highly problematic, because
      presence of stale information on routers could result in
      forwarding loops that might persist as long as the information
      isn't purged; neither approach provides suitable handling of stale
      information.

   4.6  Implications of Filtering (Firewalls)

      For a variety of reasons an administrator of a LIS may erect IP
      Layer firewalls (perform IP-layer filtering) to constrain LL
      connectivity between the hosts/routers within the LIS and
      hosts/routers in other LISs within the same SM.  To avoid
      disruption in forwarding, the mechanisms described in this
      document need to take into account such firewalls.

      Using [X]Redirects requires a router that generates an [X]Redirect
      to be cognizant of possible Link Layer connectivity constraints
      between the router that is specified as the Next Hop in the
      Redirect and the host that is the target of the Redirect.

      Using extended routing requires a router that originates and/or
      propagates "third-party" information be cognizant of the possible
      Link Layer connectivity constraints. Specifically, a router should
      not propagate "third-party" information when there is a lack of
      Link Layer connectivity between the router depicted by the
      information and the router which is the immediate recipient of
      that information.

      Using extended proxy ARP requires an ARP Server not to propagate
      an ARP Request to another ARP server if there are Link Layer
      connectivity constraints between the originator of the ARP Request
      and the other ARP server.

      Using SM routing query and reply messages requires the routers
      that pass the messages to be aware of the possible Link Layer
      connectivity constraints.  The flow of messages need to reflect
      these constraints.








Braden, Postel & Rekhter                                       [Page 15]

RFC 1620              Shared Media IP Architecture              May 1994


5. SECURITY CONSIDERATIONS

   We should discuss the security issues raised by our suggested
   changes.  We should note that we are not talking about "real"
   security here; real Internet security will require cryptographic
   techniques on an end-to-end basis.  However, it should not be easy to
   subvert the basic delivery mechanism of IP to cause datagrams to flow
   to unexpected places.

   With this understanding, the security problems arise in two places:
   the ICMP Redirect messages and the ARP replies.

   *    ICMP Redirect Security

        We may reasonably require that the routers be secure.  They are
        generally under centralized administrative control, and we may
        assume that the routing protocols will contain sufficient
        authentication mechanisms (even if it is not currently true).
        Therefore, a host will reasonably be able to trust a Redirect
        that comes from a router.

        However, it will NOT be reasonable for a host to trust another
        host.  Suppose that the target host in the examples of Section
        4.1 is untrustworthy; there is no way to prevent its issuing a
        new Redirect to some other destination, anywhere in the
        Internet.  On the other hand, this exposure is no worse than it
        was; the target host, once subverted, could always act as a
        hidden router to forward traffic elsewhere.

   *    ARP Security

        Currently, an ARP Reply can come only from the local network,
        and a physically isolated network can be administrative secured
        from subversion of ARP.  However, an ARP Reply can come from
        anywhere within the SM, and an evil-doer can use this fact to
        divert the traffic flow from any host within the SM
        [Bellovin89].

        The XRedirect closes this security hole.  Validating the
        XRedirect (as coming from the node to which the last datagram
        was sent) will also validate the LL address.

        Another approach is to validate the source address from which
        the ARP Reply was received (assuming the link layer protocol
        carries the source address and the driver supplies it).  An
        acceptable ARP reply for destination IP address D can only come
        from LL address x, where the routing cache maps D -> E and the
        ARP cache gives x as the translation of E.  This validation,



Braden, Postel & Rekhter                                       [Page 16]

RFC 1620              Shared Media IP Architecture              May 1994


        involving both routing and ARP caches, might be ugly to
        implement in a strictly-layered implementation.  It would be
        natural if layering were already violated by combining the ARP
        cache and routing cache.

   It is possible for the link layer to have security mechanisms that
   could interfere with IP-layer connectivity.  In particular, there
   could possible be non-transitivity of logical interconnection within
   a shared medium.  In particular, some large public data networks may
   include configuration options that could allow Net A to talk to Net B
   and Net B to talk to Net C, but prevent A from talking directly to C.
   In this case, the routing protocols have to be sophisticated enough
   to handle such anomalies.

6. CONCLUSIONS

   We have discussed four possible extensions to the Internet
   architecture to allow hop-efficient forwarding of IP datagrams within
   shared media, when this optimization is allowed by IP-layer
   firewalls.  We do not draw any conclusions in this paper about the
   best mechanisms.

   Our suggested extensions are evolutionary, leaving intact the basic
   ideas of the current Internet architecture.  It would be possible to
   make (and some have suggested) much more radical changes to
   accommodate shared media.  In the extreme, one could entirely abolish
   the inner clouds in Figure 2, so that there would be no logical
   network structure within the SM.  The IP addresses would then be
   logical, and some mechanism of distributed servers would be needed to
   find routes within this random haze.  We think this approach ignores
   all the requirements for management and security in today's Internet.
   It might make a good research paper, but it would not be good
   Internet design strategy.

7. ACKNOWLEDGMENTS

   We are grateful to Keith McGloghrie, Joel Halpern, and others who
   rubbed our noses in this problem.  We also acknowledge Tony Li
   (cisco), Greg Minshall (Novell), and John Garrett (AT&T) for their
   review and constructive comments.  We are also grateful to Gerri
   Gilliland who supplied the paper tablecloth, colored crayons, and
   fine food that allowed these ideas to be assembled initially.









Braden, Postel & Rekhter                                       [Page 17]

RFC 1620              Shared Media IP Architecture              May 1994


8. REFERENCES


 [Bellovin89]  Bellovin, S., "Security Problems in the TCP/IP Protocol
     Suite", ACM CCR, v. 19. no. 2, April 1989.

 [Garrett93]  Garrett, J., Hagan, J. and J. Wong, "Directed ARP", RFC
     1433, AT&T Bell Laboratories, University of Pennsylvania, March
     1993.

 [Plummer82]  Plummer, D., "An Ethernet Address Resolution Protocol",
     STD 37, RFC 826, MIT, November 1982.

 [Halpern93]  Halpern, J., Private Communication, July 1993.

 [Heinanen93]  Heinanen, J., "NBMA Address Resolution Protocol (NBMA
     ARP)", Work in Progress, June 1993.

 [Laubach93]  Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
     Hewlett-Packard Laboratories, January 1994.

 [Postel81a]  Postel, J., "Internet Protocol - DARPA Internet Program
     Protocol Specification", STD 5, RFC 791, DARPA, September 1981.

 [Postel81b]  Postel, J., "Internet Control Message Protocol- DARPA
     Internet Program Protocol Specification", STD 5, RFC 792, ISI,
     September 1981.

 [PSC81]  Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet
     Protocol", Computer Networks 5, pp. 261-271, 1983.

 [RFC-1122]  Braden, R., Editor, "Requirements for Internet Hosts --
     Communication Layers", STD 3, RFC 1122, USC/Information Sciences
     Institutue, October 1989.

















Braden, Postel & Rekhter                                       [Page 18]

RFC 1620              Shared Media IP Architecture              May 1994


Authors' Addresses

     Bob Braden
     Information Sciences Institute
     University of Southern California
     4676 Admiralty Way
     Marina del Rey, CA 90292

     Phone: [phone]
     EMail: [e-mail]


     Jon Postel
     Information Sciences Institute
     University of Southern California
     4676 Admiralty Way
     Marina del Rey, CA 90292

     Phone: [phone]
     EMail: [e-mail]


     Yakov Rekhter
     Office 32-017
     T.J. Watson Research Center, IBM Corp.
     P.O. Box 218,
     Yorktown Heights, NY 10598

     Phone: [phone]
     EMail: [e-mail]




















Braden, Postel & Rekhter                                       [Page 19]