Subject: (NAT) Pittsburgh minutes

From: Matt Holdrege <[email-masked]>
Date: Sun, 20 Aug 2000 23:16:57 -0700

NAT WG Minutes

Scribed by Daniel Senie

Matt Holdrege <[email-masked]> and Pyda Srisuresh <[email-masked]>
WG Chairs

Thursday, August 2, 2000, 9AM

Agenda:
- NAT Implications - Tony Hain
- NAT Protocol Complications - Matt & Suresh
- NAT traditional - Suresh
- RSIP drafts - Gabriel
- App Guide - Daniel
- Interface Framework - Suresh
- NAT WG Revised milestones
- Aboba-NAT-IPSec - William Dixon
- ipsec-nat-traversal - Steinberg

--

Matt: Introductions. RSIP -> Experimental path being considered. Proposal
stage only at this point, will be taken to the mailing list.

Tony Hain: IAB Draft. Current revision -08. Minor comments received from
Suresh. Send Tony additional comments. Status: almost done, needs cleanup
then publication.

Suresh: The draft does seem closer to being done - awaiting response to
the comments sent.

Matt, Protocol Complications draft: IETF last call did the trick in getting
comments. Comments incorporated. Draft will be sent to WG last call.

Suresh: reviewed changes made in most recent draft:
Added a section on common characteristics of protocols
broken by NAT.

Draft redone to ensure there were no "pro-NAT"
wording, or understatement of the problem.

New text for lack of support of Kerberos, X Windows issues
(FQDN can't be used).

Send comments.

Suresh: Traditional NAT draft. WG last call and review complete long time
back. Any additional comments, feedback still OK. Awaiting IESG
review pending other base NAT drafts. Publication of all base NAT
documents (IAB draft, NAT complications draft and traditional NAT
draft) must happen together.

Gabriel: RSIP drafts. Revised framework specification and support for
end-to-end IPSec.

Framework document: Mike Borella lead, introduction rewritten, replaced
implementation considerations with requirements section. Added sections in
multi-party applications and scalability. Toned down mobile IP interaction.
Added reference to the SLP-RSIP draft, and added a table of contents.
Protocol specification document: registrations have lease times. Management
of lease times discussed. Most packet and field diagrams documented in
canonical form. RSIP gateway can redirect a host to a particular tunnel
endpoint not necessarily itself.

IPSec support document: put message time before overall length to align
protocol with protocol draft 5 added message counter parameter.

Suresh: Comments: Discussion on IETF list about administrative /
manageability of RSIP stack. Has this been added?

Gabriel: yes.

Suresh: Concern RSIP is significant effort to manage. Concern there's
issues with how the control channel interacts with applications. There
are many applications that are affected by the way RSIP control and
application data paths interact, but haven't been addressed.

Gabriel:
expects there are holes, needs a summary or to do some research in this
area. Multi-party case, is a good example, the RSIP folks don't know how to
address these.

Action item: Gabriel will research updates to deal with the issues. Suresh
will try to get some summary information from the discussion on the IETF
list to Gabriel.

Mike Handley (sp?): Blanket statement that there's no need for ALGs in
RSIP. Believes there could be more explanation.

Suresh: Assumption is that with RSIP replacing NAT, this obviates the need
for ALG (end host will do the work).

Protocol draft: last message buffer discussion could use clarification. Is
it per-host? Matt: Yes.

Daniel: draft-ietf-nat-app-guide-03.txt received few comments. Suresh
suggested adding a section on peer networking, mirroring the protocol
complications draft, and suggested verifying similar content match-up with
other areas.

Suresh: Interface Framework document. Foglamps mailing list discussion of
mechanism to control firewalls and NATs and control resources. Very similar
to what's in this draft, which has added interest to this draft. Now
interest in building a protocol for interfacing with NAT/Firewall. This
document could be the basis for such work. Interfacing with ALG both
internal and external, administrative agents, RSIP clients,
multihomed-NATs, and so forth. Addresses foglamps issues relating to NATs
(not firewalls), but could be used in that area. Would like to move this
document along within the WG.

Milestones: Matt: we're late. Milestones not met. Base documents are about
ready. the IAB draft also a gating factor.

Suresh: By early next year, WG milestones should be completed, provided
the base NAT drafts are cleared with IESG.

Brian Carpenter: should RSIP be split out to a separate WG to get it
completed?

Matt: not clear it'd get more attention as a separate WG. In any case, it's
an IESG issue.

Alison: IESG will discuss as a part of the charter discussion.

Gabriel: RSIP really separate from NAT, and would prefer if it were split off.

Suresh: 9 months ago, ADs thought the NAT WG be the place to put it, but in
the mean time, the NAT drafts haven't progressed so quickly.

Matt/Alison: take hum of the room. Seems to be rough interest in splitting
RSIP off into separate WG. Alison will take input to IESG and see what
consensus is.

Bernard Aboba: NAT and IPSec discussion: draft-aboba-nat-ipsec-02.txt. Will
talk about the problem here, not solutions. Solutions will be discussed at
IPSec group.

Goals and objectives: Describe the scenarios and issues. Usage scenarios:
Telecommuters with IPSec and NAT because of DSL/Cable modems. Tunnel
scenario. Transport mode is seen as extremely difficult at this point.
Compulsory tunneling cases exist with ISPs and other upstream cases.
Various discussion from the floor about DSL, cable modems and STSN/hotel
system.

Suresh: Can it work with IPSec running in the NAT box? Bernard's experience
is customers don't handle it.

Bob Moskowitz: Providers forcing IP address changes often via DHCP as a way
to limit servers on cable modems and such. Makes matters even worse.

Known Nat/IPSec incompatibilities: AH, checksums (pseudoheader issue). UDP
checksum is optional, providing a way around.

Alison comment that they should be used, however. Tunneling discussion: if 
inner packet is unaffected. IKE allows other identifiers, not necessarily 
just IP
addresses. Issues with embedded IP addresses within NAT (in payload).
Incompatability between IKE destination ports and NAPT. Source ports will
be changed. Re-key can occur on either side. Re-key coming from server
looks like unsolicited packet, and NAT will drop it. NAT Port timeouts a
big problem here, as the mapping would have to keep the association alive.
In transport mode, Incompatibility between overlapping security policy and
NAT policy. Makes for difficulty in deciding where to send information.
Without client-nat communication this is a problem.

Suresh:
request quick mode vs. main mode issues be isolated. Incompatability 
between SPI
selection and NAT: issue is SPI of packets incoming to NAT with out client-nat
communication NAT must depend on timing. A problem nearly all the time.

Summary: NAT compatability critical to key uses to Ipv6. Incompatibilities
substantial and intricate. Goal is to find a solution sooner than Ipv6.

Brian Carpenter: 6-to4 has the same problem. Floor question: how about
tunneling IPSec over L2TP.

Marcus Stenberg: Short talk about his draft. Only requires changes in end
station.

Marcus Leech (AD): IPSec WG will be chartered to deal with the
interoperability issues.

End Of Meeting

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.