VPN BOF meeting minutes Co-chairs Naganand Dorasamy <naganand@baynetworks.com> Robert Moskowitz <rgm-sec@htt-consult.com> Mailing List: vpn@baynetworks.com I would like to thank Hugh Daniel for taking notes. BOF Charter Virtual Private Networking (VPN) is a way of extending a private network seamlessly over a public network. However, this raises various issues such as security, Addressing, Quality of Service to name a few as the traffic belonging to the private network traverses a public network. VPN model can be one of many. An organization can build its VPN. An ISP can build and maintain a VPN of an organization. VPN can exist between organizations (extranets). There is a need to define mechanisms to achieve these capabilities. Some of the issues that needs to be addressed are: 1. How to establish Automatic Tunnels. We can look into existing technology to and adapt it to our needs or define a new protocol. 2. How to handle Network Address Translation issues. Even though NAT's are a kludge, it has been deployed widely and there is a need to address this issue properly. 3. How to secure the traffic. IPsec provides a way to secure the traffic. We need to define mechanisms of using it for VPN by defining how policies get distributed, how tunnels are established. 4. How to provide Quality of Service/Class of service for packets flowing between the edges. In this case, we may not be worried about providing end to end QoS but only between edges. 5. Issues with naming. There are two basic challenges with naming: How to announce a server based on its VPN name and tunnel, and how to find a server address and tunnel when behind a tunnel gateway. Currently this is done with manual configurations and DNS query hacks. Are there improvements to DNS, like new resource records, that can smooth out this process. The goals of the VPN BOF are: 1. Decide if there is a need to form a working group to solve some or all of the problems above. 2. Which of the problems above should be addressed by the working group. 3. What will the working group produce. In our opinion, we need to interact with other working groups such as IPsec working group, NAT working group, int-serv working group, and probably routing working group to solve some or all of the problems above. 4. What other problems need to be solved for successful deployment of VPN's. Agenda Introduction by Naganand Doraswamy, Bay Networks TEP by Charlie Perkins, Sun Microsystems Policy Issues by Roy Pereira, Timestep VPN customer scenarios for IBM by Charles Kunzinger,IBM NAT and Net66 by Robert Moskowitz, Chrysler Corporation Advanced VPN Services by Shantigram Jagannath, Bay Networks Introduction The goal of the BOF is to decide on the following: - Define scope of what VPN means to IETF - Define models of VPN - What tech requirements? The requriments can be broadly classified into: Tunnel Management - discovery - configuration - address allocation - fragmentation - DNS (BIND was later added) Security - how to secure traffic IPSEC? - Policy issues Class of server - services, do we address: bandwidth, delay - models TEP - Charlie Perkins described the Tunnel Establishment Protocol (TEP) <draft-ietf-mobileip-calhoun-tep-00.txt>. The idea was to see if TEP could be used to dynamically discover tunnel end points for IP Security. TEP is a protocol that is defined in the context of Mobile IP to establish hierarchical tunnels. Even though it looks like mobile IP, it does not use much of the mobile IP infrastructure. TEP allows multi-level security domains to be handled by hierarchical arrangement of tunnel agents. TEP was described in detail. Policy Now that a lot of VPN-based protocols have been standardized, we must look further to how it will actually work in real world situations. This opens up issues that must be dealt with. Issues like Illegal Address Subnets, Internal Management Servers, Policy Management, Tunneling into Private Networks. Another large issue is that there now exists many different methods to accomplish the same task (eg. PPTP, L2F, IPSec). The Goal of a VPN working group should be to marry the existing technologies together, create a policy structure, maintain scalibity and open standards. Customer Scenarios Wants a standard VPN config system that is the same between different VPN products & maybe vendors. Wants to use LDAP to hold all the configuration and maybe routing data for such a system, claims to have a spec or maybe some working code they are willing to contribute. Advance VPN Services This 10 minute talk attempted to address features that might belong to enhanced VPN solutions. The talk addressed the features of Differentiated Services and Reliability and Fault tolerance in the context of VPNs. This goes beyond the requirements of security, tunneling etc. For differentiated services, the VPN solution needs to be based on whatever gets standardized in the Diff. Serv./Int. Serv. group. There are however, the following approaches to looking at providing differentiated VPN services. a) Single Pipe, Single Class VPNs - all flows tunnelled into a single class - simpler provisioning and pricing - lacks flexibility to provide diff. serv. within the VPN - resource management needs to be done at the edge of the VPNs, possibly where the tunnels originate and terminate. b) Multiple pipes, perhaps one for each class of traffic - parallel VPNs, separate provisioning for each class of traffic, separate connectivity for each class - added flexibility - flow aggregation (multiple sessions between the same end-points of the VPN) at the edge c) Secure VPN clouds - no provisioning and capacity planning, flow based set-up and tear down of VPN tunnels. - full flexibility - complex signalling and implementation details Some issues of VPNs in the context of service providers were raised a) Single ISP VPN - originating and terminating at the edge of a single ISP - resource mgmt. can be done within the ISP, room for proprietary solutions b) VPNs spanning multiple ISPs - peering agreements between ISPs, set policy and business level agreements - standardised mapping of services across ISPs Issues to be considered in providing Diff Serv. for VPNs (summarised from the above slides) a) number of levels - different isps may provide different number of levels - need for standard levels across isps b) provisioning, signalling mechanisms have to be put in place c) in band negotiation to provide flexibility in resources for a VPN d) routing issues - number of addresses, route pinning etc. e) peering agreements, policy Some issues of VPNs and reliability were raised a) Points of failure - access, first router - peering points b) Recovery is dependent on BGP fault detection and recovery - can be slow c) need for better fault detection and recovery - alternate routes(?) - VPN-keep-alives (?) Net66 and NAT The Net66 proposal is an effort to severly limit the amount of NAT work needed in a VPN. The underling premises are that: Each network in the VPN will only advertise a small number of servers These servers need to be globally addressable, but not routable. The VPN gateway address is routable. The global address can be used by the server in the local network All servers will be addressed out of a common address block, allowing for route aggregation within the client's network With this the only NAT function required is the client's source address if it is not a private address. This is done in the destination VPN gateway. To accomplish this, IANA will need to set aside a block of addresses for Net66 and develop the allocation process, by server request. Conclusions Statement that one tunneling protocol will not solve all the various folks problems as we really are trying to solve different problems and trying to have only one solution is likely a waste of time. Naganand says that we are just exploring the problem space and not trying to force a single solution. It was probably a little premature to assume that tunneling will be the mechanism even before refining the problem statement. The next step is to first refine the problem and define the models of VPN and the services that VPN needs to provide. After that we need to figure out how we can provide these services. Either use existing protocol or work with other working groups to extend suitable protocols. There was enough interest to form a working group.