home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-vpn-00.txt < prev    next >
Text File  |  1997-03-14  |  13KB  |  339 lines
  1.  
  2.  
  3. Network Working Group                       Naganand Doraswamy (FTP Software)
  4. Internet Draft                                          12 March, 1997
  5.  
  6.  
  7.            Implementation of Virtual Private Network (VPNs) with IP Secrity
  8.                  <draft-ietf-ipsec-vpn-00.txt>
  9.  
  10.  
  11. Status of This Memo
  12.  
  13.    Distribution of this memo is unlimited.
  14.  
  15.    This document is an Internet-Draft.  Internet Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its Areas,
  17.    and its Working Groups.  Note that other groups may also distribute
  18.    working documents as Internet Drafts.
  19.  
  20.    Internet Drafts are draft documents valid for a maximum of six
  21.    months, and may be updated, replaced, or obsoleted by other documents
  22.    at any time.  It is not appropriate to use Internet Drafts as
  23.    reference material, or to cite them other than as a ``working draft''
  24.    or ``work in progress.''
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
  28.    Directories on:
  29.  
  30.       ftp.is.co.za (Africa)
  31.       nic.nordu.net (Europe)
  32.       ds.internic.net (US East Coast)
  33.       ftp.isi.edu (US West Coast)
  34.       munnari.oz.au (Pacific Rim)
  35.  
  36. Abstract
  37.  
  38.    This document discusses methods for implementing Virtural Private
  39.    Networks (VPN) with IP Security (IPSec). We discuss different scenarios in
  40.    which VPN is implemented and the security implications for each of these
  41.    scenarios. 
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Doraswamy                                             [Page 1]
  53.  
  54. INTERNET DRAFT              October 10, 1996        Expires April 1997
  55.  
  56.  
  57. Contents
  58.  
  59.    1.  Introduction...................................................
  60.    2.  Scenarios
  61.    2.1    Road Warrior into Corporate Network
  62.    2.2    Securing packets only on Internet
  63.    2.3    Securing packets to Net 10 Hosts
  64.    2.4    AH in tunnel mode
  65.    ACKNOWLEDGMENTS....................................................
  66.    REFERENCES.........................................................
  67.    CONTACTS...........................................................
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107. Doraswamy                                               [Page 2]
  108.  
  109. INTERNET DRAFT              October 10, 1996        Expires April 1997
  110.  
  111.  
  112. 1. Introduction
  113.  
  114.    The Authentication Header (AH) [RFC-1826] provides integrity and
  115.    authentication for IP datagrams.  ESP provides data confidentiality,
  116.    integrity, and authentication. These protocols are used to secure packets
  117.    end to end and are normally called IP Security (IPSec). However, with
  118.    intervening gateways (firewalls) or because of the 
  119.    faith in their own private networks, some organizations may choose to secure
  120.    the packets only on the Intenet and let the packets travel in clear text
  121.    inside the organization. 
  122.  
  123.    This document discusses some scenarios where IPSec can be used to achieve
  124.    this functionality. We also discuss the security implications under each of
  125.    this scenario.
  126.  
  127.    Familiarity with the following documents is assumed: "Security
  128.    Architecture for the Internet Protocol" [RFC-1825], "IP
  129.    Authentication Header" [RFC-1826], "IP Encapsulated Security Payload"
  130.    [RFC-1827]. 
  131.  
  132. 1.1
  133.  
  134.    This section defines certain terms used in this memo in order to communicate
  135.    with greater clarity.
  136.  
  137.     NODE      Any system implementing the TCP/IP protocol suite.       
  138.  
  139.     HOST      Any IP node that does not forward packets not addressed
  140.               to the node itself.
  141.  
  142.     ROUTER    An IP node that forwards packets not addressed to itself.
  143.  
  144.     FIREWALL  An IP node located on the perimeter of an administrative
  145.               domain that implements that domain's security policy.
  146.               A firewall usually performs address and port-based
  147.               packet filtering and usually has stateful proxy servers
  148.               for EMAIL and other services.  
  149.  
  150.     ENCRYPTING FIREWALL    A firewall that implements full IP Security,
  151.               including AH and both tunnel-mode and transport-mode ESP.
  152.  
  153.     PROXY SECURITY SERVER        A node that encrypts or decrypts traffic on
  154.               behalf of some other node.  Encrypting Firewalls often also
  155.               function as proxy security servers.
  156.  
  157.     KEY MANAGEMENT PROXY    A node implementing a key management protocol on
  158.               behalf of some other node.
  159.  
  160.     MOBILE NODE    A node that is mobile and is not permanently attached
  161.               to a fixed location from the perspective of IP. 
  162.  
  163.     PRIVATE ADDRESS    An IP address that is not globally unique and is only
  164.               useful within a particular private administrative domain.
  165.  
  166.     NAT       Network Address Translator.  A router that selectively 
  167.               translates IP addresses in packets prior to forwarding 
  168.               the packets.  NATs are commonly used to connect network
  169.               regions where private addressing is in use to network
  170.               regions having conflicting private addressing or having
  171.               globally-unique addressing.
  172.  
  173.     SECURE PACKET       In this document this term is used to represent an IP
  174.                         packet with AH and/or ESP.
  175.  
  176. 2. Scenarios
  177.  
  178. 2.1 Remote Node into Corporate Network
  179.  
  180.     Consider the case where a mobile node (host A) needs to communicate with
  181.     host B behind a firewall (F). In this case, it is necessary
  182.     that all packets from A to B always go through F. The firewall is
  183.     configured  not to let any unauthenticated packets into the network. There
  184.     are a few solutions to this problem.
  185.  
  186. 2.1.1 Packets tunneled to firewall
  187.     The host A establishes an SA between itself and F and sends a pkt tunneled
  188.     to F with the final destination B. In this case, F decrypts/authenticates
  189.     the pkt and forwards the pkt depending on the rules at F. The pkt is
  190.     forwarded from F to B either in clear text or using AH/ESP. If the pkt
  191.     needs to be secured the firewall needs to establish an SA between itself
  192.     and B.  
  193.  
  194.     For outbound pkt, i.e. pkts sent from B through the firewall to A, B does
  195.     not secure the packets to be sent to A. The firewall F after receiving the
  196.     packet destined to A, secures the packet. B might however secure the packet
  197.     to F depending on its trust on its internal network.
  198.  
  199.     The problem with this is that the end host (B) has to beleive the
  200.     firewall. It has to assume that the firewall is doing the necessary
  201.     security on the inbound packets. Also, on the outbound packets it has to
  202.     assume that they are going to be secured at the firewall.
  203.  
  204.     The advantage of this is that the firewall can apply the normal filtering
  205.     rules on the packet as the inner payload is not encrypted.
  206.  
  207. 2.1.2 Packets secured to end host
  208.     In thiscase, the firewall (F) is authorised to act as
  209.     a key management proxy for the hosts on either side of it.  So when
  210.     A seeks to initiate a secure session with B, it discovers (either via
  211.     the KX record of DNS security or via manual configuration) that it 
  212.     should initiate the Key Management exchange with F, with F acting 
  213.     on behalf of B.  From A's perspective, this results in a Security 
  214.     Association between A and B, even though the packet will transit F 
  215.     en route to B.  In this case, F has the capability of decrypting and 
  216.     examining the packet contents before deciding whether to forward the 
  217.     packet to B or to discard it.  This permits IPsec to be used between 
  218.     A and B even though F is still applying its packet filtering policy.
  219.  
  220.     The advantage of this approach is that the end host is encrypting and
  221.     decrypting packets . However, there is still an implicit assumption that
  222.     the firewall is not changing any traffic. 
  223.  
  224. 2.1.3 Packets secured to end host and tunneled to firewall
  225.     In this case, the inner payload is secured to B (transport mode ESP and AH)
  226.     , and the outer payload tunneled and secured to firewall F.
  227.  
  228.     The advantage of this scheme is that the firewall is able to authenticate
  229.     packets and decide whether to allow the packet or not without applying the
  230.     normal filtering rules. This is typical of what happens in the networks
  231.     today, where an employee gets into the corporate network via a dialup PPP.
  232.  
  233.     On packets destined from B to A, the packets leaving B has transport mode
  234.     ESP and AH, and the packet is tunneled from F to A after securing the
  235.     packet. 
  236.  
  237. 2.2 Securing packets only on Internet
  238.  
  239.     This case handles securing packets between two or more border routers
  240.     of a topologically distributed organisation (i.e. one organisation 
  241.     having more than one site without direct internal connectivity 
  242.     between all of the organisation's sites). This scenario is
  243.     applicable when the organization has faith in its private network but not
  244.     Internet.  This model treats Internet as a set of pipes.
  245.  
  246.     In this case, Security Associations are setup between the border
  247.     routers.  The border routers enforce a policy where all traffic
  248.     to or from another site of this organisation must be secured
  249.     using IPsec before being forwarded and must arrive secured
  250.     as well.
  251.  
  252.     In this case, the KX record for each site probably exists and
  253.     is configured to point to the border routers for that site.  In
  254.     this way, all nodes outside of that site know that the Border Router
  255.     handles IPsec on behalf of nodes within that site.
  256.  
  257.     In implementing VPN in this mode, one has to be aware of the following:
  258.  
  259.     - All packets flowing between the two topologically separated facilites
  260.     always use the routers that have been configured with security. 
  261.  
  262.     - All packets between the two routers MUST contain valid IPsec.  Any packet
  263.     received at either router claiming to come from either the other router or
  264.     from any node protected by the other router MUST contain valid IPsec or be
  265.     dropped upon receipt.  To do otherwise creates a security hole for
  266.     spoofers. 
  267.  
  268.  
  269. 2.3 Securing packets to Net 10 Hosts
  270.  
  271.     This handles the case where an organisation is using IP addresses that are
  272.     private (e.g. use of 10.x.x.x as per RFC-1918). When packets
  273.     have to be secured to hosts that are in net 10 environment, one needs 
  274.     infrastructure. DNS support is needed to identify where the packets
  275.     destined for the net 10 hosts can be tunneled to so that, NAT
  276.     can then forward the packets to this private host. 
  277.  
  278.     Consider site S with border router R1.  Let S1 be some node inside site S
  279.     and behind R1. Consider some remote node X that is not within the same
  280.     administrative domain as S or R1.  Now consider that X wishes to initiate
  281.     an IP session with some node S1.  X performs a DNS lookup on S1 and
  282.     receives an authenticated A/AAAA record with S1's address and also obtains
  283.     a KX record covering S that points to R1.  This enables X to know that it
  284.     should initiate a key exchange session with R1 if X wishes to use IPsec to
  285.     protect its session to S1. In this case, R1 is behaving as NAT as well as
  286.     proxy security server.
  287.  
  288.     In this scenario, NAT is responsible to impose security on the
  289.     packets flowing into the net 10 environment and there could be some
  290.     performance bottlenecks. 
  291.  
  292. 2.4 AH in tunnel mode
  293.  
  294.     AH in tunnel mode is useful in cases such as Scenario 2 of section 2.1
  295.     where you may have a requiment that says that all packets flowing between
  296.     two routers need to be authenticated. It is also useful in cases when the
  297.     end hosts do not implement IPSecurity and decision needs to be made at
  298.     firewall/router as to which packets should be let into the network.
  299.  
  300.     In this scenario, it should be noted that AH does not protect the
  301.     confidentiality of any data being transmitted and hence this is not
  302.     strictly speaking a Virtual Private Network.  VPNs separate the different
  303.     logical networks via encryption while AH only provides cryptographic 
  304.     authentication. 
  305.     
  306. Note: Some of the discussions above may change depending on the new drafts.
  307.  
  308. Acknowledgments
  309.     I would like to thank Ran Atkinson and Steve Kent for their valuable
  310.     input. 
  311.  
  312. References
  313.  
  314.  
  315.     [RFC-1825]    R. Atkinson, "Security Architecture for the Internet
  316.                   Protocol", RFC-1852, Naval Research Laboratory, July 1995.
  317.     [RFC-1826]    R. Atkinson, "IP Authentication Header",
  318.                   RFC-1826, August 1995.
  319.     [RFC-1827]    R. Atkinson, "IP Encapsulate Security Payload"
  320.                     RFC-1827, August 1995.
  321.     [RFC-1918]    Net 10 (need to add more into)
  322.  
  323.  
  324. Doraswamy                                               [Page 6]
  325.  
  326. INTERNET DRAFT              October 10, 1996        Expires April 1997
  327.  
  328.  
  329. Contact
  330.  
  331.     Naganand Doraswamy
  332.     FTP Software Inc.,
  333.     2 High St.,
  334.     North Andover, MA 01845
  335.     naganand@ftp.com
  336.    
  337.  
  338.  
  339.