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