Browse Prior Art Database

Security Concerns for IPng (RFC1675)

IP.com Disclosure Number: IPCOM000002512D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 4 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

Related Documents

10.17487/RFC1675: DOI

Abstract

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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

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

Processing...
Loading...