GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1675

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

Source Routing and Address-based Authentication

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

Accounting

 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.

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

References

 [1] Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability
     and Transition Mechanism", Work in Progress, March 16, 1994.
 [2] Piscitello, D., "Transition Plan for TUBA/CLNP", Work in
     Progress, March 4, 1994.

Security Consierations

 This entire memo is about Security Considerations.

Author's Address

 Steven M. Bellovin
 Software Engineering Research Department
 AT&T Bell Laboratories
 600 Mountain Avenue
 Murray Hill, NJ  07974, USA
 Phone: +1 908-582-5886
 Fax: +1 908-582-3063
 EMail:  smb@research.att.com

Bellovin [Page 4]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1675.txt · Last modified: 1994/08/04 23:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki