Security Concerns for IPng
RFC 1675

Document Type RFC - Informational (August 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1675 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        S. Bellovin
Request for Comments: 1675                        AT&T Bell Laboratories
Category: Informational                                      August 1994

                       Security Concerns for IPng

Status of this Memo

   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.

Abstract

   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.

Overview and Rationale

   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.

Firewalls

   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.

   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.

Bellovin                                                        [Page 1]
RFC 1675               Security Concerns for IPng            August 1994

   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.

   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.

   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.

   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.

   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.

Encryption and Authentication

   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.

   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.)

Bellovin                                                        [Page 2]
RFC 1675               Security Concerns for IPng            August 1994

   Dual-stack approaches, such as in TUBA's transition plan [2], imply
   multiple addresses for each host.  (IPAE has this feature, too.) The
Show full document text