Security Concerns for IPng (RFC1675)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
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 email@example.com mailing list.
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.
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 firstname.lastname@example.org 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.
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
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.
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
In a different vein, at least one of the possible transition plans
uses network-level packet translators . 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 --...