home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-richardson-ipsec-icmp-filter-00.txt < prev    next >
Text File  |  1997-07-16  |  6KB  |  235 lines
  1. Network Working Group      Michael Richardson mcr@sandelman.ottawa.on.ca
  2. INTERNET-DRAFT                               SSH Communications Security
  3. draft-richardson-ipsec-icmp-filter.txt                v1.0, 16 July 1997
  4. Expires in six months
  5.  
  6.  
  7.            Why traceroute can not work through IPsec gateways
  8.  
  9. Status of This memo
  10.  
  11. This document is an Internet-Draft. Internet-Drafts are working
  12. documents of the Internet Engineering Task Force (IETF), its areas,
  13. and its working groups. Note that other groups may also distribute
  14. working documents as Internet-Drafts.
  15.  
  16. Internet-Drafts are draft documents valid for a maximum of six
  17. months and may be updated, replaced, or obsoleted by other documents
  18. at any time. It is inappropriate to use Internet-Drafts as reference
  19. material or to cite them other than as ``work in progress.''
  20.  
  21. To learn the current status of any Internet-Draft, please check
  22. the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
  23. Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  24. munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast),
  25. or ftp.isi.edu (US West Coast).
  26.  
  27. Abstract
  28.  
  29. This document describes the problem of doing diagnostics through IPsec
  30. gateways (VPNs). If the gateways implement their policies to the letter,
  31. then diagnostics are not possible.
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 1]
  59.  
  60. INTERNET-DRAFT                                        v1.0, 16 July 1997
  61.  
  62. Table of Contents
  63.  
  64. 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  65.   1.1.  Definition of terminology   . . . . . . . . . . . . . . . . .  2
  66. 2.  Options HEADER-2  . . . . . . . . . . . . . . . . . . . . . . . .  3
  67.   2.2.  ICMP from preset list   . . . . . . . . . . . . . . . . . . .  3
  68.   2.3.  The header inside the ICMP packet gives the truth. This could be   3
  69. 3.  References:   . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  70.   3.1.  Author's Address  . . . . . . . . . . . . . . . . . . . . . .  4
  71.   3.2.  Expiration and File Name  . . . . . . . . . . . . . . . . . .  4
  72.  
  73.  
  74.  
  75. 1.  Introduction
  76.  
  77. 1.1.  Definition of terminology
  78.  
  79. Here is a network of two security gateways, a client node and a server
  80. node.
  81.  
  82.                   org1                org2
  83.                  C1-\                 /-S1
  84.                     +--{G1}----{G2}-{R1}
  85.                  C2-/                 \-S2
  86.  
  87.             C1 is a host.
  88.             C2 is another host.
  89.             G1/G1 are security gateways.
  90.             S1 is a host.
  91.             S2 is a host.
  92.             R1 is a router.
  93.  
  94. There are per-host SA's linking C1<->S1, C2<->S2, and also C1<->S2.
  95.  
  96. One does a traceroute from C1 to S.
  97.  
  98. One expects to see:
  99.  
  100.           traceroute to S1 (192.168.32.71), 30 hops max, 40 byte packets
  101.            1  G1  2.323 ms  2.323 ms  2.323 ms
  102.            2  G2  3.456 ms  3.456 ms  3.456 ms
  103.            3  R1  8.456 ms  8.456 ms  8.456 ms
  104.            4  S1  5.678 ms  5.678 ms  5.678 ms
  105.  
  106. The first return is from G1. The second return is from G2, the final one
  107. is from S. Let's examine the details of the ICMP datagrams that are
  108. received by C1.
  109.  
  110. 1. A datagram from G1 to C1, traverses a protected (unencrypted
  111.    network). No problem, there is no SA to restrict traffic between G1
  112.    and C1.
  113.  
  114. 2. A datagram from G2 to C1. This is a problem: The SA between G1 and G2
  115.  
  116.  
  117. Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 2]
  118.  
  119. INTERNET-DRAFT                                        v1.0, 16 July 1997
  120.  
  121.    is for datagrams between C1 and S1, but the datagram doesn't fit into
  122.    that pattern. It is reasonable to assume that the filter code could
  123.    be persuaded to accept this packet. It is from a node that is trusted
  124.    (G2), which could easily send a spoofed datagram (claiming to be from
  125.    S1) through tunnel if it wanted to.
  126.  
  127.    The question remains: which SA should be used? Clearly, it should be
  128.    the one linking C1 and S1, not the one linking C1 and S2. The two
  129.    SA's could have very different privacy attributes. One must pick the
  130.    right SA bundle. This problem is solvable at this level.
  131.  
  132. 3. A datagram from R1 to C1. This is an even worse problem. The gateway
  133.    has little ability to know if R1 is even legitimately a router on
  134.    which datagrams to S1 must travel. Further, there is now no record in
  135.    the outer ip header as to which SA to use.
  136.  
  137. 4. A datagram from S2 to G2. No problem, the SA covers this already.
  138.  
  139. 2.  Options HEADER-2
  140.  
  141. 2.1.  No ICMP?
  142.  
  143. One possible solution is to give up on moving ICMP datagrams at all.
  144.  
  145. 2.2.  ICMP from preset list
  146.  
  147. Maybe it is enough to accept ICMP datagrams from a preconfigured list of
  148. routers. This list would include the IPsec gateway (G2), and the list
  149. would have to be passed to G1.
  150.  
  151. 2.3.  The header inside the ICMP packet gives the truth. This could be
  152. used to determine if the packet had appropriate source/destinations.
  153. Examine the ICMP HEADER-2
  154.  
  155. 2.4.  ICMP soft state?
  156.  
  157. The ICMP datagram carries some 28 bytes (plus options) of the original
  158. datagram. The destination/source/id field ought to be unique. The
  159. gateways could take arrival of an ICMP datagram with some destination as
  160. an indication to start recording datagram ids (i.e. accumulating soft
  161. state). A retransmission occurs, and then the ICMP can be matched to an
  162. actual IP datagram.
  163.  
  164. This is not very secure, as it can be spoofed by any node on org2's
  165. network. The assumed requirement for host based SA's, implies a distrust
  166. of org2's network.
  167.  
  168. 3.  References:
  169.  
  170.    RFC-1825
  171.       R. Atkinson, "Security Architecture for the Internet Protocol",
  172.       RFC-1825, August 1995.
  173.  
  174.  
  175.  
  176. Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 3]
  177.  
  178. INTERNET-DRAFT                                        v1.0, 16 July 1997
  179.  
  180.    RFC-1191
  181.       J. Mogul, S. Deering, "Path MTU Discovery", RFC-1191, November
  182.       1990.
  183.  
  184.    RFC-1812
  185.       F. Baker, "Reqirements for IP Version 4 Routers", RFC-1812, June
  186.       1995
  187.  
  188. 3.1.  Author's Address
  189.  
  190.              Michael C. Richardson
  191.              Sandelman Software Works Corp.
  192.              152 Rochester Street
  193.              Ottawa, ON K1R 7M4
  194.              Canada
  195.  
  196.              Telephone:   +1 613 233-6809
  197.              EMail:       mcr@sandelman.ottawa.on.ca
  198.  
  199. 3.2.  Expiration and File Name
  200.  
  201. This draft expires January 9, 1997
  202.  
  203. Its file name is draft-richardson-ipsec-icmp-filter-00.txt
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234. Michael Richardson mcr@sandelman.ottawa.on.ca                   [page 4]
  235.