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.