home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1455.txt < prev    next >
Text File  |  1996-05-07  |  13KB  |  188 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                   D. Eastlake, III Request for Comments: 1455                 Digital Equipment Corporation                                                                 May 1993 
  8.  
  9.                   Physical Link Security Type of Service 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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. 
  18.  
  19. 1. Nature of Requirement 
  20.  
  21.    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. 
  22.  
  23. 1.1 Traffic Analysis 
  24.  
  25.    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. 
  26.  
  27.  
  28.  
  29. Eastlake                                                        [Page 1] 
  30.  RFC 1455                   Link Security TOS                    May 1993 
  31.  
  32.     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. 
  33.  
  34.    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. 
  35.  
  36.    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. 
  37.  
  38. 1.2 Confidentiality 
  39.  
  40.    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. 
  41.  
  42.    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. 
  43.  
  44.    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. 
  45.  
  46.  
  47.  
  48.  Eastlake                                                        [Page 2] 
  49.  RFC 1455                   Link Security TOS                    May 1993 
  50.  
  51.  1.3 Link Physical Security Characteristics 
  52.  
  53.    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: 
  54.  
  55.       1) Land line media is usually harder to intercept than radio          broadcast media. 
  56.  
  57.       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. 
  58.  
  59.       3) Between land lines, point to point systems are generally harder          to intercept than multi-point systems such as Ethernet or FDDI. 
  60.  
  61.       4) Fiber optic land lines are generally harder to intercept than          metallic paths because fiber is harder to tap. 
  62.  
  63.       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. 
  64.  
  65.       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. 
  66.  
  67.    Routers also have different levels of security against interception    depending on the physical security of the router site and the like. 
  68.  
  69.    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. 
  70.  
  71. 2. Protocol Specification 
  72.  
  73.    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.) 
  74.  
  75.  
  76.  
  77.  
  78.  
  79. Eastlake                                                        [Page 3] 
  80.  RFC 1455                   Link Security TOS                    May 1993 
  81.  
  82.  3. Protocol Implementation 
  83.  
  84.    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. 
  85.  
  86.    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. 
  87.  
  88.    An example of "costs" at a hypothetical router could be as follows: 
  89.  
  90.            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 
  91.  
  92.    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. 
  93.  
  94.    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 
  95.  
  96.  
  97.  
  98. Eastlake                                                        [Page 4] 
  99.  RFC 1455                   Link Security TOS                    May 1993 
  100.  
  101.     other defined TOS values. 
  102.  
  103.    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. 
  104.  
  105. References 
  106.  
  107.    [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol        Specification", STD 5, RFC 791, DARPA, September 1981. 
  108.  
  109.    [2] Braden, R., Editor, "Requirements for Internet Hosts --        Communication Layers", STD 3, RFC 1122, IETF, October 1989. 
  110.  
  111.    [3] Braden, R., Editor, "Requirements for Internet Hosts --        Application and Support", STD 3, RFC 1123, IETF, October 1989. 
  112.  
  113.    [4] Almquist, P., "Type of Service in the Internet Protocol Suite",        RFC 1349, Consultant, July 1992. 
  114.  
  115.    [5] Moy, J., Editor, "OSPF Protocol Analysis", RFC 1245, Proteon,        Inc., July 1991. 
  116.  
  117.    [6] Moy, J., Editor, "Experience with the OSPF Protocol", RFC 1246,        Proteon, Inc., July 1991. 
  118.  
  119.    [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991. 
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141. Eastlake                                                        [Page 5] 
  142.  RFC 1455                   Link Security TOS                    May 1993 
  143.  
  144.  Security Considerations 
  145.  
  146.    The entirety of this memo concerns an Internet Protocol Type of    Service to request maximum physical link security against    surreptitious interception. 
  147.  
  148. Author's Address 
  149.  
  150.    Donald E. Eastlake, III    Digital Equipment Corporation*    30 Porter Road, MS: LJO2/I4    Littleton, MA 01460 
  151.  
  152.    Phone: +1 508 486 2358 (w),  +1 617 244 2679 (h)    Email: dee@ranger.enet.dec.com 
  153.  
  154.    *Company affiliation given for identification only.  This document    does not constitute a statement, official or otherwise, by Digital    Equipment Corporation. 
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  Eastlake                                                        [Page 6] 
  187.  
  188.