NAT WG meeting minutes - 44th IETF - Minneapolis, MN - March 19, 1999
Chairs: Matt Holdrege <
[email protected]>
Pyda Srisuresh <
[email protected]>
Reported by: Ben Rogers <
[email protected]>
Edited by: Matt & Suresh
Attachements: 1. RSIP IETF 44.PPT
2. IETF-NAT-SNMP-ALG.PPT
____________________________________________________________________
Mailing list:
[email protected]
To subscribe: Send e-mail to
[email protected] with
"subscribe" in the body of the message.
To unsubscribe: Send e-mail to
[email protected]
with "unsubscribe" in the body of the message.
Mailing list:
[email protected]
(This is nat mailing list, in daily-digest format.
To receive the digest, you can subscribe as follows.)
To subscribe: Send e-mail to
[email protected] with
"subscribe" in the body of the message.
To unsubscribe: Send e-mail to
[email protected] with "unsubscribe" in
the body of the message.
All presentations, along with WG meeting minutes will be avilable
on-line from the following URL (Within a few days after this posting)
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>"
<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 - "WG Introduction"
Agenda
IESG Document Status
Architectural Implications of NAT
draft-iab-nat-implications-03.txt
Protoocl Complications with the IP network Address Translator (NAT)
draft-ietf-nat-protocol-complications-00.txt
NAT Friendly Applications Design Guidelines
draft-ietf-nat-app-guide-01.txt
An SNMP Application Level Gateway for Payload Address Translation
draft-ietf-nat-nat-snmp-alg-00.txt
Realm Specific IP: A framework draft
draft-ietf-nat-nat-rsip-framework-00.txt
Realm Specific IP: Protocl specification
draft-ietf-nat-nat-rsip-protocol-00.txt
IP Relocation through twice Network Address Translators (RAT)
draft-ietf-nat-nat-rnat-00
Miscellaneous
Pyda Srisuresh - "IESG Document Status"
Reminded the audience about the Word from the ADs concerning
presentation discipline, sent as part of agenda e-mail.
Presenters should focus on unresolved/outstanding issues rather
than give tutorial of their drafts. We intend to operate this way
from this point on, going forward. Further, most of the issues
should be debated over the mailing list.
For those presenters, who came prepared with some educational
viewgraphs, I would be glad to add those slides to the WG minutes,
even as they donot get to present these slides.
Terminology draft - is intended to encourage the use of same common
terms across drafts. This draft is a required reading for all NATWG
attendees.
As for WG drafts with the IESG - the IESG has close to 4 drafts (The
DNS-ALG went through WG last call but not resubmitted with changes
folded in). Suresh has been working with the IESG members to remove
ambiguities and clarify text in the terminology draft. As soon as the
draft clears its way, other should follow right along.
Pyda Srisuresh - "Agenda change"
Offline meeting with the Tony Hain, the author of the IAB NAT draft
will result in Tony making a new revision of this draft. This new
copy of the draft will be discussed in the next meeting, if necessary.
We hope, issues are discussed over the mailing list and the draft
goes through WG last call much before the next IETF, so we dont
have to pursue this until the next IETF.
[Tony Hain - If anyone has comments, please send them]
[Brian Carpenter - Can Tony tell us the date for the 04 draft?]
[Tony Hain - April 2]
[Brian Carpenter - We'd like to get any gut feelings out of this draft
and try to make it more objective. This should
become a draft that we all agree on, instead of
an IAB or NAT authored draft.]
[Pyda Srisuresh - Yes, I fully agree with Brian's
comments. We do like to have a single
IAB/NAT-WG draft that people could refer.]
[Matt Holdrege - There is a significant positive difference in 03.
The review was mostly intended to remove some
ambiguities, so readings of 03 might bring up
problems which have already been solved.]
Matt Holdrege - "Protocol Complications"
Little input has come back from this group. Matt has sent a note
to all WG and BOF chairs requesting input and specific
complications. Very little information was returned. This
needs to become an RFC
[???? - Which protocols have we already heard from?]
The draft shows which protocols we have already looked
at and found problems with.
Matt may look through protocols as he can to find
possible problems.
Before the next rev of this draft, Matt will be working on
reorganizing the draft to make it more organized and readable.
[Danny Raz - Can we make a list of protocols which have been
known to be working with NATs?]
In theory, this is a good idea. In practice, it will be
nearly impossible. It is very hard to actually say that
something _certainly_ works with NAT, given obscure
options, etc.
This will be taken under advisement.
[Brian Carpenter - We could add a disclaimer to cover liability.
Many of the protocols belong to currently dead WGs.
Other areas might not even imagine that they might
need to respond to such a request, as they might
not see how NAT might be used with them. eg: BGP4]
Comments?
Pyda Srisuresh - "NAT Friendly application design guidelines"
<Suresh will be representing Daniel Senie, who could not be present
for the meeting. Issues will be forwarded to Daniel if necessary.>
Questions?
[Dan Raz - Plans for NAT friendly evangelism outside this document?]
No. Only to present the guidelines.
If anyone feels like this draft does not address any issues that
particular protocols might have, we'd like to hear about them.
One of the issues might be that Address bindings are not guaranteed
to last in NAT after the session that used the binding has terminated.
Some applications such as RSVP require that the Binding parameters be
kept alive, even after the session that caused the binding to originate
has gone away. This could be a sticky problem area - Are there many such
applications ??
But for a few nits, the draft does not seem to have any issues left
and may be ready to move forward.
More comments?
[Rhandeev Singh - DNS lookups? Should the application cache these
lookups, or always do the lookup?]
The application should do the DNS lookups, but not
cache the results longer than is advised in the
response. DNS-ALG will set the responses to be
valid for no longer than a second for dynamic
address bindings.
Dan Raz - "SNMP-ALG"
The problem
o Two or more private networks use the same address space.
o A single management station is expected to manage
both of them.
o Occurs during mergers and with network service providers
Constraints
o Local networks cannot be reconfigured
o No changes to NM software
o Transparent to both NM application and to network elements
o SNMP Proxies require reconfiguration of the local network and
possibly NM software changes.
These proxies are intended to support elements which do not
have an agent.
Solution
NAT between n-1 overlapping networks and the NM station
Issues
o Can this be done using only per-packet information
Currently everyone has standarized on using UDP under SNMP.
TCP is possible, but not currently supported.
o Private MIB and non-standard encoding
When the variables contain address information, then we need
to translate those addresses.
IP address type is the standard way to encapsulate IP
addresses, but we often see private encapsulations of those
addresses.
o Performance
There is much work that needs to be done to parse the SNMP
packets.
o IP addresses are used as an index to MIB tables
Basic NAT-SNMP-ALG
o Translate only PDUs from network elements to manager (they
have the data).
o Translate only standard IP address type encoding
o Does not change packet length and OIDs
o May be insufficient for some applications
[Thomas Narten - This doesn't work if you dont have the same number
of global addresses as the number of machines you
need to manage.]
Correct. This is meant to be static.
[Pyda Srisuresh - I believe, the requirement is simply that Whoever
is assigning the mapping addresses for the various
private networks needs to ensure that managed
address do not overlap. These neednt be globally
unique.]
[Thomas Narten - I cannot see why a network manager would want this.]
[Bernard Aboba - I'm confused as to what you're trying to manage.]
The situation at hand is a real world case, and is a
real world requirement from network managers.
This application reduces cost
[Thomas Narten - The information is now hidden and the network is now
much more difficult to manage.]
This doesn't necessarily help manage, it works for
situations where we could do nothing else.
[Bernard Aboba - Write an SNMP proxy. It is easier than NAT.]
[??? - won't work for SNMPv3]
Yes it will.
[Others - Explain nature of v3 authentication and hence cite the
reason why SNMPv3 wouldnt work with this solution]
It will if the ALG has access to SA keys - The ALG
can get this from the SNMP application.
[Thomas Narten - Same as IPsec end-to-end versus concatenated tunnels.]
The keys are still within a single organization.
[??? - Assume that all NATs are run by the same organization.]
[Matt Holdrege - Since this is a problem specific solution, this
should be Informational.]
Yes.
[Tony Hain - The applicability statement should be very strong
to show that it will not work in all situations.]
[Steve Deering - Doesn't the proxy provide a better solution?]
No, that requires network reconfiguration.
[Brian Carpenter - The proxy would take the load off the normal packet
processor, thus providing added advantage.]
The NM software gets confused with a proxy.
[George Tsirtsis - A proxy can always be used in place of an
ALG, but the ALG makes more sense in some
cases.]
[Brian Carpenter - The management station should be reconfigured to
become NAT aware. Without this, there is no way
to clearly visualize the network.]
Manufacturers of this software are looking to NAT to
solve this as they don't want to rework their own code.
[Matt Holdrege - This discussion should be moved to the list.]
Michael Borella - "Realm Specific IP (RSIP) protocol Specification"
o Generalization and extension of HostNAT/DNAT
How many have read the draft? [more than 10] Not bad
Security
o As RSIP is currently defined, spoofing can be used for denial of
service.
o RSIP should eventually include authentication
We're looking for feedback on these security isssues.
[Pyda Srisuresh - Are these issues you raise different from that of
of a DHCP protocol?]
No. Same issues exist in DHCP as well.
Problems which RSIP doesn't solve
TCP TIME-WAIT
o Policy fix at RSIP server
NAT problems
DNS
ICMP requires memory
External access to local services
[Bernard Aboba - This doesn't seem to work for IPsec tunnel mode for more
than one host at a time.]
[Unless you have a table of SPIs, you wont be able to demux]
Yes
[Tony Hain - Make sure this is addressed]
[Pyda Srisuresh - Why is TCP TIME-WAIT a problem?]
[Thomas Narten - Problem with generic NAT, or is it induced by RSIP?]
Listed this as an issue because it was mentioned in the IAB draft.
[Timothy Shepard - ICMP issue]
Need some memory to properly send pings through
Feedback needed
o Comments on the whole idea
o Evaluation of messages and parameters (too few, too many)
Is the protocol too complex, or is it lacking in certain areas
o End to end security
Will be submitting a draft on how to run end to end IPsec
through RSIP.
[Gabriel Montenegro - Will the SPI be the demuxer?]
Yes.
[Gabriel Montenegro - I have NAR draft out that addresses this and
can be used as a basis for this area. The
old draft has already had some scrutiny from
IPsec folks in the last IETF meeting.]
[Gabriel Montenegro - Why not use SOCKS as the base and add
extensions to supports the RSIP protocol?]
[Bernard Aboba - Concern about similarity between this and other
protocols. How can we evaluate this against other
alternatives?]
Will be addressed in architecture draft
[Brian Carpenter - RSIP is one solution. We could really use
Map-and-Encap in order to compare.]
IPv6 Transition
RSIP could be used for V6 transition such that IPv4 addresses are
assigned to IPv6/v4 hosts. This could be explored in future versions
of the draft.
[Pyda Srisuresh - The main goal of the draft must be to address
Private-v4<=>Public-v4 issues adequately. Subsequent to
that, you could work on making it extentsible to other
areas, including IPv6 transition]
[Pyda Srisuresh - Can the server notify the client?]
Yes, to invalidate parameters.
[Pyda Srisuresh - Doesn't look like unsolicited messages are covered here.]
Not explicitly at this time.
[Pyda Srisuresh - Why does a node need to ask for multiple addresses
at a time?]
Basic-NAT environment where we might need a distribution of
a sub-pool of addresses.
[Pyda Srisuresh - You mean allocation between servers?]
Yes. The server should be able to act as a client to get
multiple addresses.
[Pyda Srisuresh - This seems confusing and can lead to misconfigurations.]
[Pyda Srisuresh - On a different note, Address request and port requests
should not be separate, when a host is requesting for
a tuple of (IP Address, TU port).]
Request for address is combined with a request for a
block of ports - for extensibility.
[Pyda Srisuresh - The protocol does not seem to take into account domains
that are supported by Multiple NATs.]
Two RSIP routers for the same client? Is this realistic?
[Pyda Srisuresh - Yes]
[Pyda Srisuresh - Why do we need to consider twice-NAT?]
Twice NAT mentioned for completeness sake.
Expresses desire to move the draft forward for the common
case. Scope can be narrowed to accomplish this
[Pyda Srisuresh - You need to include bi-directional NAT.]
Yes, we will include that.
[Pyda Srisuresh - DNS needs to be discussed as well in conjunction with
Bi-directional NAT.]
Yes.
Jeffrey Lo - "RSIP Framework"
Brief discussion of how RSIP actually works.
Comments?
RSIP Protocol
o Lightweight negotiation of arbitrary parameters.
o Messages and parameter formats allow extensibility beyond the
current specification.
RSIP Protocol Phases
o Registration
RSIP server becomes aware of an RSIP client, and assignes a
client ID ant tunnel type.
o Assignments
o Transport
[Pyda Srisuresh - Isnt sequence number you use simply a message ID
for message request and response correlation?]
Yes.
[Pyda Srisuresh - Then, simply call it Message-ID, so it is less
confusing]
[Pyda Srisuresh - Is the framework document discussing protocol issues?]
[Michael Borella - the framework document presents the problem
that RSIP is trying to solve.]
[Pyda Srisuresh - Framework doc should consist only of requirements,
scope and applicability. It may be referenced by
the protocol document.]
[Pyda Srisuresh - A good area to mention in the framework draft is
whether applications would be affected, or only
the protocol stack.]
[Rhandeev Singh - Are you saying that we can do away with the DNS ALG?]
[Michael Borella - Not at this time.]
o Freeing
[Pyda Srisuresh - Is this something that the application does?
It is not clear that the stack can do this.]
This needs to be studied.
[ed- Further discussion and bickering on location of this
protocol (stack vs. application), socks, ...]
o Renewing
o De-registration
Messages and Parameters
Parameter List
Errors
More comments?
[Pyda Srisuresh - Security Considerations seems to imply that the server
should be a traffic cop for traffic generated by RSIP
clients. The original intent was for RSIP clients to be able
to take part in end-to-end IPsec. The traffic cop defeats
this purpose.]
More on the mailing list
Rhandeev Singh
IP relocation through twice network address trnalators
Originally presented at mobileip WG
Is intended to be a bootstrap for mobileip. NAT is proposed for a
quick-fix for initial deployment.
RAT and MobileIP Comparision
Relocation (Mobile-IP and RAT)
Seamless mobility (Mobile IP)
[Thomas Narten - What do you mean by this?]
RAT doesn't allow you to keep your connections as your
address changes.
[Steve Bellovin - Why not use tunnel mode IPsec, which provides
seamless mobility?]
This is not intended as a replacement for MobileIP, but merely
to give people experience with mobility
Route Optimization (Mobile IP)
E2E Layer 3 Security (Mobile IP)
Immediate Utility (RAT)
Issues
o ALG requirements
Needed when applications don't work correctly. Free versions of
ALGs are encouraged to be shared.
o Application Scenarios
When is RAT most applicable?
o VPN-like connectivity
o FIREWALL traversal
RAT-to-RAT tunneling across firewalls?
[Pyda Srisuresh - Concerns about using RAT for mobileip.
Introductory section should be clear on what
the advantage/motive is for using RAT.]
o PRIVATE home addresses
o RSIP enabling
[Pyda Srisuresh - What do you mean by a RAT device, and how does it
relate to twice-NAT? We need an architectural
description of what goes into a RAT device.]
Zero-knowledge will register with registration server.
Registration server will the send configuration
information to the RAT device (Twice NAT box).
[Pyda Srisuresh - How does the HA talk with the RAT device?]
RAT box will intercept packets from the Correspondent
Node and NAT them on their way to the Zero-knowledge
Mobile Node.
[Pyda Srisuresh - Is the RAT device doing the equivalent job as
the Foreign Agent?]
It looks more like a Home Agent than a Foreign agent.
[Steve Deering - Traffic from Correspondent to Mobile Node undergoes
Twice NAT?]
Only for Correspondent -> Mobile Node sessions. Sessions
in the other direction are not translated at all.
[Brian Carpenter - How did the MobileIP group respond to this?]
Pretty much ignored.
[Hillary Orman - This seems more comparable to IPsec tunnel mode.]
Yes, but nobody is shipping it.
[Steve Bellovin - Lots of demand and implementations are emerging
soon after the IPsec RFCs have come out.]
So, we're seeing a lack of support for RAT because
IPsec gives us the functionality?
[ed- implied general consensus]
[Brian Carpenter - Many large coorporations have already rolled out
tunneling solutions.]
The purpose of RAT/MobileIP is to provide mobility.
[George Tsirtsis - This tries to address something between roaming
and mobility.]
No changes are required to Mobile Nodes. The RAT box instantly
provides all functionality even to legacy hosts.
[Steve Deering - This seems ironic, as it uses NAT to help outisders to
reach a global address.]
[Brian Carpenter - Since the time that MobileIP has started, we have
given up on having fixed addresses. Too many hosts
are forced to use private addresses.
Matt Holdrege
Other issues?
Adjourned
