[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Network Working Group                       Naganand Doraswamy (FTP Software)
Internet Draft                                          12 March, 1997


           Implementation of Virtual Private Network (VPNs) with IP Secrity
                 <draft-ietf-ipsec-vpn-00.txt>


Status of This Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as
   reference material, or to cite them other than as a ``working draft''
   or ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

Abstract

   This document discusses methods for implementing Virtural Private
   Networks (VPN) with IP Security (IPSec). We discuss different scenarios in
   which VPN is implemented and the security implications for each of these
   scenarios.










Doraswamy                                             [Page 1]


INTERNET DRAFT              October 10, 1996        Expires April 1997


Contents

   1.  Introduction...................................................
   2.  Scenarios
   2.1    Road Warrior into Corporate Network
   2.2    Securing packets only on Internet
   2.3    Securing packets to Net 10 Hosts
   2.4    AH in tunnel mode
   ACKNOWLEDGMENTS....................................................
   REFERENCES.........................................................
   CONTACTS...........................................................







































Doraswamy                                               [Page 2]


INTERNET DRAFT              October 10, 1996        Expires April 1997


1. Introduction

   The Authentication Header (AH) [RFC-1826] provides integrity and
   authentication for IP datagrams.  ESP provides data confidentiality,
   integrity, and authentication. These protocols are used to secure packets
   end to end and are normally called IP Security (IPSec). However, with
   intervening gateways (firewalls) or because of the
   faith in their own private networks, some organizations may choose to secure
   the packets only on the Intenet and let the packets travel in clear text
   inside the organization.

   This document discusses some scenarios where IPSec can be used to achieve
   this functionality. We also discuss the security implications under each of
   this scenario.

   Familiarity with the following documents is assumed: "Security
   Architecture for the Internet Protocol" [RFC-1825], "IP
   Authentication Header" [RFC-1826], "IP Encapsulated Security Payload"
   [RFC-1827].

1.1

   This section defines certain terms used in this memo in order to communicate
   with greater clarity.

    NODE      Any system implementing the TCP/IP protocol suite.

    HOST      Any IP node that does not forward packets not addressed
              to the node itself.

    ROUTER    An IP node that forwards packets not addressed to itself.

    FIREWALL  An IP node located on the perimeter of an administrative
              domain that implements that domain's security policy.
              A firewall usually performs address and port-based
              packet filtering and usually has stateful proxy servers
              for EMAIL and other services.

    ENCRYPTING FIREWALL A firewall that implements full IP Security,
              including AH and both tunnel-mode and transport-mode ESP.

    PROXY SECURITY SERVER               A node that encrypts or decrypts traffic on
              behalf of some other node.  Encrypting Firewalls often also
              function as proxy security servers.

    KEY MANAGEMENT PROXY        A node implementing a key management protocol on
              behalf of some other node.

    MOBILE NODE A node that is mobile and is not permanently attached
              to a fixed location from the perspective of IP.

    PRIVATE ADDRESS     An IP address that is not globally unique and is only
              useful within a particular private administrative domain.

    NAT       Network Address Translator.  A router that selectively
              translates IP addresses in packets prior to forwarding
              the packets.  NATs are commonly used to connect network
              regions where private addressing is in use to network
              regions having conflicting private addressing or having
              globally-unique addressing.

    SECURE PACKET       In this document this term is used to represent an IP
                        packet with AH and/or ESP.

2. Scenarios

2.1 Remote Node into Corporate Network

    Consider the case where a mobile node (host A) needs to communicate with
    host B behind a firewall (F). In this case, it is necessary
    that all packets from A to B always go through F. The firewall is
    configured  not to let any unauthenticated packets into the network. There
    are a few solutions to this problem.

2.1.1 Packets tunneled to firewall
    The host A establishes an SA between itself and F and sends a pkt tunneled
    to F with the final destination B. In this case, F decrypts/authenticates
    the pkt and forwards the pkt depending on the rules at F. The pkt is
    forwarded from F to B either in clear text or using AH/ESP. If the pkt
    needs to be secured the firewall needs to establish an SA between itself
    and B.

    For outbound pkt, i.e. pkts sent from B through the firewall to A, B does
    not secure the packets to be sent to A. The firewall F after receiving the
    packet destined to A, secures the packet. B might however secure the packet
    to F depending on its trust on its internal network.

    The problem with this is that the end host (B) has to beleive the
    firewall. It has to assume that the firewall is doing the necessary
    security on the inbound packets. Also, on the outbound packets it has to
    assume that they are going to be secured at the firewall.

    The advantage of this is that the firewall can apply the normal filtering
    rules on the packet as the inner payload is not encrypted.

2.1.2 Packets secured to end host
    In thiscase, the firewall (F) is authorised to act as
        a key management proxy for the hosts on either side of it.  So when
        A seeks to initiate a secure session with B, it discovers (either via
        the KX record of DNS security or via manual configuration) that it
        should initiate the Key Management exchange with F, with F acting
        on behalf of B.  From A's perspective, this results in a Security
        Association between A and B, even though the packet will transit F
        en route to B.  In this case, F has the capability of decrypting and
        examining the packet contents before deciding whether to forward the
        packet to B or to discard it.  This permits IPsec to be used between
        A and B even though F is still applying its packet filtering policy.

    The advantage of this approach is that the end host is encrypting and
    decrypting packets . However, there is still an implicit assumption that
    the firewall is not changing any traffic.

2.1.3 Packets secured to end host and tunneled to firewall
    In this case, the inner payload is secured to B (transport mode ESP and AH)
    , and the outer payload tunneled and secured to firewall F.

    The advantage of this scheme is that the firewall is able to authenticate
    packets and decide whether to allow the packet or not without applying the
    normal filtering rules. This is typical of what happens in the networks
    today, where an employee gets into the corporate network via a dialup PPP.

    On packets destined from B to A, the packets leaving B has transport mode
    ESP and AH, and the packet is tunneled from F to A after securing the
    packet.

2.2 Securing packets only on Internet

    This case handles securing packets between two or more border routers
        of a topologically distributed organisation (i.e. one organisation
        having more than one site without direct internal connectivity
        between all of the organisation's sites). This scenario is
    applicable when the organization has faith in its private network but not
    Internet.  This model treats Internet as a set of pipes.

    In this case, Security Associations are setup between the border
        routers.  The border routers enforce a policy where all traffic
        to or from another site of this organisation must be secured
        using IPsec before being forwarded and must arrive secured
        as well.

    In this case, the KX record for each site probably exists and
        is configured to point to the border routers for that site.  In
        this way, all nodes outside of that site know that the Border Router
        handles IPsec on behalf of nodes within that site.

    In implementing VPN in this mode, one has to be aware of the following:

    - All packets flowing between the two topologically separated facilites
    always use the routers that have been configured with security.

    - All packets between the two routers MUST contain valid IPsec.  Any packet
    received at either router claiming to come from either the other router or
    from any node protected by the other router MUST contain valid IPsec or be
    dropped upon receipt.  To do otherwise creates a security hole for
    spoofers.


2.3 Securing packets to Net 10 Hosts

    This handles the case where an organisation is using IP addresses that are
    private (e.g. use of 10.x.x.x as per RFC-1918). When packets
    have to be secured to hosts that are in net 10 environment, one needs
    infrastructure. DNS support is needed to identify where the packets
    destined for the net 10 hosts can be tunneled to so that, NAT
    can then forward the packets to this private host.

    Consider site S with border router R1.  Let S1 be some node inside site S
    and behind R1. Consider some remote node X that is not within the same
    administrative domain as S or R1.  Now consider that X wishes to initiate
    an IP session with some node S1.  X performs a DNS lookup on S1 and
    receives an authenticated A/AAAA record with S1's address and also obtains
    a KX record covering S that points to R1.  This enables X to know that it
    should initiate a key exchange session with R1 if X wishes to use IPsec to
    protect its session to S1. In this case, R1 is behaving as NAT as well as
    proxy security server.

    In this scenario, NAT is responsible to impose security on the
    packets flowing into the net 10 environment and there could be some
    performance bottlenecks.

2.4 AH in tunnel mode

    AH in tunnel mode is useful in cases such as Scenario 2 of section 2.1
    where you may have a requiment that says that all packets flowing between
    two routers need to be authenticated. It is also useful in cases when the
    end hosts do not implement IPSecurity and decision needs to be made at
    firewall/router as to which packets should be let into the network.

    In this scenario, it should be noted that AH does not protect the
    confidentiality of any data being transmitted and hence this is not
    strictly speaking a Virtual Private Network.  VPNs separate the different
    logical networks via encryption while AH only provides cryptographic
    authentication.

Note: Some of the discussions above may change depending on the new drafts.

Acknowledgments
    I would like to thank Ran Atkinson and Steve Kent for their valuable
    input.

References


    [RFC-1825]    R. Atkinson, "Security Architecture for the Internet
                  Protocol", RFC-1852, Naval Research Laboratory, July 1995.
    [RFC-1826]    R. Atkinson, "IP Authentication Header",
                  RFC-1826, August 1995.
    [RFC-1827]    R. Atkinson, "IP Encapsulate Security Payload"
                                  RFC-1827, August 1995.
    [RFC-1918]    Net 10 (need to add more into)


Doraswamy                                               [Page 6]

INTERNET DRAFT              October 10, 1996        Expires April 1997


Contact

    Naganand Doraswamy
    FTP Software Inc.,
    2 High St.,
    North Andover, MA 01845
    naganand@ftp.com