NAT WG meeting minutes - 43rd IETF - Orlando, FL - December 9, 1998

Chairs:         Matt Holdrege   <matt@ascend.com>
                Pyda Srisuresh  <suresh@ra.lucent.com>

Reported by:    Ben Rogers      <ben@ascend.com>
Edited by:      Matt & Suresh
____________________________________________________________________

Mailing list:   nat@livingston.com

To subscribe:   Send e-mail to nat-request@livingston.com with
                "subscribe" in the body of the message.
                To unsubscribe: Send e-mail to nat-request@livingston.com 
                with "unsubscribe" in the body of the message.

Mailing list:   nat-digest@livingston.com
                (This is nat mailing list, in daily-digest format. 
                 To receive the digest, you can subscribe as follows.)

To subscribe:   Send e-mail to nat-digest-request@livingston.com  with 
                "subscribe" in the body of the message.
                To unsubscribe: Send e-mail to 
                nat-digest-request@livingston.com with "unsubscribe" in 
                the body of the message.

All presentations, along with WG meeting minutes will be avilable
on-line from the following URL.
 
       http://www.livingston.com/tech/ietf/nat
____________________________________________________________________

In order to avoid confusion, the following indentation and format legend 
should be used as a guide to interpreting the minutes.

<Presenter> - "<presentation/Discussion Topic>"
<Any other remarks by minutes taker or editors>

  Detailed Slides and/or Comments made by the presenter

     Questions from the Audience:
            
        [<Audience-Name> - <Question/Comment>]

                           <Response from the Presenter>

_________________________________________________________________________


Matt Holdrege - Introduction

  Two NAT Drafts sent to mailing list completed WG last call and
  are currently awaiting IESG review for advancing into informational
  RFC status.

  Agenda

       1. "NAT Friendly Application Design Guidelines"          20 mins.
          <draft-ietf-nat-app-guide-00.txt> by  Daniel Senie

       2. "A Multihoming solution using NATs"                   20 mins.
           < draft-akkiraju-nat-multihoming-00.txt >
          by Praveen Akkiraju and Yakov Rekhter

       3. "Security for IP Network Address Translator           20 mins.
           (NAT) Domains"
          <draft-ietf-nat-security-00.txt> by Pyda Srisuresh

       4. "IP Network Address Translator (NAT) Protocol Issues" 20 mins.
          <draft-ietf-nat-protocol-issues-01.txt> 
          by Matt Holdrege & Pyda Srisuresh

       5. "IP Network Address Translator Application            20 mins.
           Programming Interface"
           <draft-ietf-nat-api-00.txt>      by Pyda Srisuresh

       6. "IP Host Network Address (and Port) Translation"      20 mins.
           <draft-ietf-nat-hnat-00.txt>     
           by Jeffrey Lo & K. Taniguchi

Daniel Senie - "NAT Friendly Application Design Guidelines"
<draft-ietf-nat-app-guide-00.txt>

  http://www.amaranthnetworks.com/nat - This is the link to Daniel's 
  web page that will have the most uptodate copy of applications that
  are NAT friendly

  General Goal

    o Develop new application protocols which do not require ALG
      assistance from NAT and Firewall implementations

      These guidelines tend to apply to both NAT and Firewall
      implementations as the requirements for a firewall a similar.

  General Recommendations

    o Use of Multiple Session Bundle

      * Use single TCP or UDP port for all traffic where possible

      * If possible, originate all sessions from the same endpoint
        (this avoids the FTP problem)

    o Use DNS names, not IP addresses

    o Avoid passing addressing data in payload (IP addresses, port numbers)

    o End to end IPsec problematic

      * Consider using TLS instead.  Host NAT is a possibility for the future

    o Service Location

      * Avoid location via broadcast or multicast

    o Subsequent Sessions

      * Address bindings not guaranteed between subsequent sessions.

        Reliance on the appearance of co-location can be problematic

    o Operational Reliability

      * TCP preferred over UDP since NAT can track TCP sessions more
        easily and know when sessions end.

      * UDP sessions are tracked by timeouts.

      ALG's can overcome this problem, but we'd rather design
      applications to not need this processing.

    o Processing Overhead

      * Each new session requires resources and processing to
        establish associations.  Using a single session for app
        reduces overhead.

      There is still some overhead, but this is unavoidable.

  Additional Items

    o Comments since the last draft

      * Performance: latency and throughput can be affected by NAT.
        Depends on implementation.

        The hardware solution can be optimized to lessen this problem

      * NAT implementations presently tend to only support TCP and UDP
        applications (... for implementations of NAPT). A device 
        performing just NAT, without any ALG support, supports 
        many applications as is.


  Questions from the Audience:

    [Eliot Lear - UDP session management.  UDP may make it more
                  difficult to maintain the mapping]

                  An application may maintain keep-alives to make this
                  less of a problem.

    [Someone said there are similar issues with SOCKS, and these ideas can
                  be shared with NAT.  Do we have any plan to make a 
                  utility to verify the guidelines? ]

                  Multiple sessions can work, but are not as reliable, nor
                  as friendly as single sessions.  An analyzer might be
                  created to diagnose traffic in a non-NAT environment.

    [Can we add a recommendation to change current applications (eg. 
                  modify FTP to use passive) to avoid these problems 
                  in current protocols.]

                  An RFC exists on this particular issue, RFC1579 by 
                  Steve Bellovin. It doesn't reduce FTP to a single 
                  session, though, just makes the connections start 
                  from the same endpoint.

Praveen Akkiraju - "A Multihoming solution using NATs"
<draft-akkiraju-nat-multihoming-00.txt>

  Agenda

    o Terminology
    o Bootstrapping
        - Routing configuration
        - DNS configuration
    o Scenario 1: internally originated connections
    o Scenario 2: externally originated connections
    o Discussion

  Problems with Multihoming

    o Creates scaling problems for the global routing infrastructure.

    o Use of multiple address blocks from upstream ISPs provides a
      possible solution, but results in added address management complexity

    o Controlling load balancing based on address assignment is complex

    o Difficult to achieve symmetric flow of packets in and out of 
      an enterprise

  Terminology

    o Inside Global Address (IGA): Block of address space assigned by
      the ISP to the enterprise.

    o Inside Local Address (ILA): Address space used within the enterprise
      behind the NAT

    o Outside Global Address (OGA): Legal address space outside the 
      enterprise and the NAT

    o Outside Local Address (OLA): Address space in the enterprise
      used to translate OGA addresses

    [Brian Carpenter - terminology is quite confusing and is worth
                       rethinking, because outside and inside are
                       backwards from what we're currently used to.]

  Topology

    An enterprise with 2 NAT routers interfacing with 2 different ISPs.

  Routing Configurations

    o NAT configured to assign IGA prefixes to internal addresses and
      OLA prefixes to external addresses.

    o OLA prefixes must not overlap with ILA or OGA address space

    o NATs EBGP peer with upstream ISPs to advertise IGA prefixes

    o NATs injects OLA prefixes into the enterprise IGP routing

    o NATs also IBGP peer with each other

  DNS configuration

    Goal: Bootstrap exchange of DNS messages across NAT

    Reaching the parent zone server

      o Assign an OLA prefix to the external parent server and create
        a translation entry in the NAT mapping the server OGA to its
        OLA

      o Configure internal DNS server with the parent zone server's OLA

    Reaching foo.com's DNS server

      o Assign a IGA prefix to the internal DNS server and create the
        corresponding translation entry in both the NATs

      o Configure DNS Server for authoritative parent zone with the
        IGA's from both NAT's to reach foo.com's authoritative server

        (DNS message handling as in draft-ietf-nat-dns-alg-01.txt)

  Initial NAT Table

    Internal DNS server and Root DNS server are both mapped to provide
    inside/outside pairs for each.

    NAT bootstrapped with foo.com and parent zone DNS 
    server mappings.

  DNS Summary

    o DNS response processing in a NAT consists of 2 stages

      * translation of the IP-UDP header
      * translation of the reply message

  (Walk-through of full packet flow for a DNS lookup, and changes to
   the NAT table.)

  The structure of this query-response system ensures that all traffic
  flow passes through the same NAT.

  Resolving X.foo.com (externally initiated session)

    (Walk through of full packet flow for the incoming DNS-lookup)

  Discussion

    o Scheme places no addressing restrictions on the multihomed network
      except in OLA allocation.

    o Scheme is independent of the enterprises internal routing
      architecture.

    o Changing providers doesnt require renumbering.

    o Due to address allocation packet flow between a pair of
      hosts will always flow through the same NAT resulting 
      in symmetry

    o In case of link failure between the NAT and ISP, fallback 
      connectivity may be provided using RFC 2260 mechanisms.

    o Controlling the selection of the NAT which processes a DNS
      response controls the rest of the packet flow to the target
      host.

      * Load balancing is tied to the flow of DNS packets

      * Translation of the IP-UDP and DNS reply are handled in the
        same NAT

      * Under policy control Translation of the IP-UDP and DNS reply 
        may be handled in seperate NATs

      * This allows for more flexible policy based load balancing
        of traffic flows.

  Misc.

    o Draft includes lab-tested router and DNS server configurations

    o Concept tested by Ed Kern at NANOG

      http://www.academ.com/nanog/feb1998/nat.html

    o Refer draft-rfced-info-srisuresh-05.txt for details on
      NAT operations and issues.

  Questions from the Audience:

    [Brian Carpenter - DNS server for foo.com has to be inside
                       foo.com, and zone transfer will result in a
                       disaster.]

                       Correct

    [continued...      Very clever zone transfer (at minimum) is
                       needed, if this is possible at all. This is not
                       very clear in the text.]

    [Suresh     - Names are apparently end-to-end unique. Is the DNS
                  information here a duplicate effort of the DNS-ALG 
                  draft (or) Is there something particularly different 
                  in this draft?]

                  DNS information here is same as in DNS-ALG draft.
                  The information is included here for Completeness.

    [continued..  Twice nat and BGP are implied as required in this
                  draft, while they are only required for the given
                  scenarios.]

                  Twice nat is not necessarily required, but BGP seems to
                  be.

    [continued..  BGP doesn't have to be on boxes connecting to two ISPs.
                  The draft must be scoped properly.  Terminology should
                  be cleared up to be consistent with other drafts.  
                  Also, DNS based Load sharing discussed here seems 
                  orthogonal to multihoming and NAT issues.]

    [Eliot Lear - We can probably get away with no BGP, but we would
                  still need to use some dynamic routing protocol.

    [Yakov      - BGP is mentioned because an existing RFC 2260 for robust
                  multihoming is based on BGP]

    [Radia Perlman - Talked about ISP link going down, but not what
                     happens when the NAT itself goes down.  Can we
                     force new DNS queries so that address caching does
                     not occur.]

                     Force of 0 ttl should address this problem.

    [Bob Brandt - This seems to infer that there is a 1-1 mapping
                  between external DNS servers and internal addresses.
                  This seems to create a scaling problem.]

                  Addresses are assigned for a limited time, so we can
                  timeout the addresses quickly.

Pyda Srisuresh - "Security Model for NAT domains"
<draft-ietf-nat-security-00.txt>

  Problems with End-to-end IPsec.

  Security from NAT box to external node seems to be possible

  Model made to be in line with IPsec model to provide security for
  NAT nodes-> external nodes

  Terminology

    o Clear-NAT - Nat applied to Outer packet Header

    o Secure-NAT - NAT applied to packets embedded within a secure tunnel

    o Secure-NAT gateway device - Supports both Clear-NAT and Secure-NAT

    o Terminology from IPsec RFCs + nat draft

  Secure-NAT Model

    o Secure Policies administered using private realm addressing

    o Secure-NAT address mapping

    o Security Association Parameters

  Secure-NAT Gateway Outbound Packet Processing

    (Flow-chart to describe NAT processing decision)
    (Verify Outbound packet against outbound Secure policies.
     In case of a match, subject the pakcet to Secure-NAT prior 
     to tunneling using Outbound IPsec SA.)

  Secure-NAT Gateway Inbound IPsec Packet Processing

    (Detunnel packet using IPsec SA, perform inbound Secure-NAT, then
     verify that it matches inbound security policies)

  Slides thus far make the assumption that keys are statically
  configured.

  IKE support to secure-NAT GW

    (Large diagram describing the role of IKE-ALG in the translation 
     of secure policies)

  Secure-NAT applications

    o Secure Extranet connectivity - Allows private domains to
      connect securely to external domains.

    o Secure mobile user connectivity - allows mobile users to
      connect securely to enterprise routers.

  There is a draft by Vipul (<draft-gupta-ipsec-remote-access-00.txt>)
  that describes how secure remote access is possible for a mobile user, 
  without requiring both Home and Care-of addresses on Mobile Node.

Matt Holdrege - "NAT Protocol Issues" draft
<draft-ietf-nat-protocol-issues-01.txt>

  Title has been a point of contention (issues?)
  "Limitiations" proposed on the list

  "NAT Protocol Complications" is the new proposed title.

  We need input from the community

  We will continue to document the additional information we receive
  on protocols in the current format.

  We are working on a better method to get more contributions.

  The draft will be titled after we can put more information into
  this draft.

  Questions from the Audience:

    [Brian Carpenter - RFC on renumbering issues brought up a similar
                       set of problems.  There was not at the time a
                       clean way to find all the affected protocols.
                       Y2K was solved by searching 2000 RFCs, but an
                       appeal to the community may be better in this
                       case.]

                       Diverse group in the room should be able to
                       talk to members of other WGs to help find these
                       types of issues.

Pyda Srisuresh - "NAT API"
<draft-ietf-nat-api-00.txt>

  Draft title is not necessarily representative of the objectives of
  this draft. In particular, the intent is not to mandate standardization
  of the NAT API.

  Objective

    o Identify external agents and their interface requirements with NAT

    o Provide a framework for the development of one or more protocols
      by which agents can interface with NAT

    o Identify NAT objects that could be externalized with MIB

    o Provide an API framework for agents on the same device to
      interface with NAT.

  External Agents

    o Host-NAT and Host-NAPT clients need some way to obtain their 
      addresses and routes.

    o Management application needed to configure a NAT (which ALGs are
      available, ...)

    o Backup NAT may be needed.

    o ALGs

    A number of agents with different requirements would need to
    interface with the NAT.  (Hence the API name.)

    NAT is doing significant resource management, and this information
    is useful for network management applications.

    These constitute the behind-the-scene's agenda for the creation of
    this draft.  There is no intention to standardize on an API.

  NAT elements

    Draft will contain more gory details than are discussed in this
    meeting.

    o NAT Descriptor - ID, Type, Address map, etc.

    o BINDing Descriptor - ID, Type, specific addresses (port) bound,
      Leased time, Controlling Agent ID, etc.

    o Session Descriptor - ID, Controlling BIND ID, Original and
      Translated session parameters, Session Tag, Session Termination
      heuristic, etc.


  External Agent descriptor

    o Agent ID
    o Agent Type
    o Agent Call back requirements
    o Agent Call-back functions
    o Agent Accessibility information

  Function calls provided to agents

    (List of function calls that an agent could invoke)

    Functions are provided to perform inquiries on bindings, sessions
                           to register with NAT (as an ALG, ...)
                           to set parameters within BIND or Session
                           to free BIND or Sessions

  Callback functions in agents

    (List of callback function an agent could provide)

    Callbacks may occur on events or packets, or simply periodically.

  The ADs have advised that this WG is the right forum to discuss
  Host-NAT issues. However, we need to ensure that the base documents
  of the WG are given priority.

  Questions from the Audience:

    [Eliot Lear - This seems to be required.  Brian raised the issue
                  of architectural implications of NAT.  This draft
                  addresses some of those problems, especially in
                  terms of Host NAT.]

                  This doesn't provide for Host NAT, per-se.

    [Brian Carpenter - Hasn't read the draft.]

Jeffrey Lo - "Host Network Address Translation"
<draft-ietf-nat-hnat-00.txt>

  This draft came out recently, so there may not have been many people
  who have taken a look at it.  (Some indication of Distributed NAT.)

  Framework

    o Uses a common "control" protocol for HNAT parameter negotiation

    o Uses tunneling mechanisms for routing externally addressed
      packets within private domain.

  Motivations

    o Lack of a common protocol that enables Host-NAT-client and 
      Host-NAT-Server to interoperate.

    o Hence goal is to design a common protocol that enables 
      Host-NAT-client and Host-NAT-server to interoperate.

  Protocol requirements

    o Client type registration and identification
        - Client ID assignment
    o Enables negotiation of multiplexing fields
        - Global address, port, protocol ID
    o Enables negotiation of HNAT related parameters
        - Max. Leased Time, NAT type
    o Support negotiation of tunnel type
    o Support subnet query

  Considerations

    o Exploitation of existing protocols?

      * DHCP, ICMP, COPS, TCP/UDP/RUTS based?

    o Independence

      * Support negotiation of all fundamental parameters required to
        perform HNAT.

    o Extensibility

      * Flexible packet format

      * Able to support vendor specific information
          - New error codes

      * Able to accommodate new policies.

  Proposal

    o Dynamic Bindings Acquisition Protocol (DBAP)

      * ICMP based
      * Enable assignment of various parameters
        
  End host implementation

    (Chart of relations between various pieces of client and server)

  Questions from the Audience:

    [Daniel Senie - Choice of ICMP versus TCP]

                    This was designed around a larger scale
                    implementation.

    [Nair Venugopal - Does this mean that we can use transport mode
                      IPsec.]

                      Yes.