home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1675.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  8.1 KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        S. Bellovin
  8. Request for Comments: 1675                        AT&T Bell Laboratories
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.                        Security Concerns for IPng
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27. Overview and Rationale
  28.  
  29.    A number of the candidates for IPng have some features that are
  30.    somewhat worrisome from a security perspective.  While it is not
  31.    necessary that IPng be an improvement over IPv4, it is mandatory that
  32.    it not make things worse.  Below, I outline a number of areas of
  33.    concern.  In some cases, there are features that would have a
  34.    negative impact on security if nothing else is done.  It may be
  35.    desirable to adopt the features anyway, but in that case, the
  36.    corrective action is mandatory.
  37.  
  38. Firewalls
  39.  
  40.    For better or worse, firewalls are very much a feature of today's
  41.    Internet.  They are not, primarily, a response to network protocol
  42.    security problems per se.  Rather, they are a means to compensate for
  43.    failings in software engineering and system administration.  As such,
  44.    firewalls are not likely to go away any time soon; IPng will do
  45.    nothing to make host programs any less buggy.  Anything that makes
  46.    firewalls harder to deploy will make IPng less acceptable in the
  47.    market.
  48.  
  49.    Firewalls impose a number of requirements.  First, there must be a
  50.    hierarchical address space.  Many address-based filters use the
  51.    structure of IPv4 addresses for access control decisions.
  52.    Fortunately, this is a requirement for scalable routing as well.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Bellovin                                                        [Page 1]
  59.  
  60. RFC 1675               Security Concerns for IPng            August 1994
  61.  
  62.  
  63.    Routers, though, only need access to the destination address of the
  64.    packet.  Network-level firewalls often need to check both the source
  65.    and destination address.  A structure that makes it harder to find
  66.    the source address is a distinct negative.
  67.  
  68.    There is also a need for access to the transport-level (i.e., the TCP
  69.    or UDP) header.  This may be for the port number field, or for access
  70.    to various flag bits, notably the ACK bit in the TCP header.  This
  71.    latter field is used to distinguish between incoming and outgoing
  72.    calls.
  73.  
  74.    In a different vein, at least one of the possible transition plans
  75.    uses network-level packet translators [1].  Organizations that use
  76.    firewalls will need to deploy their own translators to aid in
  77.    converting their own internal networks.  They cannot rely on
  78.    centrally-located translators intended to serve the entire Internet
  79.    community.  It is thus vital that translators be simple, portable to
  80.    many common platforms, and cheap -- we do not want to impose too high
  81.    a financial barrier for converts to IPng.
  82.  
  83.    By the same token, it is desirable that such translation boxes not be
  84.    usable for network-layer connection-laundering.  It is difficult
  85.    enough to trace back attacks today; we should not make it harder.
  86.    (Some brands of terminal servers can be used for laundering.  Most
  87.    sites with such boxes have learned to configure them so that such
  88.    activities are impossible.)  Comprehensive logging is a possible
  89.    alternative.
  90.  
  91.    IPAE [1] does not have problems with its translation strategy, as
  92.    address are (insofar as possible) preserved; it is necessary to avoid
  93.    any alternative strategies, such as circuit-level translators, that
  94.    might.
  95.  
  96. Encryption and Authentication
  97.  
  98.    A number of people are starting to experiment with IP-level
  99.    encryption and cryptographic authentication.  This trend will (and
  100.    should) continue.  IPng should not make this harder, either
  101.    intrinsically or by imposing a substantial perforance barrier.
  102.  
  103.    Encryption can be done with various different granularities: host to
  104.    host, host to gateway, and gateway to gateway.  All of these have
  105.    their uses; IPng must not rule out any of them.  Encapsulation and
  106.    tunneling strategies are somewhat problematic, as the packet may no
  107.    longer carry the original source address when it reaches an
  108.    encrypting gateway.  (This may be seen more as a constraint on
  109.    network topologies.  So be it, but we should warn people of the
  110.    limitation.)
  111.  
  112.  
  113.  
  114. Bellovin                                                        [Page 2]
  115.  
  116. RFC 1675               Security Concerns for IPng            August 1994
  117.  
  118.  
  119.    Dual-stack approaches, such as in TUBA's transition plan [2], imply
  120.    multiple addresses for each host.  (IPAE has this feature, too.) The
  121.    encryption and access control infrastructure needs to know about all
  122.    addresses for a given host, belonging to whichever stack.  It should
  123.    not be possible to bypass authentication or encryption by asking for
  124.    a different address for the same host.
  125.  
  126. Source Routing and Address-based Authentication
  127.  
  128.    The dominant form of host authentication in today's Internet is
  129.    address-based.  That is, hosts often decide to trust other hosts
  130.    based on their IP addresses.  (Actually, it's worse than that; much
  131.    authentication is name-based, which opens up new avenues of attack.
  132.    But if an attacker can spoof an IP address, there's no need to attack
  133.    the name service.)  To the extent that it does work, address-based
  134.    authentication relies on the implied accuracy of the return route.
  135.    That is, though it is easy to inject packets with a false source
  136.    address, replies will generally follow the usual routing patterns,
  137.    and be sent to the real host with that address.  This frustrates
  138.    most, though not all, attempts at impersonation.
  139.  
  140.    Problems can arise if source-routing is used.  A source route, which
  141.    must be reversed for reply packets, overrides the usual routing
  142.    mechanism, and hence destroys the security of address-based
  143.    authentication.  For this reason, many organizations disable source-
  144.    routing, at least at their border routers.
  145.  
  146.    One candidate IPng -- SIPP -- includes source-routing as an important
  147.    component.  To the extent this is used, it is a breaks address-based
  148.    authentication.  This may not be bad; in fact, it is probably good.
  149.    But it is vital that a more secure cryptographic authentication
  150.    protocol be defined and deployed before any substantial cutover to
  151.    source routing, if SIPP is adopted.
  152.  
  153. Accounting
  154.  
  155.    An significant part of the world wishes to do usage-sensitive
  156.    accounting.  This may be for billing, or it may simply be to
  157.    accomodate quality-of-service requests.  Either way, definitive
  158.    knowledge of the relevant address fields is needed.  To accomodate
  159.    this, IPng should have a non-intrusive packet authentication
  160.    mechanism.  By "non-intrusive", I mean that it should (a) present
  161.    little or no load to intermediate hops that do not need to do
  162.    authentication; (b) be deletable (if desired) by the border gateways,
  163.    and (c) be ignorable by end-systems or billing systems to which it is
  164.    not relevant.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Bellovin                                                        [Page 3]
  171.  
  172. RFC 1675               Security Concerns for IPng            August 1994
  173.  
  174.  
  175. References
  176.  
  177.    [1] Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability
  178.        and Transition Mechanism", Work in Progress, March 16, 1994.
  179.  
  180.    [2] Piscitello, D., "Transition Plan for TUBA/CLNP", Work in
  181.        Progress, March 4, 1994.
  182.  
  183. Security Consierations
  184.  
  185.    This entire memo is about Security Considerations.
  186.  
  187. Author's Address
  188.  
  189.    Steven M. Bellovin
  190.    Software Engineering Research Department
  191.    AT&T Bell Laboratories
  192.    600 Mountain Avenue
  193.    Murray Hill, NJ  07974, USA
  194.  
  195.    Phone: +1 908-582-5886
  196.    Fax: +1 908-582-3063
  197.    EMail:  smb@research.att.com
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Bellovin                                                        [Page 4]
  227.  
  228.