doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc1675.txt b/doc/rfc/rfc1675.txt
new file mode 100644
index 0000000..2574273
--- /dev/null
+++ b/doc/rfc/rfc1675.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+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]
+