RFC 1675 (rfc1675) - Page 2 of 4

Security Concerns for IPng

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