doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc1455.txt b/doc/rfc/rfc1455.txt
new file mode 100644
index 0000000..17f01aa
--- /dev/null
+++ b/doc/rfc/rfc1455.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, III
+Request for Comments: 1455                 Digital Equipment Corporation
+                                                                May 1993
+
+
+                 Physical Link Security Type of Service
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  Discussion and suggestions for improvement are requested.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This RFC documents an experimental protocol providing a Type of
+   Service (TOS) to request maximum physical link security.  This is an
+   addition to the types of service enumerated in RFC 1349: Type of
+   Service in the Internet Protocol Suite.  The new TOS requests the
+   network to provide what protection it can against surreptitious
+   observation by outside agents of traffic so labeled.  The purpose is
+   protection against traffic analysis and as an additional possible
+   level of data confidentiality.  This TOS is consistent with all other
+   defined types of service for IP version 4 in that it is based on link
+   level characteristics and will not provide any particular guaranteed
+   level of service.
+
+1. Nature of Requirement
+
+   This Internet Protocol addition addresses two potential security
+   requirements: resistance to traffic analysis and confidentiality.
+   These are described in the two subsections below followed by a
+   discussion of why links have different levels of physical security so
+   that it is meaningful to request that more secure links be used.
+
+1.1 Traffic Analysis
+
+   At this time all Internet Protocol (IP) packets must have most of
+   their header information, including the "from" and "to" addresses, in
+   the clear.  This is required for routers to properly handle the
+   traffic even if a higher level protocol fully encrypts all bytes in
+   the packet after the IP header.  This renders even end-to-end
+   encrypted IP packets subject to traffic analysis if the data stream
+   can be observed.  While traffic statistics are normally less
+   sensitive than the data content of packets, in some cases activities
+   of hosts or users are deducible from traffic information.
+
+
+
+Eastlake                                                        [Page 1]
+
+RFC 1455                   Link Security TOS                    May 1993
+
+
+   It is essential that routers have access to header information, so it
+   is hard to protect traffic statistics from an adversary with inside
+   access to the network.  However, use of more secure physical links
+   will make traffic observation by entities outside of the network more
+   difficult thus improving protection from traffic analysis.
+
+   No doubt users would like to be able to request a guaranteed level of
+   link security, just as they would like to be able to request a
+   guaranteed bandwidth or delay through the network.  However, such
+   guarantees require a resource reservation and/or policy routing
+   scheme and are beyond the scope of the current IP Type of Service
+   facility.
+
+   Although the TOS field is provided in all current Internet packets
+   and routing based on TOS is provided in routing protocols such as
+   OSPF [See 5,6,7], there is no realistic chance that all of the
+   Internet will implement this additional TOS any time in the
+   foreseeable future.  Nevertheless, users concerned about traffic
+   analysis need to be able to request that the physical security of the
+   links over which their packets will be pass be maximized in
+   preference to other link characteristics.  The proposed TOS provides
+   this capability.
+
+1.2 Confidentiality
+
+   Use of physical links with greater physical security provides a layer
+   of protection for the confidentiality of the data in the packets as
+   well as traffic analysis protection.  If the content of the packets
+   are otherwise protected by end-to-end encryption, using secure links
+   makes it harder for an external adversary to obtain the encrypted
+   data to attack.  If the content of the packets is unencrypted plain
+   text, secure links may provide the only protection of data
+   confidentiality.
+
+   There are cases where end-to-end encryption can not be used.
+   Examples include paths which incorporate links within nations which
+   restrict encryption, such as France or Australia, and paths which
+   incorporate an amateur radio link, where encryption is prohibited.
+   In these cases, link security is generally the only type of
+   confidentiality available.  The proposed TOS will provide a way of
+   requesting the best that the network can do for the security of such
+   unencrypted data.
+
+   This TOS is required for improved confidentiality, especially in
+   cases where encryption can not be used, despite the fact that it does
+   not provide the guarantees that many users would like.  See
+   discussion at the end of the Traffic Analysis section above.
+
+
+
+
+Eastlake                                                        [Page 2]
+
+RFC 1455                   Link Security TOS                    May 1993
+
+
+1.3 Link Physical Security Characteristics
+
+   Physical links, which are composed of lines and routers, differ
+   widely in their susceptibility to surreptitious observation of the
+   information flowing over them.  For examples of line security see the
+   following list:
+
+      1) Land line media is usually harder to intercept than radio
+         broadcast media.
+
+      2) Between different radio broadcast media, spread spectrum or
+         other low probability of intercept systems, are harder to
+         intercept than normal broadcast systems.  At the other extreme,
+         systems with a large footprint on the earth, such as some
+         satellite down links, may be particularly accessible.
+
+      3) Between land lines, point to point systems are generally harder
+         to intercept than multi-point systems such as Ethernet or FDDI.
+
+      4) Fiber optic land lines are generally harder to intercept than
+         metallic paths because fiber is harder to tap.
+
+      5) A secure land line, such as one in pressurized conduit with
+         pressure alarms or one installed so as to be observable by
+         guards, is harder to intercept than an unsecured land line.
+
+      6) An encrypted link would be preferable to an unencrypted link
+         because, even if it was accessed, it would be much more
+         difficult to obtain any useful information.
+
+   Routers also have different levels of security against interception
+   depending on the physical security of the router site and the like.
+
+   The above comparisons show that there are significant real
+   differences between the security of the physical links in use in the
+   Internet.  Choosing links where it is hard for an outside observer to
+   observe the traffic improves confidentiality and protection against
+   traffic analysis.
+
+2. Protocol Specification
+
+   The value 15 decimal (F hex) in the four-bit Type of Service IP
+   header field requests routing the packet to minimize the chance of
+   surreptitious observation of its contents by agents external to the
+   network.  (This value is chosen to be at the maximum hamming distance
+   from the existing other TOS values.)
+
+
+
+
+
+Eastlake                                                        [Page 3]
+
+RFC 1455                   Link Security TOS                    May 1993
+
+
+3. Protocol Implementation
+
+   This TOS can be implemented in routing systems that offer TOS based
+   routing (as can be done with OSPF, see RFCs 1245 through 1247) by
+   assigning costs to links.  Establishing the "cost" for different
+   links for this TOS is a local policy function.
+
+   In principle services are incomparable when criterion such as those
+   given in the Nature of Requirement section above conflict.  For
+   example, a choice between an encrypted broadcast system and an
+   unencrypted fiber optic land line.  In practice, link encryption
+   would probably dominate all other forms of protection and physical
+   security as mentioned in criterion 5 above would dominate other land
+   line distinctions.
+
+   An example of "costs" at a hypothetical router could be as follows:
+
+           Cost    Type
+            1      Strong encryption with secure key distribution
+            2      Physically secure point-to-point line
+            6      Typical point-to-point line
+            8      Typical local multi-point media
+           12      Metropolitan area multi-point media
+           24      Local radio broadcast
+           32      Satellite link
+
+   Link costs should be chosen so as to be in the same ratio as the
+   probability of interception.  Thus the above example costs imply a
+   local policy assumption that interception is 32 times more likely on
+   a satellite link and associated router than on a strongly encrypted
+   line and its associated router.  It is not necessary to estimate the
+   absolute probability of interception on any particular link.  It is
+   sufficient to estimate the ratio between interception probabilities
+   on different links.
+
+   It should be noted that using costs such as the example given above
+   could result in using many more links than if the default type of
+   service were requested.  For example, the use of over 50 highly
+   secure links could be better than using two insecure links, such as
+   an unencrypted satellite hop and radio link.  However, if the costs
+   have been properly set in proportion to the probability of
+   interception, this larger number of links will be more secure than
+   the shorter default routing.  This consideration should make it clear
+   why it is necessary to estimate router security as well as link
+   security.  An excessive cost ratio based solely on the security of a
+   communications line could cause packets to go through many routers
+   which were less secure than the lines in question.  This necessity to
+   take router characteristics into account is also present for all
+
+
+
+Eastlake                                                        [Page 4]
+
+RFC 1455                   Link Security TOS                    May 1993
+
+
+   other defined TOS values.
+
+   It should also be noted that routing algorithms typically compute the
+   sum of the costs of the links.  For this particular type of service,
+   the product of the link probabilities of secure transmission would be
+   more appropriate.  However, the same problem is present for the high
+   reliability TOS and the use of a sum is an adequate approximation for
+   most uses as noted in RFC 1349.
+
+References
+
+   [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
+       Specification", STD 5, RFC 791, DARPA, September 1981.
+
+   [2] Braden, R., Editor, "Requirements for Internet Hosts --
+       Communication Layers", STD 3, RFC 1122, IETF, October 1989.
+
+   [3] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support", STD 3, RFC 1123, IETF, October 1989.
+
+   [4] Almquist, P., "Type of Service in the Internet Protocol Suite",
+       RFC 1349, Consultant, July 1992.
+
+   [5] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,
+       Inc., July 1991.
+
+   [6] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246,
+       Proteon, Inc., July 1991.
+
+   [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                                                        [Page 5]
+
+RFC 1455                   Link Security TOS                    May 1993
+
+
+Security Considerations
+
+   The entirety of this memo concerns an Internet Protocol Type of
+   Service to request maximum physical link security against
+   surreptitious interception.
+
+Author's Address
+
+   Donald E. Eastlake, III
+   Digital Equipment Corporation*
+   30 Porter Road, MS: LJO2/I4
+   Littleton, MA 01460
+
+   Phone: +1 508 486 2358 (w),  +1 617 244 2679 (h)
+   Email: dee@ranger.enet.dec.com
+
+   *Company affiliation given for identification only.  This document
+   does not constitute a statement, official or otherwise, by Digital
+   Equipment Corporation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                                                        [Page 6]
+
\ No newline at end of file